作为每天和AI资讯打交道的开发者我最近把一套RAG检索增强生成系统完整跑通了专门用来做AI行业快讯的自动生成。效果比我预想的好从丢进一篇原始稿件到清洗、切片、建索引、检索、生成一条通稿式快讯全程三分钟左右基本不需要手动改字。最让我意外的是这套系统用的全是基础技术——RAG本质上就是“先检索资料再交给大模型写”门槛真的没有想象中那么高。这篇文章我就把整套思路、实现代码和踩坑记录都摊开讲适合会一点Python、想入门大模型应用的小白程序员参考也适合想给团队搭一套轻量级资讯流水线的朋友。1. RAG是什么给大模型装上外挂知识库1.1 大模型独自写快讯为什么总翻车很多人第一次尝试用大模型生成快讯都会遇到同一个尴尬模型写出来的东西看着流畅但经不起核对。让大模型直接写“今天发布的某款新产品”它很可能一本正经地编出一个根本不存在的产品名甚至配上精确到小数点的参数——这就是行业内常说的“幻觉”Hallucination。除了幻觉还有知识过期的问题。大模型的训练数据有截止时间过了那个时间点发生的事情它一概不知道。快讯场景最讲究的就是“快”和“新”一条今天的新闻模型却只能基于几个月前的知识“脑补”结果可想而知。第三个问题是没有可追溯来源。人工写快讯可以注明“据某某报道”但大模型直接生成的内容你找不到出处出了问题没法追责这在内容生产流程里很致命。这三个问题叠加在一起让“拿起模型就写快讯”这条路基本走不通。1.2 先查资料再写稿RAG的核心逻辑RAGRetrieval Augmented Generation检索增强生成的思路一句话就能说清生成之前先检索让模型对着资料写。它的工作流程拆开看是三步把所有原始资料切片、向量化存进一个“向量数据库”收到一条快讯需求或者一条原始线索时先从向量库里检索出最相关的内容片段把检索到的片段和用户问题拼在一起作为上下文发给大模型让模型“开卷答题”。你可以把它理解成开卷考试大模型还是那个模型但手里多了一份参考资料它不再需要凭记忆硬编而是根据查到的内容组织答案。这个“外挂参考书”随时可以增删、替换不需要动模型本身——这正是RAG最灵巧的地方。1.3 对比微调为什么RAG更适合快讯场景做AI应用时很多人会在RAG和微调Fine-tuning之间纠结。我直接给了自己一个判断标准如果知识量不大、更新频繁、对实时性要求高选RAG如果模型风格和说话方式需要长期固定才考虑微调。两条路的核心差异可以看这张表对比维度微调RAG训练成本需要GPU和数据标注成本高无需训练成本低知识更新每次更新都要重新训练直接更新知识库即可事实准确性仍可能产生幻觉有检索依据大幅缓解可解释性弱难以追溯强能回溯到原始资料适用场景固定风格、专业话术高频变化、强时效资讯快讯场景天然是“高频变化、强时效”所以RAG是更匹配的解法。知识库今天加一篇稿子明天更新一篇报道数据库里加几行、删几行就行完全不用碰模型这也是我最终选择RAG而不是微调的根本原因。2. 一条3分钟快讯流水线的整体设计2.1 流水线由哪几个模块组成我搭的这条快讯流水线不算复杂但模块边界要清楚。整体分成九个环节数据采集与清洗文本切片向量化Embedding向量存储与索引查询理解与检索重排Rerank可选Prompt拼装大模型生成后处理与输出。前四个环节是“离线阶段”通常在第一次启动时全部跑一遍之后只做增量更新后五个环节是“在线阶段”每次生成快讯都会走一遍。这样把离线准备和在线生成分开是保证“3分钟出稿”的关键——因为大部分耗时花在离线建索引上真正生成一条快讯时检索和大模型生成都是秒级响应。2.2 数据源和知识库怎么设计快讯系统的知识库本质上是一个“待参考的资料池”。数据源我主要接了这么几类目标领域的RSS订阅、指定网站的更新内容、人工搜集的PDF和Markdown文档。需要注意采集内容时要避开版权风险个人学习和内部演示没问题不要大规模抓取商用。知识库设计上我建议按“领域 时间”双维度打标签。比如每条快讯片段除了正文还带上source来源、published_at发布时间、tags领域标签这几个字段。为什么要带时间因为快讯检索经常需要按时间过滤有了这个字段检索时就能限定“只看最近三天的内容”防止模型翻出一周前的旧闻当新闻引用。2.3 “3分钟”是怎么来的标题说3分钟这里要解释清楚不然会被当成标题党。3分钟指的是端到端的快讯生成时间从一条原始线索进入系统到最终快讯文本输出包含了检索、生成、后处理这些环节。实测下来如果向量库已经建好检索耗时通常在几百毫秒大模型生成一条200字快讯大概需要20到40秒加上前后处理整体确实能压进3分钟。但第一次搭建时建索引那一步不在这3分钟里。比如你要把一万篇历史文档全部切片、向量化这个过程可能要跑几十分钟甚至更久没关系这是离线操作跑一次之后增量更新就很快了。为了进一步压时间我还在系统里加了缓存同一主题的检索结果和生成结果会临时缓存第二次再问直接秒出不用重复调用模型。3. 小白也能复刻的核心环节实现3.1 环境准备我用的是Python 3.9跑在普通开发机上没上GPU。整体依赖也很轻核心就三个向量模型、向量数据库、一个HTTP客户端用来调大模型接口。pip install sentence-transformers faiss-cpusentence-transformers用来加载向量模型faiss-cpu用来做本地向量检索。如果你想把流程串得更顺也可以加一个编排框架但我的建议是第一版别用框架自己写脚本这样每个环节都看得懂出了问题也知道去哪修。3.2 切片与向量化把文档变成坐标向量化的核心任务是把一段文字变成一个固定长度的数字列表。想象一下把每句话投射到一张高维地图上意思相近的句子落点也相近——这就是“语义相似度”的雏形。我自己用的中文向量模型社区里常用的开源方案是BGE系列。加载和编码的代码非常简单from sentence_transformers import SentenceTransformer # 加载中文向量模型 model SentenceTransformer(BAAI/bge-small-zh-v1.5) texts [ 某公司今天发布了新一代AI芯片, 新款芯片的功耗降低了30%, 这家公司同时还公布了开发者计划 ] # 向量化 embeddings model.encode(texts, normalize_embeddingsTrue) print(embeddings.shape) # (3, 512)这里有个细节normalize_embeddingsTrue我会一直开着因为归一化之后向量相似度可以用点积或余弦相似度直接比较后续检索的评分语义更统一。切片策略我会在后面的细节章节展开这里先给一个默认值按段落切每段不超过300字重叠50字。这样既不会让单条片段信息过于稀碎也不会因为太长导致检索命中不精准。3.3 检索与生成从资料到快讯向量库我用了FAISS因为它本地跑、免部署、适合个人项目。建索引和检索的代码如下import faiss import numpy as np # 把编码好的向量转成FAISS需要的格式 embedding_dim embeddings.shape[1] index faiss.IndexFlatIP(embedding_dim) # 内积索引配合归一化向量等同于余弦相似度 index.add(embeddings) # 模拟一条检索请求 query 帮我了解一下今天某公司发布的AI芯片详情 query_vec model.encode([query], normalize_embeddingsTrue) # 检索最相关的3个片段 scores, indices index.search(np.array(query_vec), k3) print(indices)检索出的片段不能直接丢给模型得先拼成一个结构清晰的Prompt。我的Prompt模板长这样你是一名快讯编辑请根据以下资料生成一条200字以内的AI行业快讯。 要求 - 只引用资料里的事实不得编造数据、人名、时间 - 输出格式为标题 | 正文 | 关键词 - 如果资料与问题不相关直接回复“资料不足”。 资料 {检索到的片段} 问题{用户的需求}这里的关键是“只引用资料里的事实”这句话它是在给模型设定边界。与其指望模型“自觉不撒谎”不如在Prompt里明确告诉它“没有资料就别说”。拼好Prompt之后调用大模型API就能得到结果。为了通用性我用伪代码表示这层调用def call_llm(prompt, max_tokens300): # 这里填你使用的大模型接口地址和密钥 response requests.post( https://你的模型接口地址, headers{Authorization: Bearer YOUR_API_KEY}, json{prompt: prompt, max_tokens: max_tokens} ) return response_json_to_text(response)实测下来接口调用这一步是整条链路中最耗时的但单次也就几十秒完全可以接受。3.4 加一个简单调度让它自动跑“3分钟生成”要真正落地不能每次都手动跑脚本。我在外层套了一个简单的轮询循环对新进入的原始线索做增量处理import time watch_folder data/incoming/ while True: new_files scan_folder(watch_folder) # 扫描新文件 for file in new_files: content read_file(file) chunks split_text(content) embeddings model.encode(chunks, normalize_embeddingsTrue) index.add(embeddings) # 同时触发一次快讯生成任务 generate_news(chunks) move_to_archive(file) time.sleep(60) # 每分钟检查一次这个循环只是一个可运行的最小版本。生产环境建议用系统的定时任务比如cron或者轻量级任务队列避免脚本挂在终端里。但对个人演示和小团队内部工具来说上面这个循环已经足够实用。4. 决定快讯质量的七个关键细节4.1 Embedding模型怎么挑很多初学者栽在第一步随便选了一个向量模型发现检索结果一塌糊涂。选模型看三点语言适配度、向量维度、推理速度。中文场景优先选中文本优化过的模型英文模型处理中文时语义距离会扭曲。向量维度影响内存和速度128维快但表达有限768维更准但更占资源。BGE-small这类模型大概是512维实测在普通开发机上跑得动检索效果也够用。如果你面对的是英文内容也可以考虑社区里常用的英文向量模型但核心原则都一样先在你的小数据集上跑几个候选看谁的检索结果更符合直觉别只看榜单分数。4.2 切片大小与重叠区间怎么定切片是RAG里最容易被低估的环节。切片太大一个片段里包含太多主题检索时命中点不精确切片太小语义不完整模型看到的信息支离破碎。我实测下来中文字符按200到400字切片比较稳妥重叠50字左右。重叠的意义在于如果一句话恰好被切片边界从中间截断前后两个片段都能包含它检索时不会漏。还有一条经验尽量按段落和标题切避免把语义完整的段落硬生生拆断。如果你输入的原始文档有Markdown标题可以先用标题作为切分边界再往下细分。这个小改动能让检索准确率有明显提升。4.3 混合检索和重排要不要上纯向量检索有一个盲区它擅长找“意思相近”的内容但不擅长精确匹配关键词。比如你要找产品名“星云-2”向量检索可能因为语义接近把“星云-1”的内容也搜出来。解决方法是做“混合检索”向量检索跑一遍关键词检索BM25跑一遍再把两路结果合并。合并之后最好再加一个重排层Rerank用一个交叉编码器模型对候选片段重新打分把真正相关的排到最前面。但我要提醒一句不要一上来就堆重排。个人项目数据量没到上万条时单个向量检索足够用重排会增加延迟和部署成本。我的建议是先不加等发现检索结果明显不靠谱时再按“混合检索 → 重排”的顺序逐步加。4.4 Prompt模板的正确写法Prompt是RAG里真正决定生成质量的部分。我踩过几次坑之后总结了四个要点明确角色和任务让模型扮演“快讯编辑”行为边界更清晰给出输出格式指定“标题 | 正文 | 关键词”避免模型自由发挥禁止编造写清楚“不得编造数据、人名、时间”这是幻觉的最后一道防线设置拒绝条件告诉它“资料不足时直接回复资料不足”防止没相关材料时强行回答。另外Prompt里检索片段和原始问题的顺序也有讲究。我习惯把资料放前面、问题放后面中间用分隔符隔开这样模型在生成时能优先关注到上下文。4.5 Top-K与相似度阈值怎么配Top-K控制每次检索返回几个片段。快讯这种短文本生成场景我推荐k3到k5。K太小信息不够K太大会往Prompt里塞大量无关噪音反而干扰生成。相似度阈值是很多人忽略的参数。向量检索不管相不相关都会返回Top-K结果哪怕所有片段都不相关。所以我在代码里加了一个判断如果最高相似度分数低于0.5就视为“资料不足”不再调用大模型直接返回提示。这个阈值可以拿历史数据调试落到0.4到0.6之间比较常见。4.6 缓存与更新策略快讯生成是重复性很高的任务同一主题可能会被反复查询。缓存机制能省下大量API费用和等待时间。我用了一个很简单的字典缓存把“查询内容”哈希后作为Key保存对应生成结果和时间戳。第二次遇到同样的查询直接返回缓存不再调API。缓存的过期时间我设成30分钟兼顾实时性和成本。知识库更新方面增量添加新片段非常简单直接index.add()编码结果就行但删除和修改旧片段要麻烦一些需要重建索引。我的建议是文档量大时就定期全量重建一次文档量小就直接rebuild免得维护复杂的删除逻辑。4.7 失败重试和成本控制调用大模型API网络抖动和限流几乎一定会遇到。我在调用层加了简单的重试机制失败后等待2秒重试最多3次再失败就把任务丢进一个失败队列人工检查。成本控制上有两个亲测有效的技巧。第一是尽量用较短输入输出的轻量模型快讯本身短小不需要用超大模型第二是缓存命中率做好之后API费用能降一半以上。我做了一个粗略统计缓存开启后每天的快讯生成成本大约是原来的四成效果非常明显。5. 高频故障与排查手记5.1 检索结果和主题完全无关这是我第一次跑通系统后最常遇到的问题。排查思路按下面顺序来先确认向量模型选的合不合适中英匹配问题最常见再看切片是不是太大导致一个片段混杂多个主题最后看查询方式如果只有向量检索可以试一下加上关键词检索看召回是否有提升。我自己的案例里问题出在切片上原始文档是两篇报道混在一个大段落里明明问的是A产品检索结果却把B产品的段落整个返回了。按段落重新切分之后问题立刻消失。5.2 生成结果还是出现幻觉如果Prompt已经写了“不得编造”模型还是编通常说明检索给了错误素材或者素材里有互相矛盾的信息。我建议做一次“可追溯检查”把模型生成结果的每个关键数据点数字、人名、时间手动比对照回原始片段。如果数据点确实都是来自片段但组合起来是错的说明切片的上下文不完整需要调大切片尺寸或增加重叠。如果数据点在片段里根本不存在说明Prompt约束还不够强可以试试把“根据以上资料”改成“只能使用资料里出现的原文数字不得推算”。5.3 出稿速度比预期慢很多原本说好3分钟实际跑了10分钟最常见的原因是生成长度设置太大。快讯正文只有200字但如果你把max_tokens设成1024模型会在那里“思考”很久。第二个常见原因是单次请求把好几条快讯任务串起来调用模型生成长度翻了好几倍。我的做法是生成一条快讯只调用一次模型绝不在一个Prompt里塞三个标题让它一起写。还有一个原因是没有开缓存重复内容在反复烧时间烧钱开完缓存立刻好转。5.4 知识库更新后检索结果没变化这个坑很隐蔽你以为已经index.add()了新数据但检索结果还是旧片段。原因通常是路径问题——增量更新的代码片段里读取的是旧文件夹或者FAISS索引对象是在旧内存里创建的重启后没有重新加载。排查步骤代码里打印一下索引的总条目数和最后一条向量对应的原始文本确认新数据真的进去了。如果进去了还是搜不到大概率是查询向量和新增片段向量不在同一个语义空间比如用了两个不同的Embedding模型混着编码。5.5 接口调用成本一个月就超预算个人项目最怕API账单爆掉。我的经验是分三步走先看重复请求占比开缓存消灭重复再检查检索Top-K是不是太大K10的输出Token消耗比K3大得多最后把模型切换成更便宜的小模型快讯任务用轻量模型完全能扛住。还有一个容易被忽略的点调试阶段频繁调用接口试Prompt也会产生大量费用。我后来习惯先在本地找一个免费模型跑通流程再切到线上API做最终效果验证成本明显下降。最后再分享一点实际体会。这套系统真正花时间的地方不是写代码而是调数据、调Prompt、调切片参数。第一次全部跑通、看到生成快讯比人工整理还规整时确实很有成就感。我的建议是别一开始追求复杂架构先把数据洗干净、切片做合理、检索调准这三件事做好了整个系统的效果就稳了。想继续玩的话后面还能往多个数据源接入、自动去重、跨语言快讯这些方向扩展每一步都不难关键是先把基础链路跑起来。