RAG

OpenAI 官网 10 月 6 日的更新列表里，一条和 Atlassian 的深化合作被不少人略过，却值得拎出来看：双方将把前沿模型接入 Jira、Confluence 这套企业团队每天离不开的系统，帮团队做规划、开发和交付。表面上这又是一个「模型接入办公软件」的常规合作，但它真正的看点在于——企业里那些沉睡在工单、文档、wiki 里的知识，第一次被一个顶级前沿模型正式认领了。 Atlassian 接 OpenAI 为什么不只是一次普通合作？ 大多数企业的知识根本不在对话框里，而是散落在成千上万张 Jira 工单、Confluence 页面、代码评审记录里。员工想查一个历史决策，往往要在系统里翻半天，还不一定找得到。OpenAI 直接和 Atlassian 合作，等于绕过了「让员工自己复制粘贴进 ChatGPT」这一步，让模型在企业知识的原生位置上回答问题。 这背后其实是 RAG（检索增强生成）在企业级的成熟落地：模型不凭空回答，而是先从 Confluence、Jira 里检索出相关上下文，再生成答案。问答的可信度，取决于企业自己沉淀的知识质量，而不是模型的训练数据。 这件事对企业 IT 意味着什么？ 对项目经理：不用再去问「这个需求当初为什么这么定」，直接问模型，它会引用相关工单和决策记录。 对新员工：入职第一周想搞懂团队历史，比翻 wiki 快得多。 对知识管理：企业会突然意识到，自己 wiki 里那些烂尾、过时、互相矛盾的页面，正在变成模型回答错误的源头——知识治理从「 nice to have」变成了「必须做」。 接了最强模型，企业知识就一定靠谱吗？ 需要清醒的是，这类合作的实际效果，高度取决于企业自己的知识卫生。如果 Confluence 里全是过期文档和重复工单，接再强的模型也只会一本正经地胡说。模型只是放大器，放大的是企业已有的知识资产——干净的放大成效率，混乱的放大成错误。Atlassian 和 OpenAI 这次合作，真正卖的不是模型，而是「把你已有的知识用起来」。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Atlassian OpenAI

RAG 项目最常见的状态是：演示时效果惊艳，上线后用户总说「它有时候瞎编」。问题出在没人量化它——你知道它有时错，但不知道错在「检索没找到」还是「生成没照着检索」。Ragas 这个评测框架就是给 RAG 做体检的：它把系统拆成检索与生成两段，分别打分。 四个核心指标怎么读 Faithfulness（忠实度）：回答里的每一个论断，能不能在检索回来的上下文里找到依据。这个分低，就是模型在脱离材料编造——幻觉问题出在生成端。 Answer Relevancy（回答相关性）：回答有没有真正回应问题。问东答西，这个分就掉。 Context Precision（上下文精度）：检索回来的片段里，相关的是不是排在前面。 Context Recall（上下文召回）：该被找到的信息，到底找回来了多少。 关键在于：Faithfulness 低是生成问题，Context Recall 低是检索问题。两个问题的修法完全不同——前者改提示词、换更强的生成模型，后者要补数据、调分块、改检索。不打分，你连该修哪头都不知道。 怎么落地 准备几十条带标准答案的问答对（从真实用户问题里挑），用 pip install ragas，把问题、检索片段、回答喂进 evaluate()，它就能出这几项分数。之后每次改分块策略、换 embedding 模型，跑一遍对比，数值升降一目了然。 判断 RAG 的下一步不是「再接一个 reranker」，而是「先知道自己哪里差」。没有指标的优化是许愿。把 Ragas 接进迭代流程，让每一次改动都有分可看，RAG 才从「感觉不错」变成「能被验收」的工程系统。 补一个操作细节：评测本身也要花 token。Ragas 用一个模型当裁判去打分，几十条样例跑一次就是一笔小开销。建议把评测安排在夜间批量跑，别挂进实时请求链路——它是体检工具，不是运行时组件。分数趋势稳定后，甚至可以只在改了关键配置时才跑全量，平时抽查即可。 没有指标的优化是许愿，有了分数，RAG 才能从「感觉不错」变成「可被验收」。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：RAG评估

