企业官网建设流程全解析

做AI应用开发这两年，我最常被问到的就是“做知识库到底该用RAG还是直接上长文本大模型”。很多人觉得这俩都在解决同一个问题，让大模型“看到”更多内容，挑一个用就行。但我在实际项目中折腾下来，发现这两条技术路线的差异比想象中大得多，选错了轻则效果不达标，重则整个项目推到重来。

RAG全称是Retrieval-Augmented Generation，中文叫检索增强生成，落地的时候就是“先从知识库里把相关内容捞出来，再交给大模型结合上下文作答”。长文本大模型则是把模型本身的上下文窗口从几万token扩到十几万、几十万甚至上百万，把整份文档一次性塞进去靠模型自己读。

如果你也正在纠结这个问题，这篇内容会把两个方案的核心原理、真实成本、效果边界和我的选型经验一次讲透。后面的内容不是我抄文档抄出来的，是几个真实项目里一点一点调出来的。

1. 先搞清楚两个方案解决的是不是同一个问题

1.1 RAG的本质：两段式流水线

RAG的完整链路并不复杂：文档加载、切块、向量化、写入向量数据库；用户提问时把问题也向量化，从数据库里检索出最相关的若干片段，再把这些片段和原始问题一起拼进提示词，交给大模型生成答案。整个过程可以理解为“检索决定模型看什么，大模型决定怎么答”。

我为什么强调这个设计思路？因为它的核心是把知识存储和模型参数解耦了。想更新知识怎么办？不用重新训练模型，直接把新文档灌进去更新向量索引就行。答案错了怎么办？把检索出来的片段打开展示给用户看，问题出在哪个环节一目了然。这些特性让RAG在企业知识库、智能客服、私域数据问答这些场景里普及得非常快，根本不是偶然的，因为它天然满足企业对“可控”和“可解释”的需求。

但RAG也有自己的命门。分块切不好，检索结果就是垃圾；embedding模型选得不对，语义召回就一团糟；检索召回的片段不对，后面生成环节再强也白搭。检索和生成是串联关系，任何一个环节掉链子，整体效果就会崩。所以我一直觉得RAG入门容易，做好很难，真正的功夫都在那些看起来不起眼的细节上。

1.2 长文本模型的本质：把窗口拉大，让模型自己看

长文本大模型走的是另一条路。它不搞外部检索，直接靠扩大上下文窗口，把文档内容和模型的注意力机制连接起来。从几万token扩展到几十万甚至上百万token之后，你可以把一整本年报、几十页合同、整段技术文档直接丢进对话里。

长文本能力能落地，背后靠的是位置编码和注意力机制的双重改进。比如RoPE旋转位置编码让模型在超长序列里依然能感知词语的相对位置，ALiBi和YAARN这些方案则进一步把外推能力提上去。注意力层面也有了不少优化，稀疏注意力、滑动窗口、分块注意力这些手段都在把长上下文的计算成本往下压，不然百万token级别的推理在工程上根本跑不动。

我个人的理解，长文本模型其实是在模型侧解决了“要不要检索”这个问题。只要文档能塞进上下文窗口，模型就能自己找到重点。但问题也随之而来：窗口大不等于理解深，真实使用中经常出现信息被淹没、模型遗忘中间段落的情况。而且长上下文的计算成本不是线性增长，是超线性增长。这些细节后面我会结合实测数据仔细讲，这里先记住一个结论：长文本模型是强大的工具，但不是万能解药。

2. 一定要先对比的几个关键维度

2.1 知识更新速度决定架构上限

这一项基本没有悬念，RAG优势非常大。知识存放在外部数据库，更新只需要重新灌文档、重做向量索引。我之前做过的合同条款问答系统，法务每周都会更新合规细则，RAG方案里我做了增量索引，定时任务每天跑一遍，当天新内容就可以被检索到，这个体验是长文本模型给不了的。

长文本模型这边，知识是固化在参数里的。预训练完成之后，你没办法通过提示词让模型知道训练数据之外的新知识。虽然可以靠微调注入，但微调的成本、周期和风险都远高于重新灌文档。一条经验法则送给大家：业务知识每天、每周都在变的，不用考虑长文本路线，直接选RAG。

2.2 答案的可信度和可验证性对比

做行业应用时，用户不仅要答案，还要知道答案的出处。RAG天然支持这一点，它能把命中的文档片段直接展示出来，人工复核也方便。我做税务问答和医疗器械说明书问答项目时，这个能力是硬需求，业务方明确要求“每一条关键结论必须能对应到原文”，这种情况下只有RAG能接得住。

长文本模型这边就麻烦一些。模型虽然可以解释自己的思路，但解释也是生成出来的，同样存在幻觉的可能。你让它总结一份合同的风险点，它可能说得头头是道，但里面有一条风险点原文里根本没有，用户去核对原文时就会发现问题。所以在对溯源要求比较强的场景里，长文本模型单打独斗风险很高。

2.3 成本与延迟的隐性差异

选型时只盯着效果，把成本和延迟忽略掉，这是新人最容易犯的错。这两个参数在真实业务里往往决定项目能不能上线。

