企业官网建设流程全解析

1. 企业级 LLM 落地的真实分水岭

聊到企业级 LLM，很多人第一反应是模型选型——用哪个开源模型、参数量多大、跑在什么卡上。但我做了几个企业项目之后发现，真正决定项目成败的，往往不是模型本身，而是模型外面那一圈东西：网关怎么设计、知识库怎么组织、检索链路怎么搭、权限和审计怎么做。模型是发动机，但企业要的是一辆能上路、能年检、能拉货的车。

这篇是"企业级 LLM"系列的第二篇，第一篇我们聊了整体架构和选型思路，这一篇往深里走，专门讲落地过程中最容易翻车的几个环节：LLM 网关的设计、RAG 与知识库的工程化、本体（Ontology）在检索里的作用、以及本地化部署时那些文档里不会写的坑。适合正在做或准备做企业级 LLM 应用的工程师、架构师，也适合想搞清楚"企业级"三个字到底重在哪里的技术管理者。

先说一个我踩过的坑。早期做内部知识问答，我直接把模型 API 暴露给业务系统调用，结果三个月后出了三件事：一是某个业务线疯狂重试导致账单暴涨，二是有人把敏感字段拼进了 prompt 发出去，三是模型供应商接口改了个字段名，三个下游系统全挂了。这三件事逼着我回头补网关这一层。所以下面先从网关讲起，它是企业级和玩具级最直观的分界线。

2. LLM 网关：企业级架构的第一道闸门

2.1 为什么不能直连模型 API

直连模型 API 在 demo 阶段没问题，但一进生产就是灾难。核心原因有三个：流量不可控、成本不可见、故障不可隔离。企业里调用 LLM 的来源五花八门——有前端聊天、有后台批处理、有定时任务、有第三方系统回调，如果每个都直连，你根本不知道钱花在哪、谁在滥用、出问题找谁。

网关的本质是一个统一入口 + 策略中心。所有请求先到网关，网关负责鉴权、限流、路由、缓存、日志、脱敏，然后再转发给后端模型。这样做的好处是，业务系统只需要对接一个稳定的内部接口，模型换供应商、换版本、加新模型，业务侧无感知。

我一般把网关的职责拆成这么几层，从外到内：

• 接入层：协议适配（HTTP、gRPC、WebSocket）、鉴权（API Key、JWT、内部 SSO）
• 策略层：限流、配额、熔断、重试、超时
• 路由层：按模型名、按租户、按成本、按可用性做路由和降级
• 增强层：prompt 模板注入、敏感词过滤、PII 脱敏、缓存命中
• 观测层：全链路日志、token 计量、成本归集、调用追踪

这五层不是每个项目都要全上，但鉴权、限流、日志、计量这四样，我认为是企业级的底线，缺一个都不好意思叫企业级。

2.2 网关的核心能力拆解

鉴权与租户隔离。企业里不同部门、不同应用要有独立的身份和配额。我通常用 API Key + 租户 ID 的组合，Key 绑定租户，租户绑定配额和模型白名单。这样财务来对账的时候，能直接按租户出账单。这里有个细节：Key 不要明文存库，存哈希，校验时比对哈希，跟存密码一个道理。

限流与配额。限流分两个维度：QPS 限流防突发，token 配额防月度超支。QPS 用令牌桶就够了，token 配额要按天或按月累计，超了直接拒绝或者降级到便宜模型。我见过一个团队没做 token 配额，某个月账单是预算的 8 倍，原因是一个测试脚本忘了关，循环调了一周。

路由与降级。企业往往同时接多个模型——贵的用于复杂推理，便宜的用于简单分类，本地的用于敏感数据。网关根据请求里的model字段或者业务标签路由。降级策略要提前设计：主模型超时或报错时，是重试、切备用模型、还是直接返回兜底话术？我的经验是，读类请求可以降级到小模型，写类或决策类请求宁可失败也不要降级，因为降级产生的错误结果比报错更危险。

缓存。LLM 调用又慢又贵，缓存能省一大笔。但缓存有个坑：同样的 prompt 在不同租户、不同上下文下答案可能不同，所以缓存 key 必须包含租户 ID、模型版本、关键参数（temperature 等）。语义缓存（用向量相似度判断问题是否等价）能进一步提高命中率，但阈值要调，太松会返回不相关答案，太紧等于没缓存。

可观测性。每次调用要记录：租户、模型、输入 token 数、输出 token 数、耗时、是否命中缓存、是否降级、错误码。这些数据是后续优化的基础。没有这些数据，你连"该不该换模型"都判断不了。

