RAG 工程化

向量库特殊在「近似最近邻 + 元数据过滤 + 持续写入」三件事要一起做好。Milvus / Qdrant / pgvector / Chroma / Elasticsearch 的差别不在能不能跑起来，而在这条路能走多远：数据量级、过滤复杂度、运维能力与已有技术栈决定选型。

RAG 是「索引 → 检索 → 生成」三段链路：离线把文档解析、切分、向量化进库；在线把 query 变成检索、拿回证据、交给模型带证据作答。每一步都在解决一个具体问题，链路上任何一环出错都会表现成「答非所问」，所以先能把全链路讲清，后面的每个环节才有落点。

RAG 的上游是把文档解析干净：表格要保住结构、代码要保住块、扫描件要 OCR、图表与版面要靠 VLM 或 ColPali 这类视觉检索。解析质量决定后面所有环节的上限 —— 多数「检索不准」的根因在这一步。

切分粒度是 RAG 第一个要拧的参数：切大了检索不准、切小了上下文不全。递归字符切分是工程默认起点， overlap 用重叠窗口补跨块断句，但它同时放大索引体积与重复召回。chunk size 没有通用最优值，要拿评测集实测。

向量检索找的是「意思像」，专有名词、型号、错误码这类要一字不差的 query 天生适合 BM25。纯向量会漏召回，纯 BM25 不懂同义与口语 —— 两路各有擅长的 query 形态，这是混合检索存在的理由。

选 embedding 模型看四个维度：检索精度看 MTEB 的检索子榜而不是综合分、向量维度不是越大越好、运营适配（多语言 / 许可证 / 托管与自托管）是 2026 年真正的分水岭、稀疏还是稠密还是混合。换模型意味着全量重建索引，所以这是一次性决策。

知识库会变：新增走增量写入，删除多数向量库只能软删除、定期重建；文档改版要靠版本字段与 chunk 级 id 保证「检索到了也取得到原文」。索引与源数据的一致性是运维问题，不是算法问题。

有标注时检索侧最可靠：recall@k、MRR、NDCG 直接量化「该召回的召回了没有」。评测集从真实 query 日志、badcase 与人工构造三处来，按场景分桶；凑不齐一千条也要先跑起来，「知识库里没有答案」这一桶必须单独留。

引用溯源要求模型的每句结论都能指回具体 chunk，防「标了引用却胡编」靠事后校验：引用的 chunk 里必须真的包含该结论。检索分数低于阈值时兜底说「不知道」，比硬答一个漂亮的错误答案更值钱。

GraphRAG 在索引期用模型抽实体与关系建图，再做社区检测生成层级摘要，回答多跳推理与「全局性总结」这两类向量检索答不出的问题。代价是数倍的索引成本与更新困难，只有问题形态真需要跨文档关系时才值得付。

用户 query 口语、含糊、带多轮指代，直接拿去检索就是问错话。查询改写解决指代与口语化，查询扩展解决表述鸿沟，HyDE 先让模型写一段假想答案再拿它去检索 —— 最反直觉也最常被追问。每一招都多一次模型调用，要算成本。

BM25 分数与向量相似度不在一个量纲上，没法直接加；归一化受分布影响，RRF 只看排名、不看分数，所以多数团队直接用它。RRF 不是免费午餐：它抹平了强弱信号， k 值与两路候选数仍要评测集调。

百万级窗口不等于不需要检索：成本随 token 线性涨、context rot 让长输入的有效性塌方、知识更新与权限过滤仍要在窗口之外解决。「RAG 已死」之争的正确答法是按数据规模、更新频率、成本预算划边界，而不是站队。

RAGAS 把生成侧拆成 faithfulness（有没有编）、answer relevancy（有没有答到点上）、 context precision / recall（给的证据对不对、全不全）四件，用 LLM-as-Judge 打分。它评的是「基于给定证据答得好不好」，评不了证据本身该不该被召回。

向量库、SQL、图谱、API 各答一类问题，路由层先做意图分类再决定问谁 —— 问错地方比检索不准更常见。路由可以是规则、小模型分类或让大模型选工具（NL2SQL 也是一条路由分支），每加一路都要算成本与错路代价。

召回要「全」，排序要「准」：第一阶段用便宜的向量 / BM25 从全库捞几十条，第二阶段用交叉编码器逐条精排。Rerank 补的是双塔模型看不到 query 与文档交互的先天缺陷，代价是每次查询多一跳延迟与成本。

固定切分之外的三条路：结构感知切分按标题层级切、语义切分按 embedding 相似度断句、父子（小到大）切分用小块检索、大块喂模型。它们各解决固定切分的一种失败，代价是解析依赖、离线成本与实现复杂度。

把固定的「检索一次 → 生成」改成循环：模型自己决定要不要检索、检索什么、检索几轮，检索成了工具调用。强在能处理多跳与不确定的问题，贵在每轮都是一次模型调用 —— 失控时会反复检索同一个东西，或者明明该检索却直接答。

向量检索的默认索引。分层图 + 贪心下沉把 O(N) 降到近似 O(log N)，代价是召回不再是 100%，而且图结构常驻内存。M、ef_construction 定索引质量，ef_search 是唯一能在线拧的旋钮 —— 拿延迟换召回。

LightRAG 保留图结构但去掉了微软 GraphRAG 最贵的社区摘要：用「实体 / 关系」双层检索，支持增量更新而不用重建全图。轻在索引成本与更新友好，失去的是社区级的全局总结能力。

用户说「答非所问」，先把评测切成两段：看检索结果里有没有正确证据 —— 有就是生成问题，没有就是检索问题，再往上游一层层归因到切分、解析或 query。badcase 驱动迭代是面试最想听的工作方法：每个 badcase 进评测集，修完回归，不凭感觉调参。

双塔（bi-encoder）把 query 与文档各自编码成向量，能预计算、能建索引，但看不到两者的交互；交叉编码器（cross-encoder）把两者拼在一起打分，准但每对都要现算，所以不能用来检索全库。 ColBERT 式后期交互是第三条路：token 级向量 + 延后打分。

Naive / Advanced / Agentic / Graph 四代形态不是升级关系，是坐标系上的四个位置。决策从数据形态出发：结构化程度、更新频率、问题是否多跳、成本与延迟预算；演进路径不要一步到位 —— 先 Naive 跑通评测集，被 badcase 逼着才升级。