企业官网建设流程全解析

1. 从“1M上下文”说起：这场争论到底在吵什么

最近在各个技术社区里，RAG（检索增强生成）和长上下文的关系几乎成了日经话题。一有大模型宣布支持百万级 token，评论区必然出现“RAG 可以退休了”的论调。我做了几年大模型应用落地，也踩过不少检索增强的坑，想用自己的实际经验把这件事彻底讲明白。

先说结论：长上下文确实抢走了一部分本该属于 RAG 的工作，但距离“淘汰 RAG”还差得远。它们更像是一对互补的工具，各自解决不同层面的问题。如果你正在做知识库问答、私有化部署、Agent 应用，或者刚入门 RAG 准备在 Mac 上搭一个实验环境，这篇文章会给你一个比较完整的视角。

为什么这个问题会被反复讨论？因为从表面看，给模型塞更多上下文确实比“先检索再生成”简单直接。长上下文模型不需要额外维护索引、不需要配置向量库、不需要操心分块策略——把文档全量丢进去，模型自己找答案，效果在短文本、单文档场景下也确实更省事。但一旦深入到真实业务场景，你会发现事情没那么简单。

2. 长上下文真正解决的是什么问题

2.1 长上下文终结了哪些“伪需求”

坦白说，RAG 的一部分历史包袱确实被长上下文卸掉了。两年前做 RAG 系统，很多时候折腾半天是在对付模型的硬伤——上下文窗口只有 4K、8K，一段几千字的合同都装不下，不得不拆得稀碎再检索拼装。现在主流模型的窗口动辄 128K 起步，旗舰级别直接卷到 1M，处理整本书、整个代码仓库已经不是新鲜事。

这种变化最直接的受益者是几类场景：

• 单文档深度分析：比如读一份几百页的 PDF 财报，或者分析一个大型开源项目的全部源码。全量塞进去，模型有完整上下文，理解连贯，不需要检索。
• 跨章节逻辑推理：一份文档里的信息分布在前后三十页，RAG 检索出来的碎片往往难以维持完整推理链条，长上下文反而有优势。
• 代码仓库理解：函数的定义在 A 文件，调用在 B 文件，注释在 C 文件。全量输入时模型能看到全局依赖关系，而 RAG 高频检索可能丢三落四。

我之前做过一个合同审查项目，早期用 RAG 方案，分块检索出来的条款经常上下文不全，模型判断不够稳。后来换成长上下文直接整本输入，合同条款的前后引用、定义与例外条款的依赖关系都能被完整覆盖。在这种“一篇文章一个主题”的场景里，长上下文就是把路修到了家门口，RAG 反而像是在小区里绕路。

2.2 长上下文的天花板在哪里

但长上下文并不是银弹。最早让我产生怀疑的是一个常规的财务问答项目：文档库里存储了近几年的发票、合同、报销单，总量十万多页，全量塞给长上下文模型根本不可能——1M token 窗口在百万页面前渺小得可笑。这直接暴露了长上下文的一个硬性限制：窗口再长，物理世界里的知识总量总是远远超出单次输入上限。

更麻烦的是注意力机制本身的“偏科”问题。学术界有个著名发现叫“迷失在中间”（Lost in the Middle）：当输入文本变长时，模型对开头和结尾内容的注意力明显优于中段。我实测过用长上下文模型读一份 200 页的混合文档，让它回答埋藏在第 80 页细节处的具体问题时，准确率明显下降。这不是厂商参数吹牛能解决的，而是 Transformer 架构的内在问题。

还有个被很多人忽视的工程现实：token 都是要钱的，而且越长越贵。

以国内某主流模型为例，假设输入 1M token 的成本算下来单次调用就不是个小数目，如果业务每天有上千次提问，这笔账根本算不过来。如果检索后只把相关片段传进去，成本能减少 90% 以上。延迟也是同样的道理——输入越长，首字延迟越长。在客服、搜索这类对实时性敏感的场景里，用户可等不了每次请求都读十几万 token。

3. RAG 不可替代的四张底牌

3.1 动态知识：长上下文装不进“正在发生的事”

长上下文有一个致命短板：它的知识在训练/输入那一刻就冻结了。但现实业务里，知识是每小时都在变的。