长文本模型的推理开销随上下文长度增长得非常快。模型窗口拉一倍，注意力计算量涨得更高，这意味着处理一份大文档时，单次请求的费用会远超你的预期。我实测过一份约50万token的技术文档，按当时某商业模型的价格，一次把全文塞进去提问，单次成本高得肉疼，几个来回就能烧掉不少预算。自托管开源长文本模型也有压力，显存需求极大，没有高端GPU集群根本跑不动。

RAG这边，主要成本集中在文档向量化和向量检索维护上。embedding模型的调用成本很低，向量数据库用开源的pgvector、Milvus都能跑，推理时只需要把检索出的几个片段拼进上下文，token消耗比长文本方案低几十倍。延迟上差距更明显，长文本请求常常要等几十秒，RAG检索加生成基本能控制在几秒内，对交互式应用来说这个差距是致命的。

2.4 标称上下文长度和真实可用上下文长度

很多模型宣称支持128K上下文，但你实际塞进去80K内容就会发现，中间部分经常“失忆”。业内常用的“大海捞针”测试就是专门验证这个的，在一段超长文本的某个位置埋入一句话，看模型能不能准确找出来。结果因模型而异，但即便通过了测试，也不代表复杂推理场景下表现稳定。

我印象很深的一次，用某长上下文模型读一份100页的报告，开头和结尾的信息都回答得很好，唯独问到报告偏中间位置的关键数据时，模型给出的数字是错的。这就是典型的长文本“两头稳中间弱”。RAG反而没有这个问题，因为它是先定位再读取，检索机制能找到文档任意位置的内容。这也是我在处理长文档类需求时，经常在RAG和长文本之间摇摆的原因，各有千秋。

3. RAG落地时我踩过的坑与经验

3.1 分块这块真的不能随便切

RAG效果翻车，十有八九是分块没做好。分块太大，检索出的片段噪声多、信息密度低；分块太小，语义断裂，一个完整事件被拆得七零八落。我踩得最狠的坑是直接用固定长度切PDF，结果把表格和标题切碎了，检索到的内容完全没法读。

现在比较靠谱的思路是结构分块加重叠窗口。优先按标题、段落、表格这些文档结构信息去切，保留语义完整性；如果没有明确结构，再用固定长度切，同时设置10%到15%的重叠，避免关键信息恰好落在切割线上。长度我没有一个万能值，一般先看文档类型：FAQ类用256到512字符，长文报告可以放宽到512到1024字符，然后再根据召回效果慢慢调整。

还有一种很实用的方法是父子分块。父块大，子块小，先用子块去召回，命中后把子块对应的父块一块儿交给模型生成答案。这么做兼顾了召回粒度和上下文完整性，我在做多轮对话知识库时经常用，效果比我预想的好很多。

3.2 向量检索不等于全部，混合检索是常态

很多人以为RAG就是向量检索，大错特错。只用向量检索，召回效果通常不够理想。向量模型擅长捕捉语义相近，但对精确型号、编号、人名这类信息非常不敏感。用户输入一个“A100服务器故障排查”，向量检索可能召回一堆GPU相关的内容，关键词匹配却能直接锁定包含“A100”的文档。

我现在做RAG基本都是混合检索，把向量检索和关键词检索的结果做归一化合并，再统一排序。实测数据，纯向量检索的召回率大概在70%，加上关键词检索后能到85%以上，提升非常显著。除此之外，检索前还需要做查询改写，用户提问往往口语化，直接拿去检索效果不好，可以先让大模型做一次意图识别和关键词提取，再执行检索。这一步也是Agentic RAG的核心思路，把简单的“检索-生成”升级为“理解-规划-检索-再生成”。

3.3 重排序才是质的提升

做完混合检索就直接把结果交给大模型？如果是这样就漏了最重要的环节。向量检索返回的排序依赖于嵌入空间的相似度，但“语义相似”和“对回答问题有用”是两回事。重排序模型的任务就是站在问题角度，对召回结果重新打分，把真正有用的片段排前面。加了这一步，回答质量基本能再上一个台阶。

我的做法是两阶段检索。第一阶段用向量和关键词混合召回，取Top 50到Top 100；第二阶段用交叉编码器模型重排序，取Top 10以内交给大模型。重排序模型我用过开源的bge-reranker，也用过商业的Cohere Rerank，前者可以本地部署，成本低，性价比更高。你要是刚起步，先别追求复杂的graphRAG，把重排序加进去，效果就已经能超过大多数默认配置。

4. 长文本模型实测的一些感受

4.1 能过“大海捞针”，不代表真的好用

长文本模型评测几乎都会引用“大海捞针”测试，把一段特定信息埋在超长文本里，看模型能不能找出来。这个测试能过，说明模型具备基本的长文本定位能力，但现实项目里我发现问题没那么简单。真实业务往往不是只找单点信息，而是要做长链条推理和多点信息聚合，这种任务对注意力分配要求特别高，长文本模型的表现波动非常大。

