这两年我面试过不少标着“RAG资深”的人。十个里有九个把RAG讲成“向量检索加生成模型”，仿佛把LlamaIndex的代码抄一遍，就掌握了下一代知识管理。我对这种面试者的回答，通常只有一句：那你为什么还要用RAG呢？
好吧，安静一下！这个行业里最容易被误解的架构，大概就是RAG。你说它难？流程清晰得很。你说它简单？生产环境里翻车翻得你怀疑人生。今天我们不画那些漂亮的分色架构图，直接扎进底层。
一、底层拆解：HNSW图结构背后，是物理层的选择
向量检索不是SQL查询。它是在一个高维空间里，找出与Query嵌入最近的K个点。暴力穷举在3000条数据上是毫秒级，没问题。但企业级知识库动辄几千万条，暴力扫描的延迟你会直接暴毙。
于是我们有了ANN——近似最近邻。对，关键在于“近似”。
我最常用的HNSW构建一张多层图：顶层稀疏，底层密集，每层都像是路标系统。搜索时从顶层向下，有点像我小时候玩的滑雪游戏，先滑下陡坡，再跳入密集的小巷，沿邻居指针快跑。复杂度从O(n)直接降到对数级。
但你不能忽视代价——内存。HNSW要存储每一层的邻居关系，几十GB的向量数据，索引占用的内存常常超出想象。所以工程师必须在精度和内存之间做权衡。有些时候你不得不把维度从1024压到256，但代价是召回率下滑。这也是为什么量化方法（如PQ）经常与HNSW搭配出现。
还有一个隐蔽的炸弹：距离度量。很多人默认用余弦相似度，但高维空间里余弦值趋同，区分度下降。我们后来做了实验：同一批数据，用内积和余弦分别检索，结果集合重叠度只有60%。最后我们采用三种测度混合打分，然后用归一化融合，才换来稳定。
二、数据不会说谎：一场压测揭示的RAG效能曲线
来点硬碰硬的数据。我们内部构建了12000问的法律问答集，检索库来自3000份条款。三种配置：纯LLM、基础RAG（向量top-5）、完整RAG（加重排器+重写器）。
纯LLM（GPT-4-turbo）正确率：17%。模型不是笨，而是这种条款级答案，它背混版本的概率极高。
基础RAG正确率：61%。提升明显，但你会发现大约三成的问题，答案明明就在库里，模型却选不中用。为什么？因为top-5里通常混有1~2段干扰。LLM在长上下文面前没有辨别力，它不认为哪条更权威，于是照着杂音编。
完整RAG（加入交叉编码器重排）正确率：82%。重排器逐对打分，把真正相关的文档推到前面。这一步贡献了21个百分点的提升，比嵌入模型换大版还要猛。
延迟和成本呢？p99从1.9秒涨到2.4秒，可接受。原因是我们先做了低分过滤，原本要重排的50多段候选，最后真正送去重排的只有8段左右。
不妨对比微调。微调一个7B模型吸收知识，预算报了50万，三周培训，还不能随时更新。RAG一星期上线，后续换索引就完事。这就是工程上的不可替代性。
三、落地三个坑，每个都交了学费
RAG真正落地时，算法不是瓶颈，那些看似聪明实则鲁莽的工程决策才是。
坑1：分块策略一刀切
早期我把文本按800字符切，结果一条法规被从中间斩断，检索时另一半永远找不到。解决方法是先识别文档的层级结构（标题、目录、章节），再按语义边界切块，并让相邻片段有50字左右的重叠。这个改动直接让检索召回率上升9个点。
坑2：把相似度分数当圣旨
有一次案卷检索，余弦相似度高达0.87，放进去答案却完全跑偏。原因在于，高维空间中向量间的分数会集中在0.7~0.9之间，0.87根本不代表什么。解决思路：要么上交叉编码器做重排，要么对原始分数做统计校准。我们后来采用百分位归一化，用最近50次查询的分数分布作为动态基线，低于一个标准差的直接丢弃。
坑3：Prompt塞太多，模型变成了“摆设”
把5段上下文塞进提示词，再强调“严格按照上文回答”，模型反而开始幻觉。为什么？因为指令被埋在长文本里，注意力机制在几万token中迷失。正确的做法是只保留重排后前3段，把指令放在生成侧，例如“你的回答只能基于最后一段”。这样改造后，幻觉率在测试集上下降了27%。
看起来都是小事吧，但每一件都能让系统从demo变成不可用。
说到底，RAG是工程美学也是取舍艺术。向量检索只是第一公里，后面的重排、压缩、调度每个关节都能决定成败。
别做只会拼代码的“架构师”。
