这段时间我隔三差五就能刷到同一个问题RAG 是不是已经被长上下文淘汰了每次看到这个问题我都想拉个板凳坐下来好好聊十分钟。作为一个从早期向量检索一路做到 RAG 落地、又把长上下文模型塞进生产流水线摸爬过一遍的人我可以说一个比较踏实的结论长上下文确实很强但它远没有淘汰 RAG反而在倒逼 RAG 往更精细、更工程化的方向走。这篇我就把自己对这个问题的真实看法、算过的账、踩过的坑以及一套能在 Mac 上直接跑起来的 RAG 知识库搭建方案一次讲清楚。先说清楚一件事长上下文解决的是“能不能装得下”的问题RAG 解决的是“该不该装、怎么快速找到该装的东西”的问题。这俩根本不是一个维度。你给模型 100 万 token 的窗口它确实能把整本《三体》三部曲塞进去但如果你丢给它一家企业三年的制度文件、会议纪要和项目文档哪怕窗口再大你也不可能每次问答都把全部文档灌进去——成本、延迟、准确性全都会出问题。所以我的观点很明确长上下文是 RAG 的增强器不是替代品。下面我会把背后的逻辑拆开讲。1. 长上下文来了RAG 真的凉了吗先还原一下这个话题为什么这么热。从 GPT-4 Turbo 的 128K到 Claude 的 200K再到 Gemini 系列的 1M 甚至更夸张的窗口长度模型一口气能读的文本量确实膨胀了好几个数量级。于是很多人产生了最直接的想法既然模型都能把一整套文档放进上下文里了那我直接把资料全丢进去问就行还搞什么向量库、切片、召回这么麻烦这个想法听起来很合理但真放到实际业务里跑一圈就会发现事情没那么简单。长上下文时代真正改变的是什么是“单轮输入的容量上限”。比如你有一份 30 页的PDF合同以前塞不进窗口现在一键全文导入没问题。这类“一次性阅读”场景里长上下文的体验是碾压级的因为它省掉了切片、检索、拼接这些环节直接给模型看全文理解也更完整。这也是很多人觉得 RAG 要完蛋的原因。但知识库场景根本不一样。知识库的特点是总量大、增量不停、查询多样。我见过不少知识库项目文档量从几万份起步多则上百万份总 token 量轻松破亿。这种量级下你要么买天价的超长上下文套餐把数据全塞进去要么就得靠检索把相关的几百几千 token 精准捞出来。前者在经济上和工程上都不可行后者恰恰就是 RAG 的本职工作。还有一个反直觉的点长上下文模型在信息密度很高的时候反而更容易“迷失在中间”。学界早就观察到模型对超长上下文中间部分的内容关注度明显下降这被称为 Lost in the Middle。我实测下来也一样——把 100 份不相关文档和你要找的那份关键文档一起塞进长上下文模型经常会被无关信息带偏回答质量反而不如只给它检索出来的那几段。这不是模型笨而是注意力资源是有限的垃圾进垃圾出。所以我的判断是短文档、少量文件的场景长上下文直接平推RAG 确实显得多余但只要是规模化知识库、频繁更新、多人使用RAG 不但没被淘汰反而变成了必需品。长上下文真正淘汰掉的是以前那些“为了检索而检索”的低质量 RAG 实现。2. 先把账算清楚长上下文的代价在哪里光说“成本高”“延迟大”有点空我给大家算一笔实际账看完你就知道为什么生产环境不能无脑全量塞上下文。2.1 token 就是钱成本模型对比假设你有一个中等规模的知识库10 万份文档平均每份 5000 token总量就是 5 亿 token。如果用长上下文方案假设每次问答都把这些内容全部塞进去按现在主流模型的定价粗算一次调用的输入成本就要上千元级别。就算你有企业折扣这也不是日常问答能承受的单价。反观 RAG 方案日常开销主要是两块文档入库时的向量化费用一次性以及每次问答时的检索费用。检索走的是向量数据库或关键词索引成本极低真正花钱的是把检索到的几段内容送给大模型生成回答的那部分但输入长度通常控制在几千 token 以内。同样是 5 亿 token 的知识库RAG 单次问答的模型输入成本比全量塞入低几个数量级。这不是优化是量级碾压。2.2 延迟与并发用户等不了 30 秒长上下文还有一个容易被忽略的硬伤推理速度。模型处理输入不是免费的token 越多首字延迟越高。1M token 的输入哪怕模型再快冷启动加上预填充首字时间也很容易跑到几十秒。你想想客服机器人如果每次回答都要让用户等半分钟这个产品基本就废了。RAG 的延迟大头在检索而现代向量数据库的召回基本是毫秒到百毫秒级。加上重排之后整体从提问到拿到生成结果一般能控制在 2 到 5 秒内。这个差距在交互式产品里是天壤之别。长上下文适合离线分析、文档精读这类不赶时间的场景但线上高频问答RAG 仍然是最稳的架构。2.3 信息迷雾长上下文不等于高精度前面说的 Lost in the Middle 不是学术黑话是我在生产环境里真实遇到的问题。我把一个大客户的 200 多份项目文档直接塞进长上下文窗口做问答结果模型答非所问引用内容张冠李戴。后来切成 RAG 流程先召回再生成准确率反而上来了。原因很简单检索帮你做了第一道信息筛选模型看到的是低噪声、高相关度的内容生成质量自然更稳。所以说长上下文的价值在于“能装”RAG 的价值在于“会挑”。生产环境真正需要的是先挑再装而不是囫囵吞枣。3. RAG 的瓶颈到底在哪别再把锅甩给“切块不够细”聊完了长上下文咱们回到 RAG 本身。这个技术最近被吐槽得挺狠很多热词都在讨论“rag瓶颈”。作为一个实操过不少 RAG 项目的人我很负责任地说RAG 确实有一堆瓶颈但大部分瓶颈不是理论问题是工程实现问题。而且搞清楚这些瓶颈才能知道长上下文模型来了之后该往哪个方向优化。3.1 最常见的瓶颈召回质量差源头在“检索条件的错配”很多人搭完 RAG 发现效果不好第一反应是调 embedding 模型、改 chunk 大小但真正的问题往往是检索入口太单一。用户问“上个月华南区的退货率为什么涨了”你拿这句自然语言直接去向量库召回召回出来的可能是“退货流程说明”“物流异常处理”这类文档跟数据分析完全没关系。这不是模型不行是你没有把用户的模糊提问转成知识库能匹配的精确表达。我常用的解决思路是两步检索先用轻量模型或规则把用户问题做意图识别和关键词抽取拆出实体、时间范围、指标名再组合成多个检索条件去召回或者直接上 Hybrid Search把向量召回和 BM25 关键词召回的结果做融合。实测下来混合检索在中文文档场景里提升非常明显尤其是专业术语、人名地名这类向量模型容易“搞混”的内容关键词检索能把精度拉回来。3.2 被严重低估的瓶颈数据准备比模型选择更影响效果我见过太多人一上来就接 OpenAI 的 embedding 接口丢进去几千个 PDF然后就开始调参数。其实这些 PDF 里很多是扫描件、表格、双栏排版甚至带页眉页脚。解析不到位后面的检索和生成全是空中楼阁。图片型 PDF 要先 OCR表格要单独抽取双栏文档要按阅读顺序重排页眉页脚要去除。这一层做不好后面再牛的 RAG 框架也白搭。还有切片策略。热词里常提“rag教程”“rag框架”但很少人认真讲切片。切片不是越细越好也不是固定 500 token 就万事大吉。我的经验是按文档结构切段落语义完整优先标题和段落要保留关联信息代码、表格、列表类的特殊内容单独走不同的切法。切片是 RAG 里面最需要“手艺人感觉”的一环因为它直接决定了检索单元的信息完整性。3.3 评估瓶颈没有评测集你根本不知道改得好不好很多团队做 RAG 是“拍脑袋优化”今天换个 embedding 模型明天调一下 top_k效果好像变好了但不知道好在哪里也不知道是不是偶然。这背后缺的是评估体系。我现在的做法是每做一个知识库先人工标注 50 到 100 条典型问答对覆盖不同难度和类型然后跑一套自动评估指标检索准确率、召回命中率、生成答案的忠实度faithfulness和答案相关度。有了这个基准每次改动都能量化对比优化才有方向。这个环节在热词里很少被提到但我觉得它比模型选型重要得多。RAG 不是“配好就完事”它是一个持续迭代的系统评估体系是这个系统能不能演进的地基。3.4 顺带回应热搜RAG 知识库能存图片吗“rag知识库能存储图片嘛”这个词条最近挺火我的答案是能但要看你怎么存。如果你说的“存图片”是指把图片文件直接丢进向量库并让模型“看懂”那传统 RAG 做不到——向量模型基本是文本的图片得先过多模态模型转成描述文本或者向量才能参与检索。如果你的场景是产品图库、设计素材库那正确的做法是要么用多模态 embedding 模型比如 CLIP 系列的向量同时编码图片和文本要么给每张图片生成一段详细的文字描述再走文本 RAG。第二种方案最容易落地我做过一个商品素材库就是这个路子图片描述 标签 OCR 结果一起建索引效果很实用。4. 别让概念打架RAG 知识库、KG、结构化知识库到底怎么选热词里有一组很容易让人迷糊的概念“kg知识库”“rag知识库和结构知识库区分以及应用场景”“ontology rag”。我在社群答疑时发现很多人搞不清这些方案的区别选型全靠猜。这里我用一张表把它们讲透顺便把各自的应用场景说清楚。4.1 三种方案的本质差异方案核心存储结构检索方式擅长场景典型工具向量 RAG非结构化文本切片 向量索引语义相似度召回 重排文档问答、政策解读、客服知识库Chroma、FAISS、Milvus知识图谱 KG实体、关系、属性构成的三元组网络图谱遍历、多跳查询复杂关系推理、反欺诈、推荐解释Neo4j、JanusGraph结构化知识库表结构、字段约束、强类型数据SQL / API 精确查询订单、库存、财务、排班等强规则数据PostgreSQL、MySQL、DataHub一句话总结数据结构化程度越高越不需要向量检索数据之间的关联越复杂越需要图谱大段连续文本才是 RAG 的主场。4.2 什么时候该用知识图谱 KGKG 最强的能力是多跳推理。举个例子用户问“王总监下面团队的成员涉及了哪些项目”这种问题如果文档里没有现成句子纯靠向量 RAG 是召不回来的因为答案需要跨多个实体跳跃王总监 → 团队成员 → 成员参与的项目。图谱天生就是干这个的你提前把组织架构和项目关系建模成三元组查询时一次遍历就能拿到结果。我做过的风控项目里KG 的价值特别明显欺诈团伙识别靠的不是单条记录而是人和人之间的关系链。这类场景如果用 RAG 做效果会非常差因为文本不会把“关系”写得那么规整。但要注意KG 的建立和维护成本很高需要领域建模和数据清洗不是随便导入一堆文本就能自动生成的。4.3 结构化知识库别什么都塞向量库很多业务数据本来就在数据库里比如订单金额、库存数量、员工考勤。这类数据有精确值、有枚举约束、有唯一键你非要把它们切片向量化再让模型“猜”结果纯粹是自找麻烦。正确做法是让模型写 SQL 或调用 API 去查库返回结果后再生成自然语言回答。这就是所谓的 Text-to-SQL 或者 Function Calling 路线本质上就是让结构知识库归属到它自己该有的位置。我之前帮一个连锁门店做知识库他们把商品价格表、库存数据全都喂进了 RAG结果每次模型给的数字都对不上用户投诉多到崩溃。后来改成价格类问题直接转成 SQL 查询只有“退换货政策”“门店操作手册”这类文档内容走 RAG。同一个系统准确率一下就上去了。所以看到“rag知识库和结构知识库区分”这个热词我特别有共鸣很多人就是栽在这里。4.4 ontology RAG 是什么给 RAG 加一层“骨架”“ontology rag”是结构化思路和 RAG 的结合体。简单说就是在 RAG 的检索和生成之间加入一套领域本体模型。本体是什么就是某个领域里概念、属性、关系的正式定义比如医疗场景里的“症状”“疾病”“药物”以及它们之间的关联。ontology RAG 的思路是先用本体约束和引导检索而不是全靠 embedding 的“模糊相似”。用大白话说普通 RAG 是拿关键词去大海捞针ontology RAG 是先画一张“领域地图”让模型知道针大概落在哪片区域再去找。效果上最明显的变化是回答更规范、实体识别更准、不同问题之间的答案一致性更好。代价就是需要额外的建模和维护成本适合医疗、法律、金融这类领域知识边界清晰、错误代价高的场景。现在也有 GraphRAG 这类框架试图用知识图谱自动抽取 RAG 结合的方式降低建模成本但离“开箱即用”还有距离。5. 在 Mac 上从零搭一个 RAG 知识库前面讲了一堆概念和选型接下来是实打实的部分。热词里有一条是“怎么在mac上搭建rag知识库”我就针对这个问题写一份可以直接照着做的实战方案。我自己用的就是 MacBook ProM 芯片这套流程在 Intel Mac 上也能跑只是速度慢一些。先说选型思路。本地搭建我推荐一套组合Python 3.10、LangChain 或 LlamaIndex二选一、Chroma 向量库、Ollama 跑本地模型。为什么要本地模型因为 Mac 上跑 RAG 的乐趣就在于不依赖云 API数据不出本机而且 M 系列芯片的 GPU 加速跑 7B 级别的模型完全可行。你要是想用 OpenAI 接口也行步骤类似把模型源换一下就成。5.1 环境准备装好三样东西先装 Homebrew如果你已经装了跳过这步然后通过 Homebrew 安装 Python 和 Ollama。命令很简单/bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh) brew install python brew install ollamaOllama 装好之后拉取一个适合本地跑的模型。我日常用 Qwen 系列或者 Llama 3.2 的 7B 量化版中文效果比较稳。Embedding 模型可以选nomic-embed-text或者用bge-m3需要稍微配置一下。拉模型命令ollama pull qwen2.5:7b ollama pull nomic-embed-text然后创建一个虚拟环境避免依赖打架mkdir rag-lab cd rag-lab python3 -m venv .venv source .venv/bin/activate pip install chromadb langchain langchain-community langchain-chroma pypdf5.2 核心流程从 PDF 到可问答的知识库整个 RAG 流程可以分成四步加载文档 → 切片 → 向量化入库 → 检索问答。我直接给一份最小可运行的代码你把 PDF 放进docs/目录就能跑。from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_chroma import Chroma from langchain_community.llms import Ollama from langchain.chains import RetrievalQA # 1. 加载 PDF 文档 loader PyPDFLoader(docs/公司制度手册.pdf) documents loader.load() # 2. 切片按结构切chunk_size 设为 800overlap 设为 150 text_splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap150, separators[\n\n, \n, 。, , , , , , ] ) docs text_splitter.split_documents(documents) # 3. 向量化并存入 Chroma本地持久化到 ./db 目录 embedding OllamaEmbeddings(modelnomic-embed-text) vectorstore Chroma.from_documents( docs, embeddingembedding, persist_directory./db ) # 4. 初始化本地 LLM 并建立检索问答链 llm Ollama(modelqwen2.5:7b) qa_chain RetrievalQA.from_chain_type( llmllm, retrievervectorstore.as_retriever(search_kwargs{k: 4}), return_source_documentsTrue ) # 测试一下 result qa_chain.invoke({query: 请假超过三天需要什么流程}) print(result[result]) for doc in result[source_documents]: print(doc.page_content[:200])这段代码里有两个参数值得琢磨。chunk_size800和chunk_overlap150是我在中文制度文档上试出来的比较稳的组合。800 token 左右既不会让句子被拦腰截断也不会因为片段太长导致向量语义被稀释150 的 overlap 保证了跨段落的关键信息不会因为切片边界而丢失。你换不同领域文档后这两个值最好重新调一下。5.3 顺手优化接入长上下文模型做“二次精读”这是我最想强调的地方。RAG 召回之后生成环节完全可以用长上下文模型。也就是先让 RAG 把相关内容捞出来再把召回的 4-8 个片段全部喂给一个窗口比较大的模型让模型在受限上下文里做精读。这样既避开了全量塞入的成本问题又享受了长窗口模型更强的理解能力。上面代码里把Ollama(modelqwen2.5:7b)换成支持更长上下文的模型比如qwen2.5:14b或接入云端的 Claude / GPT 接口后面逻辑不用动。我还习惯在生成前加一个“去重和重排”步骤。Chroma 自带的相似度检索有时会把同一段落的相似片段堆在一起导致信息覆盖不足。我的做法是召回 top 20 个片段用交叉编码器重排再取 top 4 送入 LLM。重排这一步能明显提升答案的命中率尤其是知识库里相似文档很多的时候。5.4 想把知识库做进生产框架选型建议如果你不是为了跑通 demo而是要做一个长期维护的 RAG 服务我建议直接上 LlamaIndex 或者 Dify。LlamaIndex 对数据索引的管理更细腻适合“文档多、结构复杂”的检索场景Dify 则是图形化界面适合非工程团队快速搭企业内部知识库。两者都支持我前面说的混合检索、重排、评估这些高阶玩法比从零拼装的方案省心得多。6. 常见问题与排查技巧实录最后这部分是我这些年在多个 RAG 项目里攒下来的排查经验写成速查表方便大家直接用。6.1 高频问题速查现象常见原因解决建议问了问题检索出来的内容完全不相关切片粒度不对 / embedding 模型对领域术语不敏感先看召回结果确认是召回的问题还是生成的问题换领域微调过的 embedding 模型如 bge-m3或加关键词检索答案引用正确但表述不通顺拼接片段太碎模型上下文不连贯调大 overlap或者把召回片段按原文档顺序重排后再喂给模型回答总是“一本正经胡说八道”检索没召回关键内容模型在硬编检查召回命中率降低 top_k 的阈值或者做到“未命中就明说不知道”知识库更新后旧答案还在向量库没有增量删除 / 更新入库时记录文档来源和版本更新时先按来源删除旧 chunk 再插入新 chunk图片型 PDF 检索不到内容PDF 解析没做 OCR加 OCR 环节转成可检索的文本再走流程Mac 上加载模型后内存爆掉模型参数量太大 / 同时跑 embedding 和 LLM换 4B-7B 的量化模型用--num-gpu 999充分利用 M 系列 GPU 统一内存中文检索效果差分词或 embedding 模型对中文支持不好优先选针对中文优化的模型比如 bge-m3、Qwen 系列切片时按中文标点而不是英文空格切6.2 几条独家心得第一RAG 调试顺序很重要别一上来就调模型。先看“召回结果里到底有没有正确答案”如果召回都没有后面一切优化都是白搭如果召回有但答案不对再去换生成模型或者调 prompt。这条顺序能帮你省下大量瞎折腾的时间。第二一定给自己留一个评测集。哪怕只有 30 条问答对先把当前的准确率跑出来打底之后每一次改动都对着这个标准看是变好了还是变差了一目了然。没有评测集的 RAG 项目优化全靠感觉最后一定会烂在没有人知道哪次改错了上面。第三别迷信“大而全”的知识库。我见过很多团队想一次性把所有资料都导入 RAG结果检索噪音大到没法用。更务实的做法是先按高频问题圈定 50 到 100 份核心文档把这一小片做出高准确率再逐步扩量。每一次扩量后回归评测集守住准确率底线。说到这再回到开头的那个问题。长上下文模型的窗口越做越大每次发布新款大模型都会有人唱衰一次 RAG但真正落到业务里RAG 和长上下文非但不是竞争对手反而是互补搭档。根据我个人的实操经验一个成熟的 RAG 知识库真正难做的从来不是那个检索加生成的框架而是围绕它建立起来的数据治理能力、评估体系和迭代流程。框架会变模型会变但“先找到对的资料再让模型读懂它”这件事会一直是企业知识应用里最核心的命题。