RAG与长文本大模型：架构选型、成本对比与工程实践

1. 先搞清楚两个方案到底在解决什么问题在做RAG和长文本大模型选型之前我们先理清一个基本概念。RAGRetrieval-Augmented Generation检索增强生成的核心思路是你别让模型硬背全部内容把资料切块存进向量库用户提问时先检索出最相关的片段再把片段和大模型一起组装答案。长文本路线则完全不同你直接把整份文档塞进上下文窗口让模型一次性读完再回答。一个是“查字典再答题”一个是“把整本书背进脑子里再做题”。很多人在架构选型时纠结的点在于我的场景到底适合哪种这个问题没有标准答案取决于几个硬指标——上下文长度、知识更新频率、单次调用成本、检索精度要求、部署复杂度、权限细分粒度。我在多个项目里把这两条路线都跑过接下来从工程技术角度拆解这两条路线的细节、成本计算方式、坑点以及我认为最务实的架构策略。先说一个反直觉的结论长文本窗口的快速发展并没有让RAG失去存在价值反而推动RAG从“简单向量检索”往“混合检索重排序Agent调度”的更高复杂度演进。今天这两者更像是互补关系而不是纯替代关系。如果你在做一个只需要处理几千字PDF、文档不会持续增长、回答精确度要求不高的Demo长文本方案可能更快上线。但如果你面对的是不断更新的企业知识库、需要精细权限控制、对答非所问零容忍的生产系统RAG几乎还是必然选择。下面详细展开。2. RAG的核心流程与工程落地细节2.1 RAG的完整链路与各环节作用RAG最基础的流程是加载文档、切块、调用Embedding模型向量化、存入向量数据库、用户提问时向量化问题、检索TopK相关块、重排序、组装提示词、调用生成模型最终输出答案。这九步每一环都影响最终效果。一个常见误区是觉得只要接上了向量库就算做完了RAG。实际生产中每一环都可能成为瓶颈。比如加载环节不同文档格式PDF、Word、Markdown、扫描件的解析质量差异巨大纯文本提取和版面识别出来的结果完全不同切块策略直接决定检索召回率Embedding模型选型决定语义理解的粒度重排序模型决定候选块能否被精准排序。我在实战中养成了一个习惯先把RAG整体跑通再逐个环节调优。不要在一开始就追求完美切块策略或最优向量库先保证链路能通再根据实际效果反推哪个环节有问题。这个思路很像调优一个网络服务——先确认连通性再做性能优化。2.2 文本切块策略的选型与参数计算文本切块是整个RAG里最容易被低估的环节但它对召回效果的影响几乎占六成以上。切块的核心矛盾是块太小语义不完整检索到的内容碎片化块太大混入无关信息Embedding向量被稀释而且塞给大模型的Token成本升高。理想状态下切块粒度要尽量保证每一块表达一个完整主题。具体切块策略大致分四类固定长度切块按固定字符数切简单但容易切断语义。适合结构简单、格式统一的文档。递归字符切块按段落、句子、子句的优先级逐级切分是LangChain里最常用的方案兼顾灵活性和结构完整性。文档结构感知切块按Markdown标题、代码文件函数、LateX章节等结构边界切块适合有清晰大纲的技术文档。语义切块用Embedding/BERT计算句子相似度动态合并语义相近的句子。效果最好但计算成本高适合内容质量要求极高的场景。参数计算方面以递归切块为例核心参数是chunk_size和chunk_overlap。我的经验是chunk_size设在300到800之间overlap设置为chunk_size的10%到20%。为什么需要overlap因为同一句话如果被硬切进两个块检索时两块都可能召回但都不完整overlap可以缓解这个问题。比如chunk_size500overlap100切出的块大致就是1到500401到900801到1300这样的区间。对于中文内容切块前必须做清洗去掉多余换行、合并断行、处理全角半角空格。中文没有空格分词切块时按字节切很容易切断词汇建议按len(text)计算字符数而不是字节数同时避免在切分点落在数字、英文单词中间。这个细节虽然小但在实际检索结果中影响非常明显。2.3 Embedding模型选型与向量数据库的关键维度Embedding质量直接决定检索结果的语义相关性。目前中文场景下主流方案有OpenAI的text-embedding-3-small和text-embedding-3-large、智源的bge-large-zh系列、阿里的text-embedding-v3、Cohere的embed-v3等。选择Embedding模型时核心看三个指标中文语义理解能力、向量维度、推理速度。中文场景里bge-large-zh在MTEB中文榜单上表现稳定而且可以本地部署不需要额外API费用。向量维度上text-embedding-3-small支持通过dimensions参数控制维度知识库规模不大时甚至可以用256维检索速度更快精度损失在可接受范围内。向量库选型则要综合并发能力、过滤能力和运维成本来考虑。向量数据库这块社区热门选择有pgvector、Milvus、Qdrant、Chroma、Weaviate。我自己的经验是如果团队已有PostgreSQLpgvector是最平滑的起步选择零额外基础设施单表几百万向量完全够用如果数据量达到千万级或者需要复杂过滤、流式写入Milvus和Qdrant更合适。Chroma更适合本地原型快速验证不适合直接当生产级向量库用。这里提一个容易忽视的细节做向量检索前先把文档元数据如来源、章节、时间戳存进向量库的payload或字段里检索时用元数据过滤Metadata Filter可以大幅提升精确度。比如在客服系统里用户问题检索时就能先过滤掉已失效的旧版本文档只从当前版本中召回。没有元数据过滤的RAG回答里出现“旧版本还有这个政策”的情况极其常见。2.4 混合检索与重排序的必要性单纯依赖向量检索有一个典型毛病语义相似但关键词不同时召回好关键词完全匹配但语义表达差异大时反而召回差。很多业务问题本质上是关键词命中的问题比如查“退货政策”用户问的是“七天无理由怎么退”向量检索可能召回效果一般但BM25全文检索时“退货”这个词在文本里实打实地出现了匹配非常稳定。于是就有了混合检索把向量检索结果和关键词检索结果做加权融合再交给重排序模型打精排分。混合检索的融合策略我常用的是Reciprocal Rank FusionRRF公式很简单score(d) Σ [ 1 / (k rank_i(d)) ]其中k一般取60rank_i是文档在某个检索方式下的排名。RRF的优点是不依赖不同检索方式返回的分数尺度只依赖排名这样向量检索和BM25的分数差异不会影响融合结果。重排序方面bge-reranker-base/large是目前中文场景下性价比最高的方案之一。检索阶段先召回Top50到Top100个候选块重排序阶段用bge-reranker对这些块逐对打分取Top5到Top10喂给大模型。这样做能显著提高最终答案的准确率代价是多了一次模型推理耗时在100到300毫秒之间。生产环境里这个成本是值得花的。2.5 RAG的成本结构与Token消耗模型RAG的成本结构相对清晰核心是三块检索阶段、Embedding阶段、生成阶段。检索阶段是向量数据库的计算成本和可能的全文检索成本一般很低Embedding阶段看你是自建还是调API自建主要消耗GPU调API按Token计费生成阶段是大模型输出答案的Token消耗这里的成本大头在输入侧。具体算一笔账。假设知识库总量是100万个字符约合30万Token中文字符按1个汉字约等于1.5个Token估算不同模型分词器略有差异。用户每次提问时RAG检索出10个块每块500字符合计5000字符约合7500个Token加上系统提示词和用户问题每次调用输入Token总量约为一万。如果采用长文本方案把100万字符全部塞进上下文每次调用输入Token约30万是RAG的30倍。这里还没算向量化的前期成本。100万字符约莫是2000到3000个块Embedding一次全部向量化如果用API按每百万Token计价成本并不高但如果是自建Embedding服务主要是机器的一次性开销。RAG真正贵的地方在于迭代调优时的重复向量化成本每次调整切块策略重新向量化都会产生额外的Embedding费用。2.6 RAG在真实项目中的表现和调试心得我在一个实际的知识库问答系统里处理的是约5000页产品文档和内部FAQ。最初直接用最简单的固定长度切块向量检索准确率大概只有60%左右很多回答答非所问或者引用过时的方案。后续做了四件事效果提升到90%以上把固定长度切块换成按Markdown标题递归切块每个二级标题下内容单独成块语义完整性大幅提升。将搜索引擎召回改为向量检索BM25混合RRF权重融合解决了“关键词必须精确命中”和“语义理解不足”两头的问题。接入bge-reranker-large重排序Top5准确率明显提升。在向量库中增加元数据过滤用户提问时带上业务线条件避免跨业务线的召回噪声。调参过程中最深刻的体会RAG通过一堆小环节的叠加优化才能达到可用水平不存在一个魔法开关。不要轻信Demo里那种“开箱即用”的RAG框架生产级RAG本质上是一个需要持续打磨的信息检索系统而不是一锤子买卖的模型接口调用。3. 长文本大模型什么时候直接塞进去3.1 长文本方案的原理与上下文限制长文本大模型路线的本质是扩大模型接收的输入Token上限让模型在完整上下文中生成回答。从GPT-4的8K、32K到Claude的200K再到Gemini的1M百万Token上下文窗口确实在指数级增长。但“上下文窗口大”不等于“模型真的能理解和利用窗口里所有内容”这里有著名的“Lost in the Middle”现象——模型对于长上下文中间位置的信息利用率偏低开头和结尾的信息更容易被注意到。所以长文本方案并不是简单“把文档全部塞进去就能准确回答问题”。实际测试中当上下文超过一定长度比如50K Token以上模型的回答质量会呈现明显的衰减曲线。这不是模型“变笨了”而是注意力机制在极长序列下无法对所有位置保持同等关注。这直接关系到什么时候适合直接使用长文本路线文档长度在几千Token以内、内容高度集中、结构简单直接塞进去效果很好文档几十万字、内容分散、需要跨章节关联长文本方案的效果会随上下文膨胀而快速下降成本也随之攀升。3.2 长文本的上下文缓存机制与成本优化长文本路线成本高的关键在于每次调用都会把全部输入Token发送给模型即便你连续问十个问题每个问题都携带相同的大文档这些共享前缀都要重复计费。为了解决这个问题Anthropic推出了Prompt CachingGoogle推出了Context CachingOpenAI也提供了自动缓存机制。以Anthropic的Prompt Caching为例缓存规则是输入Token中与历史请求命中相同前缀的部分重复使用时以更低的缓存读取费率计费。比如一次输入30万Token的请求首次写入按标准输入价格计费后续5分钟内相同前缀内容再来时缓存命中部分价格只有原价的十分之一左右不同模型费率不同。这意味着连续对话场景下第一次调用是贵的后续调用会便宜很多。这改变了长文本方案的成本公式如果用户会在一个会话内连续追问长文本方案的边际成本并不像单次计算看起来那么夸张。我在一个文档问答试点项目里实测过用户平均每个会话问5到8个问题开启缓存后单次提问成本比首次降低了60%到80%。3.3 寻找内容 vs 使用内容长文本与RAG的本质区别IBM在分析RAG与长上下文技术路线时提出过一个非常透彻的框架RAG擅长“寻找内容”Find the Needle长文本模型擅长“使用内容”Use the Needle。RAG通过检索机制把最相关的信息片段从大规模语料中拎出来天然适配海量知识库长文本模型虽然没有显式检索但你喂给它什么它就用什么把“寻找”的责任转移到了使用者用户或上层路由身上。这就解释了为什么很多企业知识库场景仍然选择RAG而不是全部切换成长文本方案知识库体量动辄几十万、几百万文档即便上下文窗口扩展到1M Token也只能覆盖约75万英文单词或50万中文字符放进完整企业知识库里不过是九牛一毛。更不用说再大的Token窗口也装不下持续增长的知识库全量。而RAG是在全量语料上先做一次检索缩小范围只用最后相关的几千Token做生成理论上知识库规模扩展不增加生成成本。顺便说一个容易被忽略的点长文本方案的“寻找内容”能力依赖模型内部注意力对长尾知识的定位能力不稳定且无法接受外部索引约束。换句话说用户没法像RAG那样用标签、时间、业务线来过滤知识范围。在需要强约束检索的项目里长文本会显得力不从心但在代码生成、复杂推理这类需要连贯理解长上下文的场景长文本的直接优势又是RAG无法替代的。4. 混合方案检索 长上下文路由4.1 静态切块 vs 长文本直塞的取舍思路有没有一种架构能把RAG和长文本的优势同时用上我见过不少团队在尝试其中最务实的一种是先用检索做粗筛再用长上下文模型做精读。具体可以有两种实现方式一种是给RAG增加一个判断路由当用户的问题是“这个问题的答案可能分散在多处需要全局对照”时系统先做一轮粗检索如果召回的TopK块之间高度重合或者查询本身比较宽泛就加大上下文投入把更多检索结果或完整文档直接塞给长上下文模型精读如果问题是明确的事实性问答就走传统RAG的精简路径。另一种是将知识库按文档重要程度和读取频率分层高频核心文档走长文本直塞模式保证推理质量低频海量文档走RAG检索模式保证覆盖范围。这种混合路由可以避免RAG召回不完整又避免长文本在超大规模知识库上成本失控。4.2 LangGraph实现动态路由的示例这里给出一个基于LangGraph的简化示例思路。LangGraph适合构建有状态、可分支的Agent工作流用它的StateGraph可以让路由显式化。from langgraph.graph import StateGraph, END from typing import TypedDict, List class RagState(TypedDict): question: str docs: List[str] route: str def should_use_long_context(state: RagState) - str: question state[question] # 判断规则如果问题包含“对比”“总结”“全文”“整体”等全局性动词 # 或者检索结果少于2块说明信息碎片化严重走长上下文路径 global_markers [对比, 总结, 全文, 整体, 差异, 异同] if any(m in question for m in global_markers) or len(state[docs]) 2: return long_context return rag_generate graph StateGraph(RagState) graph.add_node(retrieve, retrieve_docs) graph.add_node(rag_generate, rag_generate) graph.add_node(long_context_generate, long_context_generate) graph.add_conditional_edges( retrieve, should_use_long_context, {long_context: long_context_generate, rag_generate: rag_generate} ) graph.add_edge(rag_generate, END) graph.add_edge(long_context_generate, END) graph.set_entry_point(retrieve)这段代码的核心思路是把“走哪条路”的决策从写死的规则变成可配置的路由函数。实际业务里路由条件可以是问题长度、检索结果置信度、用户所在业务线、甚至是历史交互数据训练的轻量分类器。路由本身是一个成本/质量权衡器目标不是追求某一侧最优而是让整体体验和成本同时可接受。顺便多说一句LangGraph真正有价值的地方是它的可观测性。每一条会话的流转路径、每个节点的输入输出、耗时和成本都能被记录和回溯这对于生产系统排查“为什么某个问题回答质量差”极其关键。我见过很多团队调RAG只盯着向量库和模型却忽略整个流程的日志追踪导致问题根本无法定位。5. 不同场景下的选型建议与避坑清单5.1 我建议直接选RAG的场景以下场景RAG仍是更稳妥的选择知识库大且持续增长文档总量超过模型上下文窗口或者知识每周都在更新RAG通过增量向量化可以做到知识即更即用。权限隔离要求高不同角色只能看到不同范围的知识RAG可以在检索阶段按元数据过滤而长文本路线下上下文一旦包含越权内容模型无法做到细粒度遮蔽。对引用来源有硬要求企业审计、法律合规、医疗咨询等领域要求回答必须标注出处RAG检索出的块天然带来源路径。成本敏感且高频调用每次调用只喂给模型最相关的几千Token而不是全量文档输入成本可以降低一个数量级不算缓存的情况下。低幻觉容错率RAG的回答锚定在真实文档片段上虽然在生成时仍可能发生幻觉但相比纯长文本约束力强不少幻觉概率显著降低。5.2 我建议考虑长文本方案或混合路线的场景文档体量可控、单次对话内连续追问上下文缓存的加入让多轮追问时成本下降非常明显长文本体验更连贯模型甚至可以自己对照前后文做推断。需要跨多个文档综合推理比如对比多份供应商合同条款长文本模型可以把所有合同一次读完协同推理的能力更强RAG在这种场景下需要额外设计“检索多个块 汇总”的流程操作复杂且容易漏。问答过程中有强背景依赖模型需要理解文档“字里行间”的隐含信息例如代码仓库源码分析、长篇研究报告的上下文推理长文本的注意力优势更明显。RAG召回率确实上不去如果尝试了各种切块、混合检索、重排序策略答案仍不理想那很可能是知识本身是强关联、不可分割的整体。这时放弃“拆块”思路直接在长文本模式下处理往往比继续优化RAG更有效。5.3 实操中的注意事项和常见问题无论选哪条路线有几个坑希望你别踩不要无脑追求大窗口上下文窗口是能力也是负担越长的输入意味着越长的预填充时间首Token延迟会明显上升。用户等不住就是体验失败。RAG不是一次性工程它需要根据线上问答记录持续迭代切块策略、筛选器、重排序模型和提示词。在我的经验里一个新知识库上线后至少要两周的调优周期。注意向量化一致性文档入库和用户提问尽量用同一个Embedding模型不要混用。如果后续要升级Embedding模型整个知识库需要重新向量化这一步不能偷懒。切块时保留块与块的关联信息在元数据里记录文档ID、章节路径、页码等信息检索结果返回给大模型时可以附带上下文路径让模型“知道自己在看哪份文档的哪一节”回答质量会显著提升。长文本方案也需要设置安全阀即便上下文窗口很大也要在应用层做Token超限检测防止用户通过超长输入触发幻觉或性能崩溃。这个检测逻辑写在上游路由比依赖模型硬扛更可靠。生产系统里没有银弹。我在实际项目中见过不少团队被“大模型什么都能做”的宣传迷惑看到一个长上下文模型参数很高就直接把知识库全量喂进去结果很快被成本、延迟和幻觉三重问题拖垮。也有团队迷信RAG万能结果在一些强语境、弱检索的场景里始终回答不到点上。这两种极端都不可取。我个人的体会是把RAG当作默认选项把长文本当作兜底和增强选项把“检索长上下文路由”作为复杂场景的演进方向。先用小成本跑通POC把两类方案在真实数据集上的准确率、首Token延迟、单次调用成本量化出来再决定主路线。不要凭直觉拍板也不要被市场热词带了节奏。数据永远比观点可靠。