企业官网建设流程全解析

1. 从“模型接进来”到“知识用起来”：AI网关在RAG里的真实定位

RAG这个词这两年已经被讲烂了，但真正在企业里落过地的人都知道，最难的从来不是把大模型API调通，而是让检索出来的知识“干净、稳定、可追溯”地喂给模型。我前后参与过三个不同规模的RAG项目，从最初用LangChain拼一个Demo，到后来在金融、制造两个行业做私有化部署，踩过的坑基本都集中在同一个地方：检索链路和模型调用链路是割裂的。Embedding服务一个地址、Re-rank服务一个地址、LLM推理又是另一个地址，中间还要处理鉴权、限流、格式转换、失败重试，代码里到处是胶水逻辑。

AI网关（这里我按MAI Gateway这类企业级网关的通用能力来讲）解决的正是这个问题。它把RAG链路里所有模型相关的调用——Embedding、Re-rank、LLM生成——统一收敛到一个入口，对外只暴露一套协议，对内做路由、鉴权、缓存、可观测。说白了，网关不是RAG的算法组件，而是RAG的“神经系统”。算法决定检索准不准，网关决定这套系统能不能稳定跑在生产环境里、能不能被运维、能不能被审计。

这篇文章适合三类人看：一是正在做RAG项目、被多模型调用搞得焦头烂额的工程师；二是负责AI平台建设、需要统一纳管模型服务的技术负责人；三是对RAG感兴趣、想知道“Demo到生产”中间差了什么的学生或转行者。我会把网关在RAG里的每个关键环节拆开讲，包括为什么这么设计、参数怎么算、坑在哪里，尽量给到可以直接抄作业的方案。

2. RAG链路的真实痛点：为什么裸调模型迟早要出事

2.1 多模型服务带来的“胶水代码地狱”

一个标准的RAG流程，用户问一句话，背后至少发生四次模型调用：Query改写（可选）、Embedding向量化、向量检索后的Re-rank精排、最后LLM生成答案。如果做的是Agentic RAG，还要加上意图识别、工具调用、多轮反思，调用次数翻倍都不止。

我最早的做法是在业务代码里直接写HTTP请求，每个模型一个Client类。结果就是：Embedding服务换了供应商，要改三个文件；Re-rank超时要加重试，得在每个调用点复制一遍重试逻辑；某天老板问“昨天RAG的平均首字延迟是多少”，我发现日志散在四个服务里，根本拼不出完整链路。这就是典型的胶水代码地狱——业务逻辑没多少，全在伺候模型调用。

AI网关的第一个价值就在这里：把N个模型服务收敛成1个入口。业务代码只认网关地址，网关背后挂几个模型、怎么路由、怎么降级，业务侧完全无感。换模型供应商？改网关配置，业务代码一行不动。

2.2 检索质量和调用稳定性是两回事

很多人把RAG效果差归咎于“检索不准”，但实际排查下来，相当一部分问题是调用层面的。我遇到过几个典型场景：

• Embedding服务偶发超时，返回空向量，检索直接返回无关结果，但日志里只看到“检索成功”；
• Re-rank模型对长文本截断处理不当，把关键段落截掉了，排序自然乱；
• LLM生成时上下文超长，被静默截断，答案缺了后半段依据。

这些问题算法层面看不出来，全是工程层面的。网关能做的是：统一超时、统一重试、统一截断策略、统一记录每次调用的输入输出。当检索效果波动时，你能快速定位到底是“检索本身不准”还是“调用过程出了问题”。这个区分能力，在真实排障里价值极高。

2.3 成本、限流、审计：生产环境的硬约束

Demo阶段没人关心成本，生产阶段每一分钱都要算。Embedding按Token计费、Re-rank按调用次数计费、LLM按输入输出Token计费，三个计费维度混在一起，财务根本对不上账。再加上多租户场景下，A部门把额度用光了，B部门跟着遭殃，没有网关做配额隔离，这事没法管。

还有审计。金融和医疗行业要求所有AI输出可追溯：这句话是基于哪段知识生成的、调用了哪个模型、什么时间、谁发起的。这些信息如果靠业务代码自己埋点，工作量巨大且容易漏。网关作为统一入口，天然就是审计的最佳埋点位置。

3. MAI Gateway在RAG中的核心能力拆解

3.1 统一协议层：让Embedding、Re-rank、LLM说同一种话

不同模型服务的接口协议五花八门。OpenAI风格的/v1/embeddings、某些国产模型的私有协议、本地Ollama的/api/embeddings，字段名、返回结构都不一样。网关的第一件事就是做协议归一化。

我的做法是在网关里定义一套内部标准协议，比如Embedding统一用{input: string[], model: string}请求，返回{embeddings: number[][], usage: {...}}。然后为每个后端模型写一个Adapter，负责把标准协议翻译成后端能懂的格式。这样业务侧永远只面对一套协议，新增模型只需要加一个Adapter。