RAG 项目做到后面，往往不是「检索一次然后生成」这么简单——要先判断问题类型，事实类走向量检索，计算类走代码工具，拿不准的再走多路召回，最后汇总。用一串 if/else 加函数调用写，三个分支之后就没人敢改了。LlamaIndex 的 Workflows 模块就是给这种复杂度准备的：它把流程拆成「事件」在节点间流动，每个节点是一个被装饰器标记的异步函数。 心智模型 不用记太多，抓住两个概念： Event（事件）：在节点之间传的数据对象，比如 QueryReceived、RetrievalDone、ResponseReady； Step（步骤）：一个异步函数，用 @step 标记，声明它监听哪些事件、又发出哪些事件。 框架帮你做的是并发调度：多个步骤可以同时跑，事件到了就触发。比起手写 asyncio.gather 加回调，这种声明式写法让流程拓扑一眼看清。 一个多分支问答的骨架 @step async def route(self, ev: QueryReceived) -> Union[RetrieveFactual, RunCalculator]: kind = await classify(ev.query) if kind == 'fact': return RetrieveFactual(query=ev.query) return RunCalculator(query=ev.query) 检索和计算两个步骤并行监听各自事件，跑完都发出 ContextReady，再由汇总步骤合并成最终回答。新增分支，就是加一个事件类和一个步骤函数，不用动老代码。 判断 事件驱动框架的好处在「可观测」：每个事件是一条明确的边界，配合日志你能知道流程卡在哪一步。对那些已经从单轮 RAG 长出来、但还没复杂到要上重型编排引擎的团队，Workflows 是一个比 LangGraph 更轻的中间档——它不抢你的控制权，只把流程显式化。 补一个心智提醒：事件驱动不是银弹。流程只有两三个节点时，写 Workflows 反而比直接 async 更啰嗦。它的甜区是「四五个分支、要并发、要可观测」的中等复杂度。如果你只是线性检索加生成，别为了用框架而用框架——直接函数调用最清楚，也好调试。 框架是手段，把流程画清楚才是目的。别让工具本身，变成新的复杂度来源；分支少的时候，最朴素的函数调用，反而是最不容易出错、最好调试的选择。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：LlamaIndex

问题：闭卷模型的知识有三个死穴 纯生成式大模型闭卷答题，知识全部冻结在训练那一刻的权重里。这带来三个硬伤：一是过时，训练截止之后的事它不知道；二是幻觉，它会一本正经编造没见过的事实；三是不可溯源，你不知道它的答案从哪来。要让模型掌握私有、实时、可引用的知识，靠重新训练或微调既慢又贵。RAG（Retrieval-Augmented Generation，检索增强生成）给出了另一条路：不把知识塞进权重，而是在生成时临时去外部知识库「开卷」查资料，再基于查到的内容作答。 方法：先检索，再生成 Lewis 等人 2020 年的原始论文把这个过程拆成两步。第一步，给定问题，用一个检索器（早期是 DPR，基于稠密向量相似度）从文档库里召回若干最相关的片段。第二步，把这些片段连同问题一起塞进生成模型的上下文，让模型基于这些证据组织答案。论文证明，把检索结果当作额外知识注入，在开放域问答上显著优于纯参数化模型，而且答案能指回具体来源。 为什么它在工程界火到今天 原始论文是学术原型，但 RAG 的思想在 2023 年后被工程界发扬光大，成为企业落地大模型的标配。原因很实在：知识库可以随时增删改——新文档进来，只要加进索引即可，不用重训模型；答案带引用，出了错能查到是哪份文档的问题；私有数据不用进训练集，只在检索时可见，隐私边界更清晰。今天的 RAG 系统已经演化出混合检索（向量加关键词）、重排序（rerank）、分块策略、查询改写等一整套工程技巧，核心仍是「检索给证据，生成来作答」这个闭环。 结论与局限 RAG 的结论是：把实时、可溯源的外部知识与生成能力解耦，是比死记硬背更可持续的知识接入方式。它大幅缓解了幻觉与时效性问题。但它不是万能药——检索不到相关文档时，模型照样会瞎编；分块切得不好，证据残缺；长上下文塞不下所有召回内容，又要做取舍。所以 RAG 的效果上限，往往不取决于生成模型多强，而取决于检索、分块、重排这套前端工程做得多细。 收束 RAG 的洞见是：与其期望模型把一切都背下来，不如让它学会查资料。这恰好契合「知识在权重之外持续更新」的现实。对企业而言，一套做得扎实的 RAG，性价比远高于反复微调——把知识库维护好，比把模型喂胖，更能解决真实业务问题。 去论坛讨论 关于「RAG」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。