举个例子，我曾经负责过一个企业内部规章制度问答系统。公司的报销政策每年调整，产品文档随版本迭代，人员架构表三个月一大变。如果用长上下文方案，每次知识更新都要重新构建整个输入——如果知识库里是上千篇文档，这既慢又不现实。RAG 方案里，知识入库时做向量化，新增一条政策只需要处理这一篇文档，检索时天然拿到的就是最新内容。这种“持续更新的活知识”，长上下文永远替不了。

3.2 私有知识可控性：企业不敢把家底全交给模型

做内部落地的人最清楚，企业知识库里有大量敏感数据：薪酬结构、未公开的财报、客户个人信息、核心源码。全量塞给模型，意味着这些数据全部暴露在模型服务商的 API 调用链路里——本地部署能缓解一部分，但没法彻底消除隐患。

RAG 体系里，数据默认不离开企业自己的存储和检索层，只有命中的片段拼接后才会进入生成模型，而拼接过程完全受你自己控制。你甚至可以再加一层脱敏中间件，在检索结果进入 Prompt 之前做字段级别的过滤。长上下文是“把整个保险柜搬出去让外人翻”，RAG 是“只递一两张你审核过的卡片”。对于合规要求严格的行业，这不是效率问题，而是根本没有选择的问题。

3.3 可解释性：出了问题你得能说出“为什么”

我接触过不少甲方，他们的验收标准里明确要求：AI 给出的每一个结论，必须能定位到知识库中某篇原文的某个段落。RAG 天生自带这种属性——检索返回的文档就是证据链，你可以把引用来源直接展示给用户，也可以在系统日志里完整追溯“哪个问题→检索了哪些文档→哪个段落参与了答案生成”。

长上下文则是一个“黑盒爆炸”：答案可能基于第 3 页的内容，也可能基于第 157 页的某句话，生成过程你无从审计，出了错也很难定位。在医疗、法律、金融这类高风险场景，这种差距直接决定能否落地。

3.4 计算成本与性能弹性

说到底，工程决策的本质是算账。RAG 最被人低估的优势其实是成本结构。

假设你的知识库有 100 万 token 的内容，做 10 次提问：

最理想的情况下，RAG 能做到两个数量级的成本差距。再加上长上下文模型对显存和计算资源的需求呈指数级增长，单机部署长上下文模型通常必须在吞吐量和延迟之间二选一。而 RAG 因为输入精炼，可以同时保住高并发和低延迟，这是业务上线时每天都在面对的硬指标。

4. 你真正需要的是一个增强体系，而不是二选一

4.1 第一层进补：别用坏了向量检索的“天灵盖”

逛 RAG 相关讨论时，最常见的抱怨就是“检索出来一堆不相关的东西”。这其实不是 RAG 的错，而是很多团队只用了最朴素的向量相似度检索，把 RAG 做成了“裸奔版”。

传统向量检索的问题在于，语义相似度和“能不能回答这个问题”是两回事。我举一个亲身经历：知识库里有很多关于“苹果价格”的内容，用户问“苹果公司今年的营收怎么样”，向量检索会返回大量水果价格数据——因为语义上都在聊“苹果”。单纯靠 embeddings 排序，模型很可能会拿着一堆炒股资料回答水果行情。

这就是为什么现在主流方案都在做混合检索（Hybrid Search）：向量检索负责语义模糊匹配，BM25 这类稀疏检索负责精确匹配，再用 RRF（Reciprocal Rank Fusion）把两种排序结果合并。加上一个Reranker 重排模型，在检索出 Top 50 的低成本结果上再做精密排序，只把 Top 5 喂给大模型，准确率的提升是肉眼可见的。

4.2 第二层进补：从 RAG 到 GraphRAG 与 Ontology RAG

今年“RAG 瓶颈”已经变成一个高频搜索词。瓶颈出在哪里？出在向量检索的碎片化上。一个主题分散在多个文档、多个段落里，检索回来的碎片很难拼出完整逻辑，尤其是“A 和 B 是什么关系”这类关系型问题，传统 RAG 基本处于半放弃状态。

GraphRAG 的做法是把抽取出的实体（公司、人物、产品）和关系（持股、合作、竞争）构建成知识图谱，回答问题时不只做文本检索，还在图结构上做多跳推理。比如问“B 公司为什么在跟 C 公司合作”，它能沿着“B→上游供应商→A→共同投资→C”这条路径给出答案。这类问题是纯向量 RAG 答不出来的。