这里有个实操细节：向量维度必须在网关层做校验。不同Embedding模型维度不同（768、1024、1536、2048都有），如果业务侧存向量库时维度对不上，写入会直接失败。网关在返回前校验维度，维度不符直接报错，比等到向量库写入失败再排查要快得多。

3.2 智能路由与降级：主备模型的无感切换

生产环境不能假设某个模型永远可用。我一般会配置主备两条链路：主用某商用Embedding，备用本地部署的BGE模型。网关根据健康检查结果自动切换，业务侧无感。

路由策略我总结了几种常用模式，用表格对比一下：

降级要特别注意语义一致性。主备模型如果Embedding空间不兼容，切换后检索结果会突变。我的经验是：备用模型要么用同系列（比如都是BGE家族），要么在切换时触发一次全量重建索引。这个坑我踩过一次，切换后检索命中率掉了30%，排查半天才发现是向量空间不兼容。

3.3 缓存层：RAG里最容易被忽视的降本利器

RAG场景有个特点：高频Query重复率很高。企业内部知识库，员工问来问去就那些问题。Embedding和Re-rank的结果对相同输入是确定的，完全可以缓存。

网关层做缓存有几个讲究：

• Embedding缓存：key用model + hash(input)，命中率通常能到40%以上。注意要设TTL，模型更新后旧缓存要失效。
• Re-rank缓存：key用model + hash(query) + hash(doc_ids)，因为同一批文档排序结果稳定。
• LLM生成缓存：这个要谨慎，因为生成有随机性。我的做法是只对temperature=0且Query完全一致的请求缓存，且TTL设短（比如5分钟）。

实测下来，加上Embedding和Re-rank缓存后，整体模型调用成本能降35%左右，P99延迟降了将近一半。这个投入产出比非常高，建议优先做。

3.4 可观测性：把RAG的“黑盒”打开

RAG最难排障的地方在于链路长。用户说“答案不对”，你要判断是Query理解错了、检索没召回、Re-rank排错了、还是LLM没用好上下文。网关的可观测性就是把这四段拆开看。

我一般要求网关记录这几个关键指标：

• 每段耗时：Embedding耗时、检索耗时、Re-rank耗时、生成耗时，分开统计；
• 召回质量：Top-K召回的相似度分布，如果最高相似度都很低，说明知识库没覆盖；
• Token消耗：输入Token、输出Token、缓存命中Token，分租户统计；
• 失败率：按模型、按错误类型分类。

有了这些数据，排障就从“猜”变成了“看”。我遇到过一个问题：某类问题答案总是缺一半。看网关日志发现，Re-rank后的上下文长度超过了LLM的窗口，被截断了。如果没有分段耗时和Token统计，这个问题能查一整天。

4. 落地实操：从零搭一套带网关的RAG链路

4.1 环境准备与组件选型

先说选型思路。网关我建议用支持插件化扩展的（MAI Gateway这类企业网关通常支持自定义插件），因为RAG场景经常要加自定义逻辑，比如Query改写、敏感词过滤。向量库看数据规模：百万级以下用Milvus或Qdrant都行，千万级以上考虑分布式方案。Embedding模型，中文场景我实测BGE系列和某商用模型效果都不错，具体选哪个要看你的领域数据。

环境准备清单：

• 网关服务：部署在内网，配置好模型后端地址
• 向量库：Milvus 2.3+ 或 Qdrant 1.7+
• Embedding服务：本地部署或商用API
• Re-rank服务：BGE-Reranker或商用
• LLM服务：按需选择

提示：网关和向量库建议部署在同一内网，跨机房调用会显著增加延迟。我见过把向量库放公网、网关放内网的架构，检索延迟直接翻倍。

4.2 网关配置：Embedding与Re-rank的接入

以标准配置为例，网关里需要为每个模型后端定义Adapter。核心配置项包括：后端地址、鉴权方式、超时时间、重试策略、限流阈值。

超时时间的设置有讲究。Embedding通常快（100ms内），超时设3s足够；Re-rank稍慢（200-500ms），设5s；LLM生成最慢，设30-60s。重试策略上，Embedding和Re-rank可以重试2次，LLM生成不建议自动重试（可能产生重复计费和副作用）。

限流阈值要结合后端承载能力。我的经验公式是：限流QPS = 后端实测最大QPS × 0.7，留30%余量应对突发。这个系数是踩过坑的——曾经按最大QPS配，结果高峰期后端直接被打挂。

4.3 检索链路的编排：网关如何串起整条流水线

网关不只是转发，还可以做链路编排。用户一个Query进来，网关按顺序调用：Query改写（可选）→ Embedding → 向量检索 → Re-rank → 组装上下文 → LLM生成。每一步的输出作为下一步的输入，中间任何一步失败都有明确的降级策略。

这里的关键是上下文组装策略。Re-rank返回Top-N文档后，怎么拼成LLM的输入？我的做法是：按相似度排序，从高到低累加Token，直到接近LLM窗口的80%就停。留20%给系统提示词和输出。这个80%是经验值，实测能兼顾信息量和安全性。

4.4 参数计算：Top-K、相似度阈值、上下文长度怎么定