2.3 一个可落地的网关配置示例

下面是一个简化的网关路由配置，用 YAML 表达，实际项目里可以放在配置中心动态下发：

gateway: tenants: - id: dept_finance api_key_hash: "sha256:xxxx" quota: daily_tokens: 2000000 qps: 20 allowed_models: [gpt-4-class, gpt-3.5-class, local-7b] routes: - match: { model: "gpt-4-class" } primary: { provider: "cloud_a", model: "large-v2", timeout: 30s } fallback: { provider: "cloud_b", model: "large-v1", timeout: 30s } retry: { max: 2, backoff: "exponential" } - match: { model: "local-7b" } primary: { provider: "local_cluster", endpoint: "http://llm-svc:8000", timeout: 60s } cache: enabled: true ttl: 3600 key_fields: [tenant_id, model, prompt_hash, temperature] guardrails: pii_redaction: true blocked_patterns: ["身份证", "银行卡"]

这份配置里，fallback和retry是分开的：retry 是同一个 provider 重试，fallback 是换 provider。很多人把这两个混在一起，结果主 provider 挂了还在原地重试，白白浪费时间。另外guardrails里的 PII 脱敏，是在请求出网关之前做的，确保敏感信息不会流到外部模型。

提示：网关的配置一定要支持热更新。我见过改个限流阈值要重启网关的团队，每次调整都提心吊胆。配置中心 + 监听刷新是标配。

3. RAG 与知识库：企业 LLM 的"外挂大脑"

3.1 RAG 到底解决了什么问题

模型本身的知识是训练时冻结的，企业内部的文档、流程、产品信息它一概不知。RAG（检索增强生成）的思路很朴素：先去知识库里找相关资料，把资料塞进 prompt，再让模型基于资料回答。这样既不用重新训练模型，又能让答案有据可查。

但 RAG 不是"把文档切一切、向量化、检索、拼 prompt"这么简单。我做过一个产品检索的项目，第一版 RAG 上线后，用户反馈"答非所问"的比例高达 40%。排查下来，问题出在切分和检索上：文档按固定 500 字切，把一张参数表从中间切断了；检索只用了向量相似度，用户问"支持多少并发"，检索到的却是"并发"这个词出现的营销文案。

所以 RAG 的质量，七分在检索，三分在生成。检索不准，模型再强也白搭。

3.2 知识库工程化的关键环节

文档解析。企业文档格式极其杂乱：PDF、Word、Excel、PPT、扫描件、网页、数据库。解析质量直接决定后续效果。PDF 里的表格是重灾区，普通解析器会把表格拍平成一行文字，丢失结构。我的做法是，表格类文档单独走结构化解析，转成 Markdown 表格或 JSON，保留行列关系。扫描件先 OCR，OCR 之后还要做纠错，因为识别错误会污染向量。

切分策略。固定长度切分是最省事但最差的做法。我一般用语义切分 + 重叠窗口：按段落、标题、列表项这些自然边界切，块与块之间保留 10%~20% 的重叠，避免答案正好卡在边界上被切断。块大小也不是越小越好，太小丢上下文，太大检索精度下降。实测下来，中文文档 300~500 字一块比较均衡，技术文档可以到 800 字。

元数据。每个块都要带元数据：来源文档、章节、页码、更新时间、权限标签。元数据在检索时能做过滤，比如只检索用户有权限看的文档，或者只检索最近一年的版本。没有元数据的知识库，在企业里基本没法用，因为权限和时效性没法保证。

向量化与索引。embedding 模型的选择要看语言和领域。通用中文场景，主流的中文 embedding 模型都够用；专业领域（医疗、法律、金融）最好用领域数据微调过的，或者至少测一下检索命中率。索引方面，数据量小用 FAISS 就够，上了百万级考虑 Milvus、Qdrant 这类专业向量库。

3.3 从朴素 RAG 到 GraphRAG 与本体增强

朴素 RAG 有个硬伤：它只能检索"相似"的内容，处理不了需要多跳推理的问题。比如问"我们产品 A 的某个功能，和竞品 B 的对应功能比，谁的性能更好"，这需要先找到 A 的功能参数，再找到 B 的参数，再对比。向量检索很难一次把这两块都捞出来。

这就引出了GraphRAG和本体（Ontology）的思路。GraphRAG 在向量检索之外，额外构建一个知识图谱，把实体和关系显式建模。检索时既走向量，也走图，把相关的实体和关系一起捞出来。本体则是更上层的东西——它定义了领域里有哪些概念、概念之间是什么关系、有哪些约束。有了本体，检索和生成都有了"骨架"，模型不容易胡说。