再进一步是 Ontology RAG。它不是简单地抽实体建图，而是先定义一套本体层（Ontology），明确这个领域有哪些概念、属性和关系规则。比如做金融知识库，Ontology 里规定“公司有 CEO”、“财报包含营收、净利润”，系统解析问题时严格按这套框架去组织答案。它的优势是精度高、可控性强，适合业务边界清晰的企业，代价是需要领域专家参与建模，前期成本偏高，不太适合随手搭一个 Demo。

下面是不同 RAG 方案的选型参考：

4.3 第三层进补：多模态与工程化

热词里有人问“RAG 知识库能存图片吗”。答案是可以，但记住一点：图片类知识库十有八九是先给图片写一段准确的描述文字，再对描述做向量化。这样用户搜“红色法拉利”时能命中一张跑车照片。基座模型支持多模态 embedding 时，也可以直接用图文联合向量，但通常描述方案更稳、成本更低。截图、合同扫描件、产品照片这类素材，入库时多一步“视觉语言模型生成说明”的预处理，效果远比裸存图片好。

Mac 上搭 RAG 知识库的流程我也简单说下：本地跑一个 Ollama 拿到 LLM（比如 qwen2.5 系列或 llama 3.1 8B），embedding 模型用 bge-m3 或 nomic-embed-text，向量库用 Chroma 或 FAISS，框架选 LangChain 或 LlamaIndex。配置齐了之后，几行 Python 就能跑通“文档导入→分块→向量化→建索引→检索问答”的完整链路。Apple Silicon 上跑 7B~8B 模型体验已经很流畅，日常练习完全够用。

5. 工程实战：一套判断标准与避坑清单

5.1 场景选型判断矩阵

每次有人问我“我这个项目到底该用 RAG 还是长上下文”，我都建议按下面这套标准逐条打分：

绝大多数现实项目，打分结果都是“RAG 为主，长上下文为辅”。例如还会有一个不错的混合实践：先用 RAG 从百万级知识库里召回到几十个候选片段，再利用长上下文模型把所有片段整体读一遍做总结——这个组合能同时拿到召回的广度和推理的深度，我在实际项目里就是这么用的。

5.2 常见问题速查表

5.3 避坑经验三则

第一，分块策略永远值得投入时间。我见过太多人默认“每 512 token 切一块”然后就不管了。真实的文档有标题、章节、表格、代码块，应该优先按语义结构切——Markdown 标题层级、文档内嵌标题等都能作为天然边界。合适的分块策略能让检索准确率显著提升，这几乎是投入产出比最高的调优项。

第二，评估不可能靠肉眼。手工看几十条问答，会觉得“还行”，但这是严重幻觉。我现在的做法是搭一套评测集——至少一百条覆盖不同难度的问答，配上标准答案，跑批量对比，算召回率和答案正确率。要判断检索段是否有效，简单做法是：模型作答时强制它引用原文片段，然后人工检查引用是否命中核心信息。没有评测集的 RAG 调优，基本等于闭着眼睛走路。

第三，RAG 流程没有银弹，调试时先分段定位。问题到底是“没检索到”还是“检索到了但模型没用上”？在系统的中间日志里把检索结果打印出来，肉眼扫一眼就知道方向。检索差就去优化分块和检索方式，生成差就去调 Prompt 和生成参数。我踩过不少弯路，后来养成“先看检索命中率再看最终答案”的习惯，调试效率高很多。

6. 再聊两句实在的

做技术选型最容易犯的毛病，是把新概念当万能药。看到长上下文参数涨了，就觉得 RAG 过时了；看到 GraphRAG 火了，又觉得向量检索该扔了。我自己的体会是：工程上的正解通常是组合拳。长上下文是和“全面阅读”匹配的能力，RAG 是和“海量知识里的精准定位”匹配的能力。真实业务里，知识规模、更新频率、合规要求、成本预算这些约束条件放在一起，反而会把大多数场景推向“RAG 为主、长上下文为辅”的组合架构——先靠检索从海量库里捞精华，再靠长窗口把精华读透。

最后分享一个可以立刻用上的小技巧：如果你已经搭了 RAG，别急着上复杂方案。先在现有流程里加一个“重排”，把 Top 20 候选用 Reranker 压到 Top 3 喂给模型。很多“RAG 效果差”的问题，这一步就解决了七八成。别怕试错，把这些方法都放到评测集上跑一轮，你会非常直观地看到差距在哪里。这套方法，才是比“RAG 跟长上下文谁淘汰谁”更值得关注的命题。