1. 为什么我要做这个RAG进阶专栏去年下半年开始我陆续帮三四个团队做过RAG系统的落地咨询从最朴素的文档切片向量检索拼prompt三件套到后来要处理表格、图片、跨文档推理、多轮追问踩的坑一个比一个深。最直观的感受是网上能搜到的RAG教程90%都停在用LangChain跑通一个PDF问答Demo这个层面而真正让RAG在生产环境里跑得住、答得准、扛得住并发的那部分经验几乎没人系统讲。这就是《RAG进阶实战》这个专栏的由来。它不是一个从零教你RAG是什么的入门课市面上那种内容已经够多了。它面向的是已经跑通过基础RAG、但被下面这些问题卡住的人检索召回率上不去、答案老是幻觉、知识库更新后索引对不上、多模态内容不知道怎么进库、Agent和RAG怎么配合、并发一上来就崩。关键词里出现的RAG、LLM、Python、Agent、MVP基本就是这个专栏要覆盖的技术栈全貌。我打算把它做成一个能抄作业的专栏而不是概念科普。每一篇都对应一个真实场景里的具体问题给出可复现的代码、可对照的参数、以及我在实际项目里踩过的坑。下面我把整个专栏的策划思路拆开讲包括选题逻辑、技术主线、每篇的定位、以及为什么这么排。如果你也在做RAG相关的项目或者准备系统补一下这块这篇策划案本身就能当一份学习路线图看。2. 专栏的选题逻辑从能跑到能扛的四道坎2.1 第一道坎检索质量决定RAG的下限大部分人做RAG第一步就埋了雷。文档切片用固定长度500字符、重叠50字符向量模型随手选个开源的检索就取top-3。跑Demo没问题一上真实语料就露馅问2023年Q3的营收是多少检索回来的全是2023年Q2和2024年Q1的段落因为语义相似度太接近了。这道坎的核心是检索质量。它涉及切片策略、embedding模型选型、混合检索向量关键词、重排序rerank、以及query改写。我在专栏里会专门用两到三篇讲这块因为检索召回率上不去后面所有环节都是白搭。这里有个经验数据在中文技术文档场景下单纯向量检索的top-5召回率大概在60%到70%加上BM25混合检索能到80%左右再叠一个rerank模型能推到88%以上。这三个数字的差距就是专栏要帮你补上的。2.2 第二道坎生成可控决定RAG的上限检索对了生成不一定对。LLM有个坏毛病检索回来的内容里没有答案它也会硬编一个。这就是幻觉。控制幻觉的手段有好几层prompt里明确约束只依据给定上下文回答、让模型输出引用来源、用LLM as judge做答案校验、设置拒答阈值。关键词里有个llm的token三个点key我是谁、query我在找什么、value我能提供什么这个说法其实很形象地概括了RAG里LLM的角色定位——它不是一个知识源而是一个信息整合器。key是它的能力边界query是用户意图value是检索给它的素材。理解这个定位才能设计出合理的prompt和校验机制。专栏里会有一篇专门讲如何让LLM在RAG里老实回答问题包括prompt模板、拒答策略、以及用第二个LLM做裁判的具体实现。2.3 第三道坎知识库工程决定RAG能不能长期维护Demo阶段的RAG知识库是静态的导入一次就完事。生产环境里文档每天都在变有新增、有修改、有删除。这时候问题就来了增量更新怎么做删掉的文档怎么从向量库里清掉同一个文档改了之后旧向量怎么失效这块是很多教程完全跳过的但恰恰是工程上最耗时间的。我在实际项目里用过几种方案全量重建简单但慢、基于文档ID的增量更新需要维护映射表、以及基于时间戳的版本管理。每种方案的成本和适用场景不一样专栏里会用一篇讲清楚知识库的生命周期管理包括向量库的选型对比Chroma、Milvus、Qdrant、pgvector各自的适用场景。2.4 第四道坎Agent化与并发决定RAG能走多远基础RAG是一问一答但真实需求往往是多步的先查A文档根据结果再查B文档最后综合。这就是Agent化的RAG也就是关键词里的rag智能体和ai agent。Agent和RAG的结合有两种模式一种是把RAG当成Agent的一个工具toolAgent决定什么时候调用检索另一种是RAG流程里嵌入Agent做query规划和多跳检索。再往上就是并发和安全。关键词里有ai agent 怎么扛并发和agent安全这两个是生产环境的硬指标。并发涉及向量库的连接池、LLM API的限流、以及缓存策略安全涉及prompt注入防护、检索内容的权限过滤、以及Agent行为的边界约束。专栏最后几篇会落到这些工程问题上。3. 技术主线Python LLM 向量库 Agent 的完整链路3.1 为什么主线语言选Python关键词里Python出现的频率极高从python安装到python构建邻接矩阵说明目标读者大概率是Python技术栈。RAG生态里LangChain、LlamaIndex、Haystack这些主流框架都是Python优先向量库的客户端也是Python最全。所以专栏的代码统一用Python不搞多语言并行降低读者的环境成本。环境准备这块我会单独写一篇因为python安装和python安装numpy库的方法这种搜索词说明确实有零基础读者。但专栏定位是进阶所以环境篇不会花太多篇幅讲怎么装Python而是重点讲依赖版本管理——这是RAG项目里最容易翻车的地方。LangChain的版本迭代极快0.1和0.2的API差异能让你照着教程写的代码直接报错。我会给一份经过验证的requirements.txt锁定版本号避免读者在环境上浪费时间。3.2 LLM层本地与云端的选择关键词里有ollama 简易本地 rag 知识库和大模型llm说明读者对本地部署和云端API都有需求。专栏的策略是两条腿走路核心逻辑用云端API讲因为稳定、效果好、便于复现同时给出本地Ollama的替代方案因为免费、数据不出本地、适合练手。这里有个选型经验本地模型做RAG7B级别的模型在中文问答上勉强能用但做query改写和rerank就力不从心。所以我的建议是本地模型只用来做生成检索和重排还是用专门的embedding和rerank模型这些模型小本地跑没压力。这个分工方案会在专栏里明确给出。3.3 向量库从Chroma到Milvus的演进路径新手最容易纠结的就是向量库选哪个。我的建议是按阶段选练手用Chroma零配置pip装完就能用小规模生产用pgvector如果你已经有PostgreSQL或Qdrant独立部署性能好大规模用Milvus分布式能扛亿级向量。专栏里会有一篇专门做向量库对比用同一份数据、同一套查询实测各个库的召回速度、内存占用、以及增量更新的便利性。这种实测数据网上很少但对选型决策特别有用。3.4 Agent框架LangChain还是自己写关键词里有agent框架和agent架构这是个绕不开的话题。我的观点是学习阶段用LangChain/LlamaIndex快速理解概念生产阶段考虑自己写核心循环。因为Agent框架的抽象层太厚出问题的时候调试成本极高而且版本升级经常破坏兼容性。专栏里会有一个AgentRAG的实战篇我会先用LangChain的AgentExecutor跑通然后拆解它的执行流程最后给出一个不依赖框架的轻量实现大概200行代码让读者理解Agent的本质就是LLM输出决策工具调用循环。理解了本质用不用框架就是个人选择了。4. 专栏文章清单与每篇的定位4.1 基础篇把地基打牢3篇第1篇RAG系统的环境搭建与版本锁定。不讲Python怎么装直接给一份可用的环境配置重点讲依赖冲突的排查方法。会包含一个check_env.py脚本一键检测环境是否就绪。第2篇文档解析与切片策略。这是被严重低估的一环。PDF里的表格、图片、页眉页脚怎么处理切片是按字符、按句子、还是按语义我会给出三种切片策略的对比实验用同一份文档、同一个问题看召回结果的差异。第3篇Embedding模型选型与本地部署。对比几个主流中文embedding模型bge、m3e、text2vec在检索任务上的表现给出本地部署的代码。这里会涉及rag知识库能存储图片嘛这个问题——答案是embedding模型只能处理文本图片要么用多模态模型转成文本描述要么用CLIP这类多模态embedding单独建库。4.2 进阶篇解决核心痛点5篇第4篇混合检索与重排序。向量检索BM25的融合策略以及rerank模型的接入。会给出完整的代码实现和参数调优建议。第5篇Query改写与多跳检索。用户的问题往往不是最佳检索query需要改写。多跳检索解决需要综合多个文档才能回答的问题。这篇会涉及ontology rag和kg知识库的概念讲清楚结构化知识库和向量知识库的区别与结合方式。第6篇幻觉控制与答案校验。prompt工程LLM as judge拒答策略。会给出一个可复用的答案校验模块。第7篇知识库的增量更新与版本管理。文档增删改怎么同步到向量库旧向量怎么清理。这是工程上最实用的内容。第8篇RAG系统的评估体系。怎么量化RAG的好坏召回率、准确率、忠实度怎么测会介绍RAGAS这类评估框架的使用。4.3 高级篇Agent化与生产化4篇第9篇Agent与RAG的结合模式。两种模式的代码实现和适用场景对比。第10篇多模态RAG。图片、表格怎么进知识库怎么检索。会涉及spatial llm这类空间理解模型的应用。第11篇RAG系统的并发优化。向量库连接池、LLM API限流、缓存策略、异步处理。这篇直接回应ai agent 怎么扛并发这个搜索词。第12篇RAG与Agent的安全防护。prompt注入、权限过滤、行为边界。会提到agentpoison这类攻击方式以及对应的防护手段。4.4 实战篇完整项目2篇第13篇从零搭建一个企业知识库问答系统。综合运用前面所有技术给出完整代码。第14篇RAG系统的MVP框架设计。回应mvp框架这个关键词讲怎么用最小成本验证RAG方案是否可行避免过度设计。5. 每篇的写作规范与交付标准5.1 代码必须能跑且给出验证方法专栏里的每一段代码我都会在本地跑通再写进去。更重要的是每篇会给出验证方法——怎么确认这段代码生效了。比如讲rerank不能只说加上rerank模型还要给出对比数据加之前top-5召回率多少加之后多少用哪个测试集测的。5.2 参数要有依据不能拍脑袋RAG里参数特别多切片长度、重叠大小、top-k、温度、相似度阈值。我不会只给一个数字而是解释这个数字怎么来的。比如切片长度我会说明中文场景下500字符大约对应250到300个token这个长度能覆盖一个完整段落又不至于超出embedding模型的最佳输入长度。不同场景要调整调整的方向是什么。5.3 踩坑经验单独标注每篇会有一个踩坑记录小节专门写我在实际项目里遇到的问题。比如Chroma在Windows下的持久化路径有坑、某些embedding模型对长文本会截断、LangChain的某些版本对中文支持有问题。这些内容网上搜不到但实际会浪费你几个小时。5.4 每篇结尾给一个可执行的checklist读者看完一篇应该能对照checklist确认自己是否掌握了。比如检索优化那篇的checklist是否用了混合检索、是否接了rerank、是否做了query改写、是否测过召回率。这种形式比总结更有用。6. 目标读者与前置要求这个专栏不是给完全零基础的人看的。如果你连Python都没写过建议先补基础。但如果你满足下面任意一条这个专栏就适合你跑通过LangChain或LlamaIndex的RAG Demo但不知道怎么优化在做企业知识库项目被检索质量和幻觉问题卡住想系统了解RAG的工程化实践而不只是概念已经在用Agent想搞清楚Agent和RAG怎么配合前置要求就三条会Python基础语法、了解LLM的基本概念知道什么是token、什么是prompt、本地能跑起来Python环境。其他的专栏里都会讲。7. 更新节奏与互动方式专栏计划每周更新两篇基础篇和进阶篇交替发这样读者可以边学边练。每篇发布后我会在评论区收集问题高频问题会整理成补充篇。如果某个技术点读者反馈特别难我会加更一篇专题。另外关键词里有个open llm leaderboard 等公开榜单我会在选型相关的文章里引用这些榜单的数据但会说明榜单分数高不等于RAG场景好用因为RAG更看重模型对给定上下文的忠实度而不是通用能力。这个区别很重要很多选型失误就出在这里。8. 我在策划这个专栏时的几点个人体会做RAG这一年多最大的感受是RAG的难点不在模型在工程。模型能力已经足够强了真正决定系统好坏的是检索策略、数据质量、以及工程细节。我见过太多团队花大力气调模型结果发现是切片策略有问题。另一个体会是不要追求一步到位。RAG系统是可以渐进演进的先用最简单的方案跑起来收集真实badcase再针对性优化。我见过有人一上来就上知识图谱、上多跳推理结果基础检索都没做好整个系统复杂到没法维护。这也是我为什么在专栏里安排了一篇讲MVP框架——先用最小成本验证再决定要不要加复杂度。最后一个体会评估比优化更重要。没有评估体系你根本不知道优化有没有效果。所以我把评估单独列了一篇希望读者能重视起来。建一个几十条问题的测试集每次改动都跑一遍这个习惯能帮你省下大量瞎调的时间。这个专栏我会持续更新也会根据读者反馈调整内容。如果你在做RAG的过程中遇到什么具体问题欢迎在评论区提很可能就是下一篇的选题。