RAG 的检索、增强与生成如何可靠衔接？

核心不是“三段式”，而是可追踪的数据契约

RAG 可以概括为知识处理、候选检索、上下文增强和生成，但生产系统需要给每个阶段定义输入、输出、版本和失败状态。一次回答应能追溯到当前用户有权查看的原始资料，而不是只展示一段相似文本。

1. 知识处理

采集时记录来源、文档 ID、版本、发布时间/生效时间、租户与访问控制。解析 PDF、网页、表格和图片时保留标题层级、阅读顺序、页码或单元格位置，并用代表性样本检查 OCR 和结构。

切分大小和重叠没有通用的 512–1024 token。应根据内容结构、模型 tokenizer、可独立回答的语义单元、引用粒度和上下文预算设计，再用检索与答案评测选择。每个块保留原文定位、父文档、版本和权限元数据。

索引构建应可重复并支持原子切换或明确的双读期。新增、更新、删除、权限变更怎样传播到原文库、关键词索引、向量索引与缓存，需要有一致性状态和失败重试。

2. 查询与候选检索

在线请求携带用户、租户、会话和时间语义。先判断查询是否需要知识库、结构化系统或实时 API，再生成候选。关键词、向量、结构化过滤和多路融合都是可选组件；以实际失败切片和评测决定组合。

记录每路候选、分数/名次、过滤原因、去重键和版本。权限必须由服务端执行，不能在生成后才删除越权引用。若需要重排，先确认正确证据已经进入候选，并评估新增延迟。

3. 上下文增强

上下文组装不只是把前几段拼进提示。它要：