这几个参数没有标准答案，但有计算方法。

Top-K的确定：先做召回率测试。取一批标注好的问答对，看Top-K从1加到20时，召回率什么时候趋于平缓。通常K=5到10是拐点。K太大反而引入噪声，Re-rank压力也大。

相似度阈值：统计正样本和负样本的相似度分布，取两者交界处作为阈值。如果分布重叠严重，说明Embedding模型不适合你的领域，该换模型了。

上下文长度：可用上下文 = LLM窗口 × 0.8 - 系统提示词Token - 预期输出Token。比如窗口8K，系统提示词500 Token，预期输出1K，那可用上下文约4.9K Token。按每段文档平均300 Token算，大概能放16段。

这些参数建议做成网关可配置项，不同业务线用不同配置，别写死在代码里。

5. 排障实录：RAG上线后最常遇到的六个问题

5.1 检索命中率突然下降

这是最高频的问题。排查顺序我总结成一张表：

我遇到过一次，命中率从85%掉到60%，最后发现是Embedding服务被运维重启，加载了旧版本模型，向量空间变了。网关如果记录了模型版本号，这个问题5分钟就能定位。

5.2 Re-rank后结果反而变差

Re-rank不是万能的。如果Re-rank模型和Embedding模型训练数据分布差异大，精排结果可能不如粗排。我的做法是：Re-rank前后都记录排序，做对比。如果Re-rank后Top-1的相似度反而降低，说明Re-rank模型不适配，该换或该关。

还有一种情况是Re-rank输入太长被截断。Re-rank模型通常有最大长度限制（512或1024 Token），超长文档会被截断，关键信息可能正好在被截断的部分。解决办法是在网关层做文档分块，每块单独Re-rank再合并。

5.3 LLM“答非所问”但检索结果是对的

这种情况通常是上下文组装出了问题。检查三点：一是文档顺序，最相关的应该放最前面（LLM对开头和结尾的内容注意力更高）；二是文档间是否有矛盾信息，LLM可能被误导；三是系统提示词是否明确要求“只基于给定上下文回答”。

我一般会在系统提示词里加一句：“如果给定上下文无法回答问题，请明确说明不知道，不要编造。”这一句话能显著降低幻觉率。

5.4 网关成为性能瓶颈

网关做链路编排后，本身可能成为瓶颈。排查方法是看网关的CPU和内存，以及每段调用的排队时间。如果网关CPU打满，考虑横向扩容或把部分逻辑（如缓存）下沉。

我的经验是：网关做转发和轻量编排没问题，但别在网关里做重计算（比如本地跑Embedding模型）。网关应该是“调度中心”，不是“计算中心”。

5.5 多租户配额串了

多租户场景下，配额计算要精确到每次调用。网关需要从请求头或Token里解析租户ID，然后按租户累加Token消耗。这里有个坑：流式返回的Token统计。LLM流式输出时，Token是逐步返回的，网关要边转发边累加，不能等流结束再算，否则中途断流就漏统计了。

5.6 缓存导致答案“过期”

缓存是把双刃剑。知识库更新后，旧缓存还在，用户拿到的还是旧答案。解决办法是：缓存key里带上知识库版本号，知识库更新时版本号+1，旧缓存自然失效。这个设计比手动清缓存可靠得多。

6. 几个我认为值得分享的实操心得

第一个心得关于灰度发布。RAG链路任何一环变更（换Embedding模型、调Re-rank参数、改提示词），都不要全量上线。网关支持按租户或按流量比例灰度，先放5%流量观察一周，指标稳定再扩。我见过直接全量换模型导致线上事故的，回滚都来不及。

第二个心得关于日志采样。全量记录每次调用的输入输出，存储成本很高。我的做法是：正常请求采样1%，异常请求100%记录。这样既控制了成本，又保证了排障时有据可查。

第三个心得关于向量库的索引重建。换Embedding模型必须重建索引，这个操作很重。建议在网关层做双写：新模型上线后，新数据用新模型写入新索引，旧数据后台慢慢迁移，迁移完成后切换读路径。这样业务无感知。

第四个心得关于提示词版本管理。提示词也是代码，要版本化。网关可以把提示词模板也纳入管理，每次调用记录用了哪个版本，出问题时能快速回滚。

最后说一个我踩过的最大的坑：别在网关里做业务逻辑。网关应该保持“薄”，只做协议转换、路由、缓存、可观测这些通用能力。业务逻辑（比如特定行业的Query改写规则）应该放在业务侧或独立的服务里。我早期把一堆业务规则塞进网关插件，结果网关越来越重，改一个规则要重新部署整个网关，牵一发动全身。后来把这些逻辑抽出去，网关回归“神经系统”的本职，整个系统清爽多了。

这套架构我在两个行业落地过，从最初的单模型裸调，到现在的网关统一纳管，最大的感受是：RAG的效果上限由算法决定，但稳定性下限由工程决定。网关就是那个把下限抬起来的东西。算法可以慢慢调，但工程底座一开始就要搭对，否则后面每加一个功能都是在还技术债。