[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-rag-not-vector-demo":3,"article-neighbors-rag-not-vector-demo":17,"article-related-rag-not-vector-demo":36},{"id":4,"slug":5,"title":6,"excerpt":7,"category":8,"tags":9,"content":13,"publishedAt":14,"readingMinutes":15,"published":16},35,"rag-not-vector-demo","RAG 检索增强生成：完整流水线拆解（不止向量入库）","RAG 不是把文档丢进向量库就完事，预处理、分块、混合检索、重排、生成约束，缺一环都白搭。","AI 学习",[10,11,12],"RAG","检索","AI 工程","现在很多 RAG 教程给人的错觉是：把文档上传、分块、存进向量库，就完事了。我一开始也这么以为，结果做出来的东西召回不准、回答失真、幻觉频发，后来才搞明白——向量入库只是整条流水线的中间一环，真正决定效果的，是它前后那些不起眼的环节。\n\n我把完整的 RAG 流水线拆成了五段，每一段都踩过坑，展开说说。\n\n### 第一段：文档预处理，最容易被忽略的一环\n\n第一段是文档预处理，这步最容易被忽略，但权重最高。真实的业务文档里全是脏东西：页眉页脚、多余空行、广告乱码、重复段落、无效注释。你要是直接分块入库，这些噪声就跟着进去了，检索的时候它们会被当成有效内容混出来，回答质量直接打折。所以预处理必须做：格式清洗、去重降噪、结构化解析、按章节拆分，源头不干净，后面全白搭。\n\n这一步还要注意格式适配：PDF、Word、Markdown、扫描件，每种格式的解析方式都不一样。表格数据尤其麻烦——直接当文本切分，表格的语义结构就全丢了。处理不好，表格类知识问答就是灾难。遇到表格，比较稳妥的做法是转成结构化的 markdown 表格或者 JSON 再入库，别拿原始文本硬切。\n\n### 第二段：语义分块，别用固定字数硬切\n\n第二段是语义分块。别用固定字数硬切——500 字一刀切下去，语义可能就被切断了，一个完整的观点被拆成两半，检索出来的就是残缺信息。正确的做法是按语义完整性来分：先按标题层级切，再在语义完整的位置断句，保证每个分块都是一个完整的语义单元。\n\n分块大小也是个权衡：切得太小，语义不完整，检索容易漏；切得太大，噪声多，检索不精准。业界常用的做法是\"大块检索、小块生成\"——检索时用较大的块保证召回，喂给模型时用更小的子块控制噪声。这个细节很多教程都不讲，但它对效果的影响很直接。另外，分块之间可以留一点重叠（overlap），避免\"观点正好被切在边界上\"的尴尬。\n\n### 第三段：向量化，存进去只是开始\n\n第三段是向量化。把文本块用 Embedding 模型转成高维向量存进向量库，这一步大家都会，但别以为存进去就万事大吉了。Embedding 模型的选型、向量的维度、相似度度量方式（余弦、内积、欧氏），都会影响检索效果。向量库的选择也很多：开源的 FAISS、pgvector，托管的向量数据库服务，各有利弊——个人项目用 pgvector 甚至够用，别一上来就上重型方案。\n\n选 embedding 模型有个原则：要跟你业务的语言和领域匹配。用中文业务就用中文 embedding 模型，用通用模型处理专业领域，效果会差不少。这是很多人容易踩的坑——一套模型打天下，结果专业术语检索效果一塌糊涂。\n\n### 第四段：混合检索 + 重排，别只靠向量\n\n第四段是混合检索。单靠向量相似度检索有个毛病——语义相近但词面不同的问题容易漏召回，精确词条匹配反而丢分。我的做法是向量检索和 BM25 关键词检索双路并跑：向量保语义，BM25 保精准词条，两边结果合并去重，再用 Rerank 重排模型对 Top-N 精筛一遍，把低相关的噪声过滤掉，只留下最该给模型看的内容。\n\n这里要说清楚为什么不能只靠向量：向量检索擅长\"语义相似\"，但不擅长\"精确匹配\"——用户问\"订单号 A123\"，如果知识库里有\"订单号 A123\"，向量检索可能因为句子整体相似度不高而把它排到很后面。混合检索把精确匹配和语义检索互补起来，召回率和精准率才能同时兼顾。Rerank 这一步很多人省掉，但它对最终效果的影响很大——向量排序是\"粗排\"，Rerank 是\"精排\"，缺了精排，结果质量上不去。\n\n### 第五段：生成约束，从机制上防幻觉\n\n第五段是生成约束。Prompt 里强制要求模型只基于检索回来的真实语料作答，资料不足就明确拒答，不编造来源。这一步是从机制上抑制幻觉的关键——不给模型自由发挥的空间。同时还可以配\"引用溯源\"：让模型在回答里标注引用了哪份资料，用户能点回去核实，也方便人工检查。引用溯源还有个好处：出问题的时候能定位——是哪份资料本身有误，还是模型理解错了。\n\n### 最后\n\n说到最后，RAG 能不能用，取决于你对整条链路的管控，而不是你用了多高级的向量数据库。把预处理、分块、检索、重排、生成约束这些环节老老实实做扎实，它才从\"玩具 demo\"变成\"能用、可信、少幻觉\"的系统。\n\n至于怎么知道每段做得好不好，我在《RAG 量化评测方案》那篇里讲过——用测试集和指标说话，别靠感觉。一句话：RAG 的成功，不在某一个环节有多炫，而在所有环节都足够扎实。\n","2026-06-26T02:00:00Z",6,true,{"prev":18,"next":26},{"id":19,"slug":20,"title":21,"excerpt":22,"category":8,"tags":23,"publishedAt":25,"readingMinutes":15},28,"rag-retrieval-evaluation","RAG 量化评测方案：召回率\u002F精准率人工测试集落地","改完 RAG 靠感觉说\"好像变好了\"？用测试集和召回率、精准率说话，才能真的定位问题。",[10,24,12],"评测","2026-06-12T02:00:00Z",{"id":27,"slug":28,"title":29,"excerpt":30,"category":8,"tags":31,"publishedAt":34,"readingMinutes":35},29,"agent-tool-call-design","Agent 工具调用工程规范：边界、拦截、容错、防失控","Agent 能不能可靠干活，一半看工具设计。轮次上限、高危拦截、容错兜底，一样都不能少。",[32,33,12],"Agent","工具调用","2026-07-10T02:00:00Z",5,[37,47,55],{"id":38,"slug":39,"title":40,"excerpt":41,"category":8,"tags":42,"publishedAt":46,"readingMinutes":15},2,"notes-on-ai-learning","AI 应用开发完整学习路线","AI 这行分三条赛道，应用开发是普通开发者最该走的那条。学习顺序和判断标准，这篇说清。",[43,44,45],"AI","学习方法","知识管理","2026-08-08T02:00:00Z",{"id":48,"slug":49,"title":50,"excerpt":51,"category":8,"tags":52,"publishedAt":54,"readingMinutes":15},36,"agent-complexity-is-not-ability","Agent 智能体工程落地：为什么复杂链路反而不稳定","工具越多、链路越长，Agent 反而越不稳定。我踩坑总结：Workflow 优先，Agent 兜底。",[32,12,53],"系统设计","2026-07-24T02:00:00Z",{"id":27,"slug":28,"title":29,"excerpt":30,"category":8,"tags":56,"publishedAt":34,"readingMinutes":35},[32,33,12]]