窗口外的知识Agent 答案质量另一半的九个工程问题系列导航本篇00 · 01 四类知识分层 · 02A 解析五环 · 02B 断裂修复 · 03 切分标定 · 04 查询理解 · 05 混合检索与重排 · 06 引用验证 · 07 知识新鲜度 · 08 多源一致性 · 09 检索管道门禁小提一句 由于平台每日发布笔记数量限制目前系列笔记还没全部上传。后续内容会持续更新大家可以先点个关注、收藏以免错过。谢谢引子答案不稳第一反应是换模型Agent 上线第三周值班人员丢过来一条「问同一个告警上午让我扩容下午让我回滚。」第一反应是模型不稳——换个更强的。换完第二天又来一条「引用的 runbook 编号 RB-214翻过去是讲磁盘清理的。」两条都不是模型问题。第一条是两个知识库对同一件事说法相反检索分数高的那个恰好先到第二条是答案里的引用根本没被验证过编号是模型顺着语气编的。模型、提示词、上下文压缩全都没动坏掉的东西在窗口外——Agent 取回来的那批知识。这个位置很尴尬它不在 prompt 里不在模型里也不在 Agent 的循环里所以大多数排查清单上都没有它。答案质量 ≈ 推理质量 × 知识质量而知识质量这一因子在生产里几乎没人度量。本文给出这个簇要解决的九个知识侧工程问题以及它们之间的依赖顺序。一、答案不稳的三类知识根因分别长什么样把「答案不稳」拆到知识侧落到生产里基本是三类而且排查路径完全不同。根因现场症状为什么难发现落在本簇哪篇取错了分层/召回答非所问或者答的是三个月前的版本返回的片段语法通顺、语气确定看起来就是「查到了」01 / 04 / 05取坏了解析/切分该召回的片段永远排不到前面或者召回了半截解析器不报错切分器也不报错输出一直是「正常的文本」02A / 02B / 03不敢信引用/时效/冲突有出处但出处不对两个库答案相反答案过期只有拿权威源逐条比对才暴露用户投诉前静默06 / 07 / 08第三类里最麻烦的是「过期但没错」和「过期且已错」混在一起——前者只需标注后者必须立刻下架而检索层给不出这个区分07。一条经验判据如果同一批问题里准确率波动随知识库版本变化而不是随模型版本变化那问题在窗口外。二、九篇文章的依赖关系重建索引需重跑01 四类知识分层判据02A 解析五环质量四尺02B 断裂检测修复三招03 切分标定跨度反推04 查询理解改写收益05 混合检索与重排06 引用验证对齐回路07 知识新鲜度时效巡检08 多源一致性显式仲裁09 检索管道门禁回归与回滚主线是知识从哪来 → 进来时丢什么 → 怎么取 → 取得准不准 → 敢不敢信 → 过期了怎么办 → 管道坏了怎么修。09 那条虚线是回边索引重建之后03 的切分标定要重跑一次因为块边界变了。编号标题本篇解决什么程序难度01RAG 效果差八成是知识放错了层四类知识的分层判据与迁移顺序knowledge_layers.py★★☆02A文档解析丢的不是字是结构管线五环的损失形态 质量四把尺子parse_quality.py★★★02B表格被拉平、段落被切断五条断裂检测规则 三招修复parse_repair.py★★★03块大小别再写 512用问题信息跨度反推切分参数chunk_eval.py★★☆04用户问的和文档写的不是一回事差距分类 改写什么时候是净收益query_rewrite.py★★☆05混合检索与重排值不值那 200ms三路合流的漏召诊断与融合实现hybrid_search.py★★★06未经验证的引用比没引用更危险断言-证据对齐回路与三档降级cite_verify.py★★★07过期知识不会报错时效元数据 三路巡检 处置三档freshness_probe.py★★★08两个知识库答案相反时听谁的冲突三形态 显式仲裁策略conflict_policy.py★★★09检索管道也要发版回归门禁 索引双版本 回滚 runbookretrieval_gate.py★★★三、三条阅读路线路线 A · 答案不稳先定位推荐起点01 判断知识是不是放错了层 → 05 看召回有没有漏 → 06 看出处是不是真的 → 08 看是不是两个库打架。四篇读完能覆盖上面表格里「取错了」和「不敢信」两类根因。路线 B · 要省钱先砍浪费01 把不该进检索的知识迁出去这一条的收益通常是最大的→ 03 重定块大小直接压索引体积与 token→ 05 判断重排是不是在为 1pp 准确率付 3 倍延迟 → 09 给管道上门禁避免反复重建索引。路线 C · 要合规先补可溯源06 引用验证回路 → 07 时效元数据与巡检 → 08 冲突登记与仲裁记录 → 09 变更留痕与回滚。这四篇的产物都是可审计的对齐判定记录、巡检记录、仲裁记录、回归报告。三条路线共享 02A / 02B——解析和切分是所有路线的地基坏了的话上面怎么调都不稳。四、统一约定贯穿案例OpsAgent 的知识来源有五处全簇共用源内容规模 ⚠️ 构造示例归哪一层topo_docs服务拓扑文档Confluence 导出 PDF/HTML12,000 条目检索知识incidents历史故障复盘记录800 条记忆属记忆主题本簇只从取用侧提一句runbooks处置手册含表格与截图300 份检索知识Prometheus当前 CPU / 错误率 / QPS实时工具知识SLO 口径 / 告警分级标准稳定业务规则约 20 页—上下文知识评测集opsqa-200200 条真实值班问题每条标了正确处置动作与应命中的证据片段 id。工具集prom_query(metric, range)/get_runbook(id)/list_services()。实验纪律每篇都要给三层检索层召回率、精确率、命中片段排序下游层任务准确率本簇用opsqa-200的处置动作命中率成本层单次 token 与 P95 延迟。三者必须与「不上这个机制」的基线对照。只有中间指标变好不算数——召回到了但答案变差是常见结果。数字标签[算]可现场推导 ·[公开]带三要素版本 / 抓取日期 / 数据规模 ·[实测]留空待跑结果落results/编号.csv。凡是没有出处的推断数字一律标 ⚠️ 经验值并说明缺什么。图码约定每篇 3 张 Mermaid流程 / 结构 / 数据流首个流程图在正文 35% 之前。代码一律零依赖内核Python 标准库 两个可替换适配口embed(text) - list[float]与async def llm(prompt) - str。术语表各篇口径一致术语定义四类知识参数模型权重里/ 上下文随 prompt 注入/ 检索按需从外部库取/ 工具调 API 现取块内完整率单个块已包含回答某问题所需全部信息的比例跨块断裂率回答某问题所需信息被切到两个及以上块的比例无感损失 / 有感损失解析丢信息但解析器不报错 / 会报错能被立刻发现断言-证据对齐答案拆成独立断言后逐条验证是否有证据片段支撑引用失真率指向不存在片段 / 片段不支撑 / 支撑但被截断 / 张冠李戴四类分别计过期存活时长从条目实际过期到被系统发现的时长结论跳变率同一问题两次查询给出不同结论的比例回归检出率注入的退化被门禁抓住的比例七、系列内脚本程序表编号脚本跑通需要什么最小验证01knowledge_layers.py一份知识清单JSONL输出四层落点建议 放错层的告警02Aparse_quality.py20 篇自己的真实文档输出四把尺子得分02Bparse_repair.py02A 的块流输出输出断裂标记 修复前后四尺子对比03chunk_eval.py02B 的块流 20 条标注问题输出跨度分布与推荐块大小04query_rewrite.py查询日志含原查询与点击输出差距分布 改写后的约束丢失率05hybrid_search.pyembed()适配口 倒排表输出三路召回的漏召诊断06cite_verify.py答案 候选片段输出断言-证据对齐判定记录07freshness_probe.py条目时效元数据输出过期标记与处置建议08conflict_policy.py多源候选集输出冲突对与仲裁结果09retrieval_gate.py新旧两套索引 固定问题集输出回归报告与切流建议适用边界本簇基于 Python 3.x / 2026-Q4 的检索与模型能力涉及向量库、embedding 模型与文档解析工具的行为以各自官方文档为准。参考Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks本簇「知识质量是独立因子」这一立论的起点Seven Failure Points When Engineering a RAG System三类知识根因的分类参照Lost in the Middle: How Language Models Use Long Contexts「取坏了」为什么在下游才暴露的依据Retrieval Augmented Generation or Long-Context LLMs?本簇坚持「窗口外知识」而非「塞进长上下文」的取舍依据Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs01 分层判据中「参数知识」一层的定位 
长河君 · 2026/10/30 7:35:29 · 阅读 1.2k SA-K-00 知识与检索工程 系列导航
窗口外的知识Agent 答案质量另一半的九个工程问题系列导航本篇00 · 01 四类知识分层 · 02A 解析五环 · 02B 断裂修复 · 03 切分标定 · 04 查询理解 · 05 混合检索与重排 · 06 引用验证 · 07 知识新鲜度 · 08 多源一致性 · 09 检索管道门禁小提一句 由于平台每日发布笔记数量限制目前系列笔记还没全部上传。后续内容会持续更新大家可以先点个关注、收藏以免错过。谢谢引子答案不稳第一反应是换模型Agent 上线第三周值班人员丢过来一条「问同一个告警上午让我扩容下午让我回滚。」第一反应是模型不稳——换个更强的。换完第二天又来一条「引用的 runbook 编号 RB-214翻过去是讲磁盘清理的。」两条都不是模型问题。第一条是两个知识库对同一件事说法相反检索分数高的那个恰好先到第二条是答案里的引用根本没被验证过编号是模型顺着语气编的。模型、提示词、上下文压缩全都没动坏掉的东西在窗口外——Agent 取回来的那批知识。这个位置很尴尬它不在 prompt 里不在模型里也不在 Agent 的循环里所以大多数排查清单上都没有它。答案质量 ≈ 推理质量 × 知识质量而知识质量这一因子在生产里几乎没人度量。本文给出这个簇要解决的九个知识侧工程问题以及它们之间的依赖顺序。一、答案不稳的三类知识根因分别长什么样把「答案不稳」拆到知识侧落到生产里基本是三类而且排查路径完全不同。根因现场症状为什么难发现落在本簇哪篇取错了分层/召回答非所问或者答的是三个月前的版本返回的片段语法通顺、语气确定看起来就是「查到了」01 / 04 / 05取坏了解析/切分该召回的片段永远排不到前面或者召回了半截解析器不报错切分器也不报错输出一直是「正常的文本」02A / 02B / 03不敢信引用/时效/冲突有出处但出处不对两个库答案相反答案过期只有拿权威源逐条比对才暴露用户投诉前静默06 / 07 / 08第三类里最麻烦的是「过期但没错」和「过期且已错」混在一起——前者只需标注后者必须立刻下架而检索层给不出这个区分07。一条经验判据如果同一批问题里准确率波动随知识库版本变化而不是随模型版本变化那问题在窗口外。二、九篇文章的依赖关系重建索引需重跑01 四类知识分层判据02A 解析五环质量四尺02B 断裂检测修复三招03 切分标定跨度反推04 查询理解改写收益05 混合检索与重排06 引用验证对齐回路07 知识新鲜度时效巡检08 多源一致性显式仲裁09 检索管道门禁回归与回滚主线是知识从哪来 → 进来时丢什么 → 怎么取 → 取得准不准 → 敢不敢信 → 过期了怎么办 → 管道坏了怎么修。09 那条虚线是回边索引重建之后03 的切分标定要重跑一次因为块边界变了。编号标题本篇解决什么程序难度01RAG 效果差八成是知识放错了层四类知识的分层判据与迁移顺序knowledge_layers.py★★☆02A文档解析丢的不是字是结构管线五环的损失形态 质量四把尺子parse_quality.py★★★02B表格被拉平、段落被切断五条断裂检测规则 三招修复parse_repair.py★★★03块大小别再写 512用问题信息跨度反推切分参数chunk_eval.py★★☆04用户问的和文档写的不是一回事差距分类 改写什么时候是净收益query_rewrite.py★★☆05混合检索与重排值不值那 200ms三路合流的漏召诊断与融合实现hybrid_search.py★★★06未经验证的引用比没引用更危险断言-证据对齐回路与三档降级cite_verify.py★★★07过期知识不会报错时效元数据 三路巡检 处置三档freshness_probe.py★★★08两个知识库答案相反时听谁的冲突三形态 显式仲裁策略conflict_policy.py★★★09检索管道也要发版回归门禁 索引双版本 回滚 runbookretrieval_gate.py★★★三、三条阅读路线路线 A · 答案不稳先定位推荐起点01 判断知识是不是放错了层 → 05 看召回有没有漏 → 06 看出处是不是真的 → 08 看是不是两个库打架。四篇读完能覆盖上面表格里「取错了」和「不敢信」两类根因。路线 B · 要省钱先砍浪费01 把不该进检索的知识迁出去这一条的收益通常是最大的→ 03 重定块大小直接压索引体积与 token→ 05 判断重排是不是在为 1pp 准确率付 3 倍延迟 → 09 给管道上门禁避免反复重建索引。路线 C · 要合规先补可溯源06 引用验证回路 → 07 时效元数据与巡检 → 08 冲突登记与仲裁记录 → 09 变更留痕与回滚。这四篇的产物都是可审计的对齐判定记录、巡检记录、仲裁记录、回归报告。三条路线共享 02A / 02B——解析和切分是所有路线的地基坏了的话上面怎么调都不稳。四、统一约定贯穿案例OpsAgent 的知识来源有五处全簇共用源内容规模 ⚠️ 构造示例归哪一层topo_docs服务拓扑文档Confluence 导出 PDF/HTML12,000 条目检索知识incidents历史故障复盘记录800 条记忆属记忆主题本簇只从取用侧提一句runbooks处置手册含表格与截图300 份检索知识Prometheus当前 CPU / 错误率 / QPS实时工具知识SLO 口径 / 告警分级标准稳定业务规则约 20 页—上下文知识评测集opsqa-200200 条真实值班问题每条标了正确处置动作与应命中的证据片段 id。工具集prom_query(metric, range)/get_runbook(id)/list_services()。实验纪律每篇都要给三层检索层召回率、精确率、命中片段排序下游层任务准确率本簇用opsqa-200的处置动作命中率成本层单次 token 与 P95 延迟。三者必须与「不上这个机制」的基线对照。只有中间指标变好不算数——召回到了但答案变差是常见结果。数字标签[算]可现场推导 ·[公开]带三要素版本 / 抓取日期 / 数据规模 ·[实测]留空待跑结果落results/编号.csv。凡是没有出处的推断数字一律标 ⚠️ 经验值并说明缺什么。图码约定每篇 3 张 Mermaid流程 / 结构 / 数据流首个流程图在正文 35% 之前。代码一律零依赖内核Python 标准库 两个可替换适配口embed(text) - list[float]与async def llm(prompt) - str。术语表各篇口径一致术语定义四类知识参数模型权重里/ 上下文随 prompt 注入/ 检索按需从外部库取/ 工具调 API 现取块内完整率单个块已包含回答某问题所需全部信息的比例跨块断裂率回答某问题所需信息被切到两个及以上块的比例无感损失 / 有感损失解析丢信息但解析器不报错 / 会报错能被立刻发现断言-证据对齐答案拆成独立断言后逐条验证是否有证据片段支撑引用失真率指向不存在片段 / 片段不支撑 / 支撑但被截断 / 张冠李戴四类分别计过期存活时长从条目实际过期到被系统发现的时长结论跳变率同一问题两次查询给出不同结论的比例回归检出率注入的退化被门禁抓住的比例七、系列内脚本程序表编号脚本跑通需要什么最小验证01knowledge_layers.py一份知识清单JSONL输出四层落点建议 放错层的告警02Aparse_quality.py20 篇自己的真实文档输出四把尺子得分02Bparse_repair.py02A 的块流输出输出断裂标记 修复前后四尺子对比03chunk_eval.py02B 的块流 20 条标注问题输出跨度分布与推荐块大小04query_rewrite.py查询日志含原查询与点击输出差距分布 改写后的约束丢失率05hybrid_search.pyembed()适配口 倒排表输出三路召回的漏召诊断06cite_verify.py答案 候选片段输出断言-证据对齐判定记录07freshness_probe.py条目时效元数据输出过期标记与处置建议08conflict_policy.py多源候选集输出冲突对与仲裁结果09retrieval_gate.py新旧两套索引 固定问题集输出回归报告与切流建议适用边界本簇基于 Python 3.x / 2026-Q4 的检索与模型能力涉及向量库、embedding 模型与文档解析工具的行为以各自官方文档为准。参考Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks本簇「知识质量是独立因子」这一立论的起点Seven Failure Points When Engineering a RAG System三类知识根因的分类参照Lost in the Middle: How Language Models Use Long Contexts「取坏了」为什么在下游才暴露的依据Retrieval Augmented Generation or Long-Context LLMs?本簇坚持「窗口外知识」而非「塞进长上下文」的取舍依据Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs01 分层判据中「参数知识」一层的定位