举个例子，让模型总结100页会议纪要它能搞定，让它比较3个不同章节里的预算数据差异，它偶尔会漏掉其中一条数据。原因在于上下文越长，注意力权重被稀释得越厉害，模型很难对所有片段保持同等关注度。所以如果你要做的是长文档的强推理和多点比对，建议别把宝全压在长文本模型上，要么做预提取，要么切分处理。

4.2 长文本模型的隐性成本和工程问题

成本问题我再强调一遍，因为它影响实在太大了。处理50万token的文档，RAG每轮只需把检索出的3到5个片段拼进上下文，token消耗可能只有几千；长文本模型直接全文送入，单次就要50万token。两者差距几十倍，积少成多就是天壤之别。

延迟上差距也很直观。长文本请求动辄几十秒才能返回，有时候用户等得不耐烦直接关掉页面了。RAG的响应时间基本跟随检索速度和生成速度，整体体感快得多。做过多轮对话场景的人应该都有体会，几十秒的等待在交互体验上是不能接受的。所以但凡业务对延迟敏感，长文本模型的部署方案就要再三掂量。

4.3 什么时候真的该选长文本模型

说了不少长文本模型的短板，但它并非一无是处。最大的优势就是不需要复杂工程链路，文档丢进去就能用，很适合快速原型验证和一次性深度分析。分析整本书、做全局宏观总结、跨章节观点对比，这些任务RAG反而可能因为切块导致上下文碎片化而吃亏。

另外，如果文本本身篇幅虽然长，但结构比较清晰，核心观点集中，长文本模型可以直接产出不错的结果。我建议这样判断：追求快速上手、宏观理解的场景，长文本模型优先；追求精确、可溯源、知识实时更新的生产级场景，RAG优先。

5. 实际决策框架：拿表对着选

5.1 一张表帮你快速判断方向

我把多个项目里总结出的选型要点整理成了一张表。核心看三条：知识更新频率、答案溯源要求、单次处理文档的体量。结合下表就能快速判断大方向。

5.2 混合方案才是最终归宿

现实项目里我很少会只押注一种方案，基本都做成路由模式，先判断用户意图再决定走哪条链路。知识库问答和事实查询走RAG，整篇文档总结、跨章节观点对比走长文本。两套链路共用同一份文档管理底座，只是最终交给模型的上下文来源不同。

想再进一步，可以引入Agentic RAG的思路，让Agent先规划“这个问题需要读哪些章节”，再决定去检索还是直接读取原始文档，最后汇总生成。这个方案是LangGraph这类编排框架非常擅长的，结合FastAPI做服务层，pgvector、Milvus做向量存储，可靠性很高。我最近几个项目基本都是这个架构，既保留了RAG的知识时效性和可溯源性，又借助长文本模型补足了整体理解能力，效果比单一方案扎实得多。

6. 遇到过的典型问题与处理实录

6.1 RAG答非所问，先查召回不查模型

RAG返回的答案明显跑偏时，很多人第一反应是换一个大模型，我反而会先看召回片段对不对。见过的反馈里，大部分答非所问都是因为召回的片段压根不含关键信息。处理步骤很固定：先把最终交给模型的上下文打印出来，人工看关键信息在不在。如果不在，检查切块策略和召回数量，看看是不是切块把关键句切碎了，或者向量召回数量太少漏掉了正确答案。如果关键信息在，再去检查提示词有没有明确要求模型只能基于上下文作答，否则模型容易自由发挥。

6.2 长文本“看是看了，但没用上”

长文本模型处理超长内容时，最典型的故障是信息明明在上下文里，回答时却没用上。这种情况我的对策是增加一个预提取步骤，先让一个轻量模型对全文做要点抽取，把抽取结果压缩进上下文，再把原始长文作为附加上下文一起给主模型。相当于第一遍先做精读，主模型再针对重点内容做深度处理。如果是RAG路径，这个预提取出的关键句子也可以当作文档摘要写入向量库，检索命中摘要后再返回对应章节原文，效果同样很好。

6.3 混合链路里的一致性维护

RAG和长文本链路同时使用时，最容易被忽略的问题是配置不一致。两条链路可能用了不同模型、不同切块策略，导致同一份文档在两条链路里的版本不一致，最终结论打架。我在项目中把底层文档处理流程统一了，每个文档生成唯一文档ID，检索和长文本读取都基于同一套ID体系，版本更替时同步更新。这样用户无论走哪条链路，看到的都是同一版本内容，就不会自己打自己脸了。

踩过几次坑之后，我的体会是：选RAG还是长文本大模型，本质上不是技术路线之争，而是业务目标在技术方案上的折射。知识要实时更新、答案要可溯源、成本要可控，就踏踏实实搭好RAG基建，把切块、混合检索、重排序这些环节磨细；如果只是分析长篇内容、快速产出洞察，长文本模型的直接性确实无可替代。最理想的状态不是二选一，而是把两者组合起来，各取所长。

最后再分享一个小技巧。做技术选型千万别急着写代码，先整理20条真实业务问题，分别用两套方案跑一遍，人工对比答案质量和响应时延。20条问题跑完，你的项目更适合哪条路，基本就清楚了。