我做过一个中药处方审核的场景，本体在这里价值极大。中药里有"十八反十九畏"这种配伍禁忌，本质上是药物之间的约束关系。如果只靠向量检索，模型可能检索到两味药各自的说明，但不知道它们不能同用。把禁忌关系建成本体里的边，检索时直接查图，就能可靠地拦住。这个例子说明，在强规则、强关系的领域，本体 + 图检索比纯向量检索可靠得多。

不过 GraphRAG 和本体不是银弹。构建知识图谱和本体需要大量人工或半自动的标注，成本高、周期长。我的建议是：先用朴素 RAG 跑起来，把检索质量、切分、元数据这些基础打牢，等遇到明确的多跳推理瓶颈，再上 GraphRAG。一上来就搞本体，大概率是过度设计。

3.4 一个 RAG 检索链路的实操配置

下面是一个检索链路的伪代码，展示混合检索 + 重排的思路：

def retrieve(query, tenant_id, top_k=5): # 1. 查询改写：把口语化问题改写成检索友好的形式 rewritten = rewrite_query(query) # 2. 向量检索 vec_hits = vector_store.search( embedding(rewritten), filter={"tenant_id": tenant_id, "status": "active"}, top_k=20 ) # 3. 关键词检索（BM25），补向量检索的短板 kw_hits = bm25_index.search(rewritten, top_k=20) # 4. 融合去重 merged = reciprocal_rank_fusion(vec_hits, kw_hits) # 5. 重排：用 cross-encoder 精排 reranked = reranker.rerank(query, merged, top_k=top_k) return reranked

这里有几个关键点。查询改写很重要，用户问"这个咋弄"，直接检索效果很差，改写成"XX 功能的操作步骤"命中率会高很多。混合检索（向量 + 关键词）能互补：向量擅长语义，关键词擅长精确匹配（比如产品型号、专有名词）。重排是最后一道精度保障，cross-encoder 比向量相似度准得多，但慢，所以只对前 20 个候选做。

注意：重排模型很吃资源，如果 QPS 高，要么上 GPU，要么限制重排的候选数量。我一般控制在 20~50 个候选，再多收益递减。

4. 本地化部署与模型工程的那些坑

4.1 什么情况下必须本地部署

不是所有企业都需要本地部署。如果数据不敏感、预算充足、追求效果，直接用云上 API 最省事。但以下情况基本只能本地化：数据合规要求不能出内网、调用量大到 API 成本不可接受、需要深度定制模型、网络环境受限。

本地部署的核心矛盾是：效果、成本、速度三者不可兼得。7B 模型跑在单张消费级卡上，速度和成本都好，但效果一般；70B 模型效果好，但要多卡，成本和运维复杂度陡增。我的经验是，先明确业务对效果的底线，再倒推模型规模，而不是反过来。

4.2 推理框架与量化选型

本地部署绕不开推理框架。主流的有 vLLM、TensorRT-LLM、llama.cpp 这几类。选型看场景：

量化是降本的关键手段。FP16 是基准，INT8 能省一半显存，INT4 再省一半但精度损失明显。我的经验是，7B 模型用 INT4 还能接受，13B 以上建议至少 INT8，否则复杂推理任务会明显变笨。量化不是免费的午餐，一定要用业务测试集验证效果，别只看 benchmark。

4.3 ONNX 部署 LLM 的实践要点

有些团队出于跨平台或已有 ONNX 工具链的考虑，会走 ONNX 路线部署 LLM。这条路可行，但坑不少。ONNX 导出 LLM 时，动态 shape、KV Cache、注意力算子这些容易出问题。我的建议是：

• 优先用官方或社区验证过的导出脚本，别自己手写
• 导出后一定要做数值对齐测试，逐层比对输出，误差超过阈值就说明导出有问题
• KV Cache 的处理是重点，处理不好会导致长文本生成时显存暴涨或结果错乱
• ONNX Runtime 的版本和 CUDA/cuDNN 版本要严格匹配，版本错配是最高频的报错来源

我踩过最深的坑是 ONNX Runtime 升级后，某个注意力算子行为变了，导致生成结果出现重复。排查了两天才定位到是版本问题。所以生产环境锁定版本，升级前必须回归测试。

4.4 本地 ERP + RAG + LLM 的产品检索实例

热词里提到"本地 ERP + RAG + LLM 产品检索"，这个场景我做过类似的，值得展开说说。企业 ERP 里有海量产品数据——SKU、规格、库存、价格、供应商。业务人员想查"哪些产品满足某组条件"，传统做法是写 SQL 或者用 ERP 的筛选界面，门槛高、不灵活。

