RAG 在生成回答前检索外部知识并把检索片段放入模型上下文。它解决的是模型参数无法覆盖私有资料、知识更新和引用核验的问题。RAG 的边界模型的参数知识来自训练阶段。内部文档、当前代码、临时政策和训练截止后的信息不会自动进入模型上下文。没有可靠依据时模型可能输出看似合理但无法核验的内容。RAG 将这部分工作交给检索系统文档被解析和索引请求到来后系统选出相关片段模型根据片段生成答案。资料变更后更新索引即可不需要重新训练模型。这套方法适合相对稳定的文本资料例如制度、产品文档、FAQ、合同和 Wiki。它不保证答案正确作用是把可用证据带进当前请求并使回答能够回到原始材料。索引构建与在线查询通常分开运行。索引与查询离线链路负责将资料变成可检索的记录在线链路负责处理请求、选取上下文并生成答案。两条链路的约束不同前者关注解析质量、索引成本和更新一致性后者关注延迟、权限和召回质量。索引采集与清洗。PDF、网页、Markdown、工单和代码需要先抽取正文去掉页眉页脚、导航、模板和重复段落。解析错误或噪声会直接进入索引。切块。检索单元不能等同于整篇文档。块太小会丢失前后条件块太大则混入多个主题并占用更多上下文。切块长度还受嵌入模型输入上限和生成模型上下文窗口限制。嵌入与存储。嵌入模型将每个片段编码为向量。向量与来源、标题、时间、权限等元数据共同写入 pgvector、Qdrant、Pinecone、Milvus 等存储。HNSW、IVF 等近似最近邻索引用于缩短大规模检索时间。中小规模场景可以先使用 PostgreSQL 与 pgvector。查询查询改写。请求中可能省略主体、使用口语化表述或包含拼写错误。改写可补全检索条件但原始问题应保留用于回退和审计。召回与融合。向量检索覆盖语义相近的内容BM25 等关键词检索对专有名词、错误码和字段名更稳定。两路结果可通过 RRF 融合。RRF 使用排名而不是原始分数常见形式为1 / (k rank)k常取 60避免直接比较不同检索器的分数。融合去重后一般保留 top-5 到 top-10 个候选。重排与生成。双塔模型用于大范围召回交叉编码器把问题与候选共同编码适合处理否定、限定词和精确实体。常见流程是先召回 50 到 100 条再重排为 top-3 到 top-5并剔除低于阈值的候选。最终上下文应包含片段、来源和用户问题证据不足时回答应明确说明。质量控制RAG 的主要问题不在于是否接入向量库而在于检索结果是否稳定、可解释且受访问控制。切块策略。固定长度切块通常使用 500 到 1000 个 token并保留 100 到 200 个 token 重叠结构化文档可按标题和段落切分递归切块则逐层细分。具体参数应由文档类型、问题集和评测结果决定。重排。召回追求覆盖重排追求候选精度。只用向量召回时getUserById可能与getUserByEmail一起出现交叉编码器可在有限候选集中区分这类差异。是否使用托管 Rerank API 或本地 bge-reranker取决于数据边界、延迟和成本。过滤。每个片段需要携带来源、部门、日期、数据等级和权限。检索前先应用权限和范围过滤避免跨权限召回也减少无关候选。评估。评测集应包含高频问题、长尾问题、无答案问题和权限边界。RAGAS、RAGVUE 可以辅助计算忠实度、上下文相关性和召回指标但验收阈值仍要按业务场景定义。没有固定评测集切块、模型和阈值的调整无法比较。缓存和重建。高频问题可以缓存嵌入、检索结果或最终答案。切块规则、嵌入模型或权限策略发生变化时需要增量或全量重建并记录索引版本与来源版本。线上指标至少应覆盖召回率、引用可用率、回答忠实度、P95 延迟和单次请求成本。文档检索RAG 的典型输入是私有、持续更新且需要保留来源的文本资料。企业知识库。制度、产品手册、项目文档和 Wiki 可以按权限入库。回答需要指向具体文档和章节。客服与 FAQ。售后政策、退换货规则和常见问题可构成受控知识源。证据不足或存在冲突时应转人工或返回预设兜底结果。长文档问答。合同、规范和论文适合先定位条款或段落再生成摘要或回答。此类系统通常还需要版本控制、段落级引用和访问审计。这些场景以自然语言资料为主检索目标是找到相关段落并给出出处。代码仓库不同符号、路径、调用关系和当前工作区状态往往比语义相似度更重要。代码搜索Claude Code 和 Codex 都通过工具循环定位代码、读取上下文、执行命令再根据结果继续探索。代码导航不依赖预建向量索引。常见操作是 grep、glob、文件读取、依赖追踪和测试执行。模型先定位符号、配置或错误信息再读取相邻实现、调用方和测试。这个过程依赖每一步工具输出而不是一次性返回一组向量检索结果。搜索与索引精确匹配。函数名、类型名、错误码、配置键和路径通常要求精确命中。grep 能直接返回位置向量检索可能找到语义接近但符号不同的代码因此更适合补充说明或文档检索。更新与边界。全文搜索直接读取当前工作区。向量索引需要随着代码变化同步若同步滞后结果可能引用旧实现。代码送往远程嵌入服务或独立索引系统前也要确认代码、向量和访问日志的存储边界。成本。ripgrep 和文件遍历没有嵌入模型、向量库和重建任务。代价是多轮工具调用带来的 token 和延迟。在大仓库中可以用 trigram 等本地索引加速文本搜索并在索引不可用时回退到 grep。Codex 的执行循环Codex 将用户请求、系统规则、可用工具以及仓库中的 AGENTS.md 等说明放入当前上下文。模型据此选择搜索、读取文件、运行命令或修改代码命令输出和测试结果进入下一轮决策直到任务完成或需要人工处理。长任务还需要压缩历史上下文保留约束、修改摘要和验证结果避免历史消息持续占用上下文窗口。选择RAG 适合自然语言资料资料规模大、结构不统一、更新可通过索引同步并且回答需要引用来源。代码搜索适合当前工作区目标是精确定位符号、文件和调用关系结果必须跟随代码变更。实际系统通常同时使用两类能力。规范、FAQ 和 Wiki 走 RAG代码走全文搜索、符号索引或 LSP。是否引入向量检索取决于数据类型、更新频率、准确性要求、权限边界、延迟和维护成本。资料展示下面是我整理的AI大模型 学习资料和工具包 预览适合收藏后按主题逐步学习