「塞得下」不等于「用得好」 模型标称 128K、甚至 1M 上下文，听上去一份 100 页文档直接整份喂进去就行。但实测打脸：上下文拉满时，模型对中间部分内容的注意力会明显下降——开头和结尾记得清，夹在中间的关键信息它常常视而不见，这就是所谓「lost in the middle」。同时，上下文越长，KV Cache 占用越大、推理越慢、成本越高。所以长文档处理的正确思路，从来不是「把窗口撑满」，而是「想办法只喂相关的那几段」。 两条成熟路线 路线一：切块 + 检索（回到 RAG）。 这正是前面几篇讲的 RAG 思路：把 100 页文档切成 500-800 token 的块，embedding 存库，用户提问时只召回最相关的 3-5 块喂给模型。上下文始终保持在几 K，又快又准。这是处理「要在文档里反复问答」的正解，别因为模型窗口大了就放弃它。 路线二：分层摘要。 当任务不是问答，而是「通读全文写总结」时，用分层摘要：先把文档切成段，每段让模型生成一段小结；再把这些小结拼成一份「中段文档」，让模型二次摘要；需要的话再叠一层。这样即便原文有几十 K，真正进最终模型上下文的只是层层浓缩后的精华，既省 token，又避免了中间内容被淹没。 方式 适合任务 上下文占用 准确度 整份塞进去 极短文档、整体浏览 巨大、慢 中间易丢 切块 + 检索 文档问答 小、快 高 分层摘要 长文通读总结 层层浓缩 较稳 三个实操要点 第一，别迷信标称窗口：官方标称 128K，实际稳定好用的可能只有一半，长上下文的有效利用率随长度衰减，按经验留足折扣。第二，关键信息放两头：如果必须把大段内容塞进去，把最重要的指令和结论放在提示词的开头和结尾，中间放次要材料——利用它对两头敏感的特性。第三，本地模型的长上下文更吃显存：前面算过，KV Cache 随上下文长度线性涨，本地跑 32K 以上要留足显存余量，否则不是「答不好」而是直接 OOM。 收束 长上下文是个好工具，但不是让你偷懒把文档一股脑塞进去的借口。真要在长文档上做问答，切块检索最稳；要通读总结，分层摘要最省。记住「lost in the middle」这个坑——窗口越长，越要克制喂进去的东西。会取舍上下文，才是用好大模型的真功夫。 去论坛讨论 关于「长上下文」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。

召回准，不等于排序准 混合检索把候选召回了，但有个致命问题：向量相似度是双向独立编码——query 和文档各自先变成向量，再算距离。这种方式快，但它没法精细判断「这份文档到底答没答这个问题」。Top-20 里经常混着几条主题接近、实则答非所问的 chunk，大模型把它们一起读进去，就容易被带偏。解决办法是在召回之后加一道重排（rerank）：用交叉编码模型把 query 和每篇候选拼在一起，让模型直接打一个相关性分数，再按分数重排取 Top-3 或 Top-5。 为什么用 bge-reranker 重排模型里，Cohere Rerank 是商业服务里最成熟的，但要按调用量付费、数据要出域。国内生产环境更常用的是开源的 bge-reranker 系列（智源 BAAI 出品）：bge-reranker-v2-m3 支持中英文多语言，参数约 568M，单张消费级显卡就能跑；更小的 bge-reranker-base 约 278M。它和 embedding 模型同源，配 bge-m3 做向量召回、bge-reranker-v2-m3 做重排，是一套经过大量生产验证的组合。 环节 模型 作用 量级 召回 bge-m3（1024维） 语义+稀疏双路 百万条索引 重排 bge-reranker-v2-m3 query-doc 交叉打分 只对 Top-20 逐条算 关键认知：重排只对召回后的小候选集（20-50 条）逐条打分，不用对全库算，所以慢一点也无所谓——交叉编码比向量检索慢，但调用量小，整体延迟通常增加 100-300ms，换来的是 Top-5 准确率显著上升。 三个实操参数 第一，重排后取 Top-3 到 Top-5 喂给大模型：别贪多，上下文里塞 8 条文档反而稀释注意力，3-5 条最相关的效果往往更好。第二，设置分数阈值：bge-reranker 输出的 logits 过 0 大致算相关，可以把分数低于阈值的候选直接丢掉，避免硬塞不相关内容。第三，GPU 批处理：transformers 加载时用 torch_dtype=torch.float16、批推理，20 条候选一次算完；没有独显就用 ONNX Runtime CPU 版，慢但够用。LlamaIndex 里直接挂 SentenceTransformerRerank，几行代码接上。 ...

