聚焦外部知识如何被摄入、检索、重排和引用，回答 LLM 怎样真正“基于证据说话” (2025-2026)
| 层级 | 核心职责 | 典型问题 | 关键关注 |
|---|---|---|---|
| 知识源 | 提供事实基础 | 知识分散、过期、口径不一致 | 可信度、时效性、权限边界 |
| 摄入与切分 | 把原始资料转成可检索单元 | 表格丢失、标题断裂、语义切碎 | 文档结构保留、分块策略、元数据 |
| 索引与检索 | 召回相关内容 | 漏召回、误召回、向量质量不稳 | Embedding、混合检索、过滤条件 |
| 重排与上下文 | 筛选和拼装最有价值上下文 | 相关内容太多、上下文超长、引用混乱 | Reranker、Context Window、压缩策略 |
| 生成与引用 | 让模型基于证据回答 | 答非所问、引用失真、幻觉补全 | 忠实度、引用溯源、评测与回归 |
PDF、表格、网页、富文本、知识库页面和数据库导出结构差异很大，如果解析阶段就丢了标题、层级和表格关系，后面检索质量会被长期拖累。
文档来源、更新时间、业务域、租户、权限范围、标题路径、章节编号，都会直接影响过滤、排序和引用表达。
如果知识源本身不可信、更新无序或权限不清晰，后面的 Prompt 和模型优化通常只能部分缓解问题。
RAG 里的 chunk 更像“最小可检索知识单元”，需要同时考虑语义完整性、标题层次、引用粒度和上下文预算。
固定长度、递归分割、按标题切分、Parent-Child、滑动窗口、语义切分，实际生产中往往会组合使用。
同一套 chunk 策略未必适合 FAQ、技术文档、制度文档、代码库和表格型知识；真正上线时要用目标模型的 Tokenizer / 词表 / 文本表示 计算 token 预算，而不是只按字符数切。
编号、错误码、专有词和精确字段更适合关键词；同义表达、自然语言问题和长文本语义更依赖向量检索。
很多生产系统会把 BM25、向量检索、过滤条件和业务规则一起做融合，而不是只押注单一路径。
如果你的 RAG 经常“明明知识库里有，但就是没拿到”，通常先该看检索召回，而不是先怪模型。
上下文太长、顺序混乱、冲突内容并列、引用范围不清晰，都会让模型出现“看到了证据却答歪了”的情况。
Reranker、摘要压缩、去重、按问题类型动态拼装上下文，往往比一味扩大上下文窗口更有效。
不仅要回答，还要让回答能对应到可核对证据，尤其是在企业知识问答、政策制度和高风险领域里。
| 类别 | 定位 | 典型能力 | 关键关注 |
|---|---|---|---|
| 文档解析 | 把原始资料结构化 | PDF 解析、网页抽取、表格识别、代码索引 | 结构保真、批量处理、错误恢复 |
| 切分与加工 | 构造可检索单元 | Chunking、标题路径、摘要、关键词、元数据 | 语义完整性、更新成本、引用粒度 |
| 检索引擎 | 召回相关知识 | BM25、ANN、Hybrid Search、过滤检索 | 召回率、解释性、时效性 |
| 重排与组装 | 筛选最优上下文 | Rerank、去重、压缩、Parent-Child 组装 | 上下文预算、顺序、证据密度 |
| 生成与引用 | 输出基于证据的回答 | 引用溯源、拒答、结构化输出、摘要生成 | 忠实度、格式稳定性、风险边界 |
| 评测与治理 | 持续验证质量 | Golden Set、Faithfulness、Recall、人工审查 | 坏例回流、回归测试、知识更新 |
| 方式 | 强项 | 代价 | 适合场景 |
|---|---|---|---|
| 直接长上下文 | 实现直观、原型快 | 成本高、时效性差、知识更新不灵活 | 小规模文档、单次分析、实验验证 |
| RAG | 知识更新灵活、成本更可控、可做引用与过滤 | 链路更复杂，需要检索与评测治理 | 长期运营的知识问答、企业助手、复杂知识库 |
它更像一个检索、筛选、组装和回答的系统工程，模型只是最后一个表达层。
如果检索不到关键证据，再好的提示词也很难稳定补出正确答案。
多源知识库里经常同时存在旧版本、新版本和不同部门口径，系统需要知道该信谁、该怎么引用。
| 证据节点 | 必须记录字段 | 用来排查什么 |
|---|---|---|
| query_understanding | query_id、original_query、query_rewrite_version、intent_label、filter_condition | 问题是否被错误改写、错误分类或过滤过窄 |
| retrieval_result | retrieved_doc_ids、chunk_ids、index_version、embedding_model、hybrid_score | 关键知识是否被召回，误召回来自哪一路检索 |
| rerank_context | reranker_version、top_k_before_after、context_pack_id、chunk_order、dropped_reason | 重排和上下文组装是否丢掉关键证据 |
| answer_grounding | citation_ids、no_answer_reason、faithfulness_eval_id、eval_case_id | 最终回答是否真的基于证据，拒答是否合理 |
Hybrid Retrieval 更常态化: 关键词、向量、过滤条件和业务规则会继续融合，单一路径很难覆盖真实需求。
RAG 与企业知识治理更紧耦合: 权限、元数据、知识时效和文档可信度会越来越被视为系统核心能力。
评测与引用质量持续受重视: 团队会更强调“答案是否真的基于证据”，而不只是“看起来像对”。
多跳检索与推理协作: 对复杂问题，系统会更常先拆问题、再多次检索，而不是一次召回所有信息。
RAG 与 Agent 融合: 检索增强会更频繁地作为 Agent 的一部分，与数据库查询、工作流和外部工具协同。
知识债持续累积: 文档过期、版本冲突和权限漂移会慢慢侵蚀整个系统可信度。
只看 Demo 不看长期运维: 很多 RAG 系统上线后真正的成本在更新、评测和坏例治理。
把引用当成正确性的替代品: 引用可以提升可核对性，但不能自动保证答案真实可靠。