用 LLM + RAG 改造后，用户可以用自然语言问："帮我找一下功率大于 500W、防护等级 IP65 以上、有现货的电机"。系统的工作流是：

1. LLM 把自然语言解析成结构化查询条件（意图识别 + 槽位填充）
2. 结构化条件走 ERP 数据库精确查询
3. 非结构化描述（产品手册、备注）走向量检索
4. 两路结果合并，LLM 生成自然语言回答

这里的关键设计是不要让 LLM 直接查数据库，而是让它生成查询条件，由后端执行。原因有二：一是安全，防止注入和越权；二是准确，LLM 生成 SQL 的准确率在复杂 schema 下并不高。让 LLM 做它擅长的（理解意图），让数据库做它擅长的（精确查询），各司其职。

提示：ERP 的 schema 往往很复杂，表名和字段名是缩写。给 LLM 的 schema 描述要加业务注释，否则它根本猜不出prod_spec_01是什么。我一般维护一份字段映射表，随 schema 一起喂给模型。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

5.2 几个独家避坑经验

关于工具调用报错。热词里那个"provider rejected the request schema or tool payload"我遇到过好几次。最常见的原因是工具定义的 JSON Schema 里用了模型不支持的字段，或者参数类型对不上（比如该传字符串传了数字）。排查方法很简单：把请求体完整打出来，跟 provider 的文档逐字段比对。另外，不同 provider 对工具调用的支持程度不一样，有的不支持并行工具调用，有的对嵌套结构有限制。跨 provider 的工具定义要取交集，别用某个 provider 独有的特性。

关于 prompt 版本管理。prompt 是代码，必须版本化。我见过 prompt 改了没记录，效果变差了找不到原因的团队。我的做法是 prompt 存文件、进 Git、带版本号，每次调用记录用了哪个版本。这样出问题能快速回滚和对比。

关于评估。企业级 LLM 没有评估体系就是盲人摸象。至少要有一套业务测试集，覆盖典型问题和边界情况，每次改 prompt、换模型、调检索参数都跑一遍。评估指标别只看准确率，还要看拒答率（该拒答的有没有拒答）和幻觉率（编造信息的比例）。我一般用人工标注 + LLM 辅助评估结合，纯自动评估容易漏掉细微错误。

关于灰度。任何改动——换模型、改 prompt、调检索——都要灰度。先放 5% 流量，观察指标，没问题再逐步放量。直接全量上线，出问题就是事故。

5.3 性能与成本的平衡技巧

企业级 LLM 最终要算经济账。几个实用的降本手段：

• 分级路由：简单问题走小模型，复杂问题走大模型。用一个小分类器或者规则先判断难度。
• 缓存：高频重复问题直接命中缓存，省下的 token 很可观。
• prompt 精简：prompt 里的冗余内容都是钱。定期审查 prompt，删掉没用的示例和说明。
• 输出长度控制：很多场景不需要长篇大论，限制 max_tokens 能省不少。
• 批处理：非实时任务攒批处理，提高 GPU 利用率。

我做过一个统计，一个中等规模的企业问答系统，上了分级路由 + 缓存之后，成本降了大概 60%，而用户满意度基本没变。这说明大部分降本手段对体验的影响，远小于你的想象。

6. 我在这几个项目里最深的几点体会

做企业级 LLM 这两年，最大的感受是：技术选型的重要性，远低于工程细节的扎实程度。模型大家用的都差不多，真正拉开差距的是网关稳不稳、检索准不准、评估全不全、灰度严不严。这些活儿不性感，但决定了项目能不能活到上线之后。

第二个体会是，别迷信新概念。GraphRAG、本体、Agent 这些词很热，但不是每个场景都需要。我见过为了用 GraphRAG 而硬造知识图谱的项目，最后维护成本高到放弃。先用最简单的方法解决问题，遇到瓶颈再升级，这个顺序不能反。

第三个体会是，评估和观测要前置。很多团队先把功能做出来，最后才想怎么评估，结果发现没有数据、没有基线，根本不知道做得好不好。我的做法是，项目一开始就搭好日志和评估框架，哪怕功能还没做完，数据先攒起来。

最后分享一个我常用的小技巧：给每个 LLM 应用建一个"失败案例库"。每次线上出问题、每次用户反馈答得不好，都把 case 记下来，定期复盘。这个库比任何 benchmark 都真实，是迭代 prompt 和检索策略最宝贵的素材。我维护的那个库攒了三百多条 case，每次改东西都拿出来跑一遍，能挡住大部分回归问题。