RAG

检索增强生成（RAG）让模型在回答前检索外部知识，并把相关片段作为上下文。目标不是“把所有文档塞给模型”，而是提供少量可信、相关、可追溯的证据。

标准流程

解析文档 → 清洗 → 分片 + 元数据 → Embedding/索引
用户问题 → Query 改写/过滤 → 初召回 → Rerank → 拼接上下文 → LLM 回答 + 引用

分片（Chunking）

分片是把文档拆为可检索单元。过大：检索不精准、上下文浪费；过小：语义不完整、答案缺上下文。

文档类型	建议做法
规程、制度、章节文档	按标题层级/条款分片，保留章节路径和条款号。
故障案例	按“现象 → 处置 → 原因 → 结论”分段，保留设备/站点/版本标签。
表格与参数	表头与行内容一起保留，避免只切出孤立数值。
长文档	语义分段后设置适度 overlap，避免断在定义或步骤中间。

不要照搬通用 token 数。先用真实问题集验证“答案所在的片段是否被召回”，再调整粒度、overlap 和元数据。OpenAI 的 vector store 同时支持自动与固定 chunk 策略；固定策略可设置 chunk 大小和 overlap。官方参考

召回、重排与回答

1. 初召回：向量搜索取候选，可加关键词/BM25、过滤条件与知识图谱实体关联。
2. Rerank：使用重排模型按“问题—片段”相关性重新排序，保留少量高质量片段。
3. 生成：提示模型只依据上下文回答；没有证据时明确说明未知，并输出引用来源。
4. 评估：分别看召回率、重排质量、回答正确性、引用正确性、延迟和成本。

RAG 回答错误时先定位在哪一层失败：文档缺失、解析/分片差、Embedding 不匹配、初召回不足、重排错误，还是模型未遵循上下文。不要只靠修改提示词掩盖检索问题。