纯向量检索的坑 很多人搭 RAG，第一步就踩坑：把文档切块、扔进 embedding 模型、存进向量库，查询时相似度 Top-K 拉出来就喂给大模型。问题是向量检索擅长语义相似，却对精确匹配天生迟钝——零件编号、合同条款编号、API 函数名、报错信息、英文缩写这类东西，语义上和查询「差不多」，但向量距离拉不开，很容易把该召回的那条挤到 Top-20 之外。这也是为什么很多 RAG 演示很好看、一上真实知识库就答非所问。 混合检索：两条腿走路 正确做法是双路召回：一路 BM25（关键词稀疏检索，Elasticsearch、OpenSearch、MeiliSearch 都内置），一路 dense 向量检索。两路各取 Top-20，再用 RRF（Reciprocal Rank Fusion，倒数排名融合）合并成最终 Top-5。RRF 公式很简单：每条文档的得分等于 Σ 1/(k+rank)，k 常取 60，不需要调权重，比手工加权稳得多。 检索方式 擅长 短板 BM25 关键词 编号、专有名词、代码、报错 同义改写召回差 Dense 向量 语义同义、模糊提问 精确匹配弱 混合 + RRF 两者兼顾 多一路索引，工程量翻倍 LangChain、LlamaIndex 都内置了 EnsembleRetriever /混合检索模块，Qdrant 从 1.10 版起原生支持稀疏向量混合检索，不用再维护两套数据库。 三个实操建议 第一，切块别一刀切：正文按 500-800 token 切，代码块、表格单独成块并打上 metadata（来源、章节、文档类型），检索时按 metadata 过滤比切块大小更影响质量。第二，K 值要留余量：双路各取 Top-20、融合后重排取 Top-5，别一路只取 Top-5——融合的前提是两路都有足够候选。第三，用真实提问集回归测试：准备 20-30 条业务高频问题，标注标准答案出自哪一段，每次改切块、改 embedding、改 K 值都跑一遍召回命中率，比凭感觉调参靠谱。 收束 混合检索不是锦上添花，是生产 RAG 的及格线。关键词路保精确，向量路保语义，RRF 把两路排到一起——这套组合在绝大多数企业知识库场景里，都比纯向量检索召回率高出一截。下一步真正值钱的，是在混合召回之后再接一层重排，那是下一篇要拆的事。 ...

幻觉的根源 模型生成时在概率空间采样，高概率但不一定正确。尤其在：编造数据、混淆事实、过度自信。 10种缓解方法 检索增强类 RAG检索+引用来源 知识图谱约束 工具调用验证（计算器、数据库、API） 提示词类 明确不知道就说不知道 要求给出推理过程 提供参考示例 工程类 温度降低（0.1-0.3） 多次采样投票 后置校验（规则引擎检查格式/数据） 置信度阈值（低置信度转人工） 关键认知 幻觉无法100%消除，但可以大幅降低。高风险场景必须有人工审核兜底。

生产级RAG架构 数据层 文档解析（PDF/Word/网页） 分块策略（语义分块 vs 固定分块） 元数据标注 检索层 混合检索（向量+关键词+BM25） 重排序（cross-encoder） 查询改写 生成层 提示模板设计 引用来源标注 答案校验 评估层 检索命中率 答案准确率 引用正确性 常见坑 分块太小丢上下文，太大噪声多 单一向量检索效果差，要混合 没有评估就上线，等于盲飞 建议 从简单开始，逐步加组件。每次改动都要有评估数据支撑。

三代RAG 1.0 朴素RAG 向量检索+拼接上下文，简单粗暴。 2.0 混合RAG 向量+关键词+重排序，准确率大幅提升。 3.0 Agentic RAG Agent自己决定：要不要查、查什么、查到之后怎么整合。甚至会交叉验证多个来源。 2026年的实践 查询改写：自动把用户问题改写成更好的搜索词 多跳推理：先查A，根据结果再查B 自我评估：检索结果不好会自动换关键词重查 工具组合：不只是查文档，还会调用API和数据库