1. 企业级 LLM 落地先想清楚“企业级”三个字到底意味着什么这两年跟不少团队聊过大模型落地的事一个很明显的感受是个人玩 LLM 和企业上 LLM完全是两码事。个人场景里你调个 API、写个提示词、跑通一个 demo就算成功了但企业场景里这套东西能不能上线、能不能扛住并发、能不能过安全审计、出了问题能不能定位才是真正的门槛。所以“企业级 LLM”这个系列我想先把最容易被忽略的地基讲清楚再往下拆架构、拆选型、拆实操。先给结论企业级 LLM 不是“把开源模型部署到服务器上”这么简单它是一整套围绕模型构建的工程体系涵盖模型接入层、网关层、知识层、编排层、可观测层、安全合规层。你可以把它理解成盖楼——模型是钢筋水泥但只有钢筋水泥盖不成写字楼你还得有水电、消防、电梯、物业。很多团队一上来就纠结“用哪个模型”其实这个问题在企业级场景里排不进前三真正卡脖子的是网关怎么做、知识库怎么管、权限怎么控、成本怎么算。这篇文章适合三类人看一是正在做 LLM 技术选型的架构师二是准备把 demo 推向生产的开发负责人三是想搞清楚企业级 LLM 全貌的技术管理者。我会尽量用从业者的视角把每个环节“为什么这么设计”讲透而不是甩一堆名词。文中涉及的具体参数和配置一部分来自我自己的实践一部分是基于行业常见方案的合理推演你落地时还是要结合自己的业务量级做压测和调整。2. 企业级 LLM 的整体架构设计与选型逻辑2.1 为什么不能“一个 API 调到底”个人开发者最常见的做法是业务代码里直接import openai然后到处调。这个做法在 demo 阶段没问题但到了企业级就会暴露一堆问题。我列几个真实踩过的坑第一模型供应商一换业务代码要全改因为各家 SDK 的入参格式、返回结构、错误码都不一样第二没有统一的限流和重试某个业务线疯狂调用把配额打满其他业务线全部挂掉第三密钥散落在各个服务里安全审计根本过不了第四出了 badcase 想追溯“当时到底发了什么 prompt、模型返回了什么”日志里啥都没有。所以企业级的第一条设计原则就是在业务和模型之间加一层网关。这层网关不是简单的反向代理它要承担协议适配、鉴权、限流、路由、缓存、日志、计费这几件事。你可以用现成的开源方案也可以自研但这一层绝对不能省。2.2 分层架构把职责切干净我习惯把企业级 LLM 系统切成五层从下往上说模型层包括商用 API各家的大模型服务和自部署模型比如用 vLLM、TGI 部署的开源模型。这一层的关键是“抽象”对上暴露统一的调用接口。网关层统一入口负责鉴权、限流、路由、协议转换、日志埋点、成本统计。这一层是整个系统的“咽喉”设计好坏直接决定后续扩展性。知识与检索层RAG 的核心。包括文档解析、切分、向量化、向量库、检索重排。企业级场景里这一层往往比模型本身更重要因为通用模型不知道你公司的业务。编排层负责把多个能力串起来比如“先检索知识库再调用模型再调用工具查数据库最后汇总”。Agent、工作流引擎都属于这一层。应用层面向具体业务比如智能客服、合同审核、代码助手、数据分析。这么分层的好处是每一层可以独立演进。比如你想把模型从 A 换成 B只改模型层想换向量库只改知识层业务代码基本不动。这就是企业级和 demo 的本质区别——可替换性。2.3 选型时最容易踩的三个坑第一个坑是“唯模型论”。很多团队花大量时间对比模型跑分却忽略了工程配套。实际上一个中等能力的模型配上好的 RAG 和好的提示词工程效果往往超过一个强模型裸调。模型选型要看的是上下文长度、函数调用能力、结构化输出稳定性、并发限制、价格、以及是否支持私有化。第二个坑是“忽略成本模型”。企业级调用量和 demo 不是一个量级。你得算清楚每千 token 的输入输出价格、缓存命中率、平均每次请求消耗多少 token、每天多少请求。我见过一个团队上线后才发现光是系统提示词就占了每次请求 40% 的 token因为提示词写得太啰嗦。优化提示词后成本直接降了三成。第三个坑是“没有降级方案”。商用 API 会限流、会抖动、会涨价。企业级系统必须有降级路径主模型不可用时切备用模型或者切到规则兜底。这个切换逻辑要提前设计好不能等出事再补。3. 网关层企业级 LLM 的“咽喉”怎么建3.1 网关到底要解决哪些问题网关层是企业级 LLM 最容易被低估的一层。我把它要解决的问题列成一张表你可以对照自己的系统看看缺了哪些能力解决的问题不做会怎样统一鉴权密钥集中管理按业务线分配密钥泄露审计不过限流熔断防止单业务打满配额一个业务拖垮全公司多模型路由按成本/能力/可用性选模型换模型要改业务代码协议适配屏蔽各家 API 差异业务代码到处是 if-else请求缓存相同请求直接返回重复烧钱日志追踪记录完整请求链路出问题无法定位成本统计按业务线算账月底不知道钱花哪了内容安全输入输出过滤合规风险这张表里我觉得最容易被忽略的是请求缓存和成本统计。缓存这块很多语义相同的请求其实可以复用结果尤其是知识库问答场景命中率能到 20% 以上。成本统计则是给管理层看的没有这个数据你没法证明 LLM 项目的 ROI。3.2 路由策略怎么决定用哪个模型路由策略是网关的核心逻辑。我一般会设计成多级路由第一级是按业务线路由。不同业务对模型能力要求不同客服场景可能用便宜的小模型就够代码生成场景必须用强模型。这一级在配置里写死简单可靠。第二级是按请求特征路由。比如根据输入长度、是否包含图片、是否需要函数调用动态选模型。长上下文请求路由到支持长上下文的模型简单问答路由到便宜模型。第三级是按可用性路由。主模型超时或报错自动切备用模型。这里要注意切换要有熔断机制不能主模型挂了还一直重试把备用模型也拖垮。路由配置我建议用配置中心管理支持热更新。这样调整策略不用重启服务运维成本低很多。3.3 一个可落地的网关配置示例下面是一个基于常见网关思路的配置示例用 YAML 表达你可以根据自己的技术栈翻译成对应实现gateway: auth: type: api_key key_header: X-LLM-Key key_store: redis rate_limit: default: 100/min per_business: customer_service: 500/min code_assistant: 200/min routes: - name: default_chat match: business: customer_service primary: provider: vendor_a model: small-chat timeout: 10s fallback: provider: vendor_b model: backup-chat timeout: 15s cache: enabled: true ttl: 3600 key_strategy: semantic_hash logging: level: full store: elasticsearch mask_fields: [user_phone, id_card]这个配置里mask_fields是安全合规的关键日志里不能出现敏感信息。key_strategy: semantic_hash表示用语义哈希做缓存键相同意思的问题能命中同一缓存。提示缓存策略要谨慎涉及实时数据的问答不能缓存否则会返回过期答案。建议按业务线配置是否开启缓存。4. 知识与检索层企业级 RAG 的工程细节4.1 为什么企业级 RAG 比想象中难RAG 这个词现在被说烂了但真正在企业里跑通 RAG 的团队不多。难点不在“向量检索”这个技术本身而在数据治理。企业文档格式五花八门PDF、Word、Excel、PPT、扫描件、网页、数据库。每种格式的解析质量直接决定 RAG 效果。我见过太多团队模型选得很好但文档解析一塌糊涂切出来的 chunk 全是乱码检索出来的内容驴唇不对马嘴。所以企业级 RAG 的第一步不是选向量库而是把文档解析和清洗做扎实。扫描件要 OCR表格要结构化多栏 PDF 要正确分栏页眉页脚要去掉。这些脏活累活才是决定 RAG 成败的关键。4.2 切分策略chunk 大小怎么定切分是 RAG 里最考验经验的地方。切太大检索精度下降因为一个 chunk 里混了多个主题切太小上下文不完整模型没法回答。我的经验是通用文档chunk 大小 300-500 token重叠 50-100 token。技术文档/法律合同chunk 可以大一些500-800 token因为条款之间关联性强。问答对/FAQ按问答对切不要硬切。重叠overlap的作用是防止关键信息被切断。比如一句话正好跨在两个 chunk 边界上有重叠就能保证至少一个 chunk 包含完整信息。另外我强烈建议在 chunk 里保留元数据来源文档、章节标题、页码、更新时间。这些元数据在检索时可以用于过滤比如“只检索最近一年的文档”也能在回答时给出引用来源提升可信度。4.3 检索优化从向量检索到混合检索纯向量检索有个问题对精确匹配不敏感。比如用户问“XX 型号的参数”向量检索可能召回一堆语义相近但型号不对的内容。所以企业级 RAG 一般用混合检索向量检索 关键词检索BM25然后做融合排序。融合排序常用 RRFReciprocal Rank Fusion原理很简单把两个检索结果列表按排名倒数加权求和排名越靠前权重越高。这个算法不需要调参鲁棒性好我实测下来比单独用向量检索召回率高不少。再往上还有重排Rerank先粗召回 50 条再用重排模型精排取前 5 条。重排模型比向量模型慢但精度高适合对准确率要求高的场景。企业级系统里重排几乎是标配。4.4 知识库的更新与版本管理企业知识是动态的文档会更新、会作废。RAG 系统必须支持增量更新和版本管理。我的做法是每个文档有唯一 ID 和版本号。文档更新时先标记旧版本失效再插入新版本。检索时默认只检索有效版本。保留历史版本方便追溯“当时为什么这么回答”。这套机制听起来简单但很多团队一开始没设计后期文档一多就乱套了。建议一开始就把版本字段加上成本很低收益很大。5. 编排层与 Agent让 LLM 真正干活5.1 从单次调用到工作流企业级场景里单次“问-答”往往不够。比如一个合同审核场景流程可能是解析合同 → 提取关键条款 → 检索法规库 → 对比风险点 → 生成审核意见 → 人工复核。这是一个多步骤工作流需要编排层来管理。编排层要解决的核心问题是状态管理和错误处理。多步骤流程中某一步失败了怎么办重试还是跳过中间状态存哪里这些在 demo 里不用考虑在生产里必须考虑。5.2 Agent 的边界什么时候该用什么时候不该用Agent 现在很火但我要泼盆冷水不是所有场景都适合 Agent。Agent 的优势是自主决策、动态调用工具但代价是不可控、难调试、成本高。企业级场景里如果流程是固定的用工作流Workflow比用 Agent 更合适因为工作流可预测、可测试、成本可控。我一般建议流程固定用工作流流程需要动态决策才用 Agent。比如“根据用户问题决定查哪个数据库”这种适合 Agent“每天定时生成报表”这种工作流就够了。5.3 工具调用的工程细节Agent 调工具这块有几个工程细节容易踩坑。第一工具描述要写清楚模型是根据描述决定调不调、怎么调的描述模糊模型就会乱调。第二参数校验要做模型生成的参数可能格式不对要在调用前校验。第三超时和重试要设工具调用可能失败不能让整个流程卡死。第四调用日志要全方便排查“模型为什么调了这个工具”。工具调用的返回结果也要处理。如果返回内容太长要截断或摘要否则会撑爆上下文。如果返回是结构化数据最好转成自然语言再给模型模型对自然语言的理解更稳。6. 可观测性与成本控制企业级绕不开的两件事6.1 可观测性出了问题怎么查LLM 系统的可观测性和传统系统不太一样。传统系统看 QPS、延迟、错误率就够了LLM 系统还要看token 消耗、缓存命中率、检索召回率、回答质量。尤其是回答质量这个最难量化但最重要。我的做法是建立全链路追踪每个请求有一个 trace_id记录从入口到出口的每一步——网关路由到了哪个模型、检索召回了哪些 chunk、模型返回了什么、耗时多少、花了多少 token。这样出问题时能快速定位是检索的问题还是模型的问题。质量监控方面我会做抽样人工评估自动评估。自动评估可以用另一个模型给回答打分或者用规则检查比如回答是否包含引用、是否包含敏感词。虽然不完美但能发现大部分明显问题。6.2 成本控制钱要花在刀刃上LLM 成本主要是 token 消耗。控制成本有几个抓手提示词精简系统提示词能短则短别写一堆废话。我见过一个系统提示词写了 2000 token其实 500 token 就能说清楚。缓存相同或相似请求直接返回缓存结果。模型分级简单任务用便宜模型复杂任务用强模型。上下文压缩检索回来的内容做摘要或截断别一股脑塞给模型。输出长度限制设置 max_tokens防止模型啰嗦。我算过一笔账一个中等规模的企业问答系统优化前每月 token 成本可能是五位数优化后能降到三分之一。关键是要有成本监控知道钱花在哪才能优化。6.3 一个成本监控的指标表指标含义优化方向平均输入 token每次请求输入长度精简提示词、压缩上下文平均输出 token每次请求输出长度限制 max_tokens、优化提示词缓存命中率缓存命中比例优化缓存策略模型分布各模型调用占比调整路由策略单次请求成本平均每次花费综合优化日/月总成本总消耗预算控制这张表建议做成看板每天看。成本异常时能第一时间发现。7. 安全合规企业级的底线7.1 数据安全什么能发什么不能发企业级 LLM 最敏感的就是数据。我的原则是敏感数据不出内网。如果必须用外部模型要在网关层做脱敏把手机号、身份证、银行卡这些敏感信息替换成占位符模型返回后再还原。这个逻辑要在网关层统一做不能靠业务代码自觉。另外日志里也不能存敏感信息。前面配置示例里的mask_fields就是干这个的。日志要存但敏感字段要脱敏。7.2 内容安全输入输出都要过滤输入过滤是防止提示词注入和恶意请求输出过滤是防止模型生成不当内容。这两块都要在网关层做用规则 模型双重过滤。规则过滤快但覆盖不全模型过滤准但慢两者结合效果最好。7.3 权限控制谁能访问什么企业级系统里不同角色能访问的知识库范围不同。比如 HR 能查人事文档财务能查财务文档但不能互相查。这个权限要在检索层做检索时带上用户权限过滤条件只召回用户有权限的文档。这个逻辑不能放在应用层否则容易被绕过。8. 实操心得与常见问题排查8.1 上线前必须做的几件事第一压测。LLM 系统的瓶颈往往不在模型本身而在网关、检索、数据库。压测要覆盖全链路找出瓶颈。第二降级演练。故意把主模型停掉看系统能不能自动切备用。这个演练一定要做不然真出事时手忙脚乱。第三成本预估。按预估的日活和请求量算成本设置预算告警。第四安全审计。检查密钥管理、日志脱敏、权限控制是否到位。8.2 常见问题速查表问题现象可能原因排查方向回答不准确检索召回差检查切分、检索策略、重排响应慢模型慢或检索慢分段计时定位瓶颈成本超预期提示词太长或缓存没生效检查 token 消耗和缓存命中模型报错限流或参数错误检查网关日志和模型配额回答不一致缓存或温度参数检查缓存策略和 temperature敏感信息泄露脱敏没做或日志没过滤检查网关脱敏和日志配置8.3 几个我踩过的坑第一个坑过度依赖模型能力。一开始我以为模型够强就能解决所有问题后来发现检索质量才是天花板。检索召回不对再强的模型也答不对。第二个坑忽略提示词版本管理。提示词改了之后效果变差想回滚却发现没存旧版本。后来我把提示词也纳入版本管理每次改动都记录。第三个坑没有做请求去重。上线后发现大量重复请求白白烧钱。加了缓存后成本降了不少。第四个坑日志存太多。全量存日志导致存储成本飙升后来改成采样存储 关键字段全存。9. 后续可以怎么扩展这个系列的第一篇我主要把企业级 LLM 的整体架构和关键环节讲了一遍。往下还可以展开很多比如自部署模型的性能优化、多模态场景的工程实践、Agent 的评测体系、RAG 的自动化评估。每一个都够写一篇。如果你正在做企业级 LLM 落地我的建议是先把网关和知识层做扎实再考虑 Agent 和复杂编排。地基不稳上面盖得越高越危险。另外别追求一步到位先跑通最小闭环再逐步迭代。企业级系统是演进出来的不是设计出来的。我个人在实际操作中的体会是企业级 LLM 项目失败的原因技术问题占三成工程问题占三成组织问题占四成。技术可以学工程可以练但组织问题——比如业务不配合、数据拿不到、预算批不下来——往往才是真正的拦路虎。所以做这个事技术之外沟通和推动能力同样重要。
企业级 LLM 落地实战：从网关、RAG 到可观测性的架构设计
1. 企业级 LLM 落地先想清楚“企业级”三个字到底意味着什么这两年跟不少团队聊过大模型落地的事一个很明显的感受是个人玩 LLM 和企业上 LLM完全是两码事。个人场景里你调个 API、写个提示词、跑通一个 demo就算成功了但企业场景里这套东西能不能上线、能不能扛住并发、能不能过安全审计、出了问题能不能定位才是真正的门槛。所以“企业级 LLM”这个系列我想先把最容易被忽略的地基讲清楚再往下拆架构、拆选型、拆实操。先给结论企业级 LLM 不是“把开源模型部署到服务器上”这么简单它是一整套围绕模型构建的工程体系涵盖模型接入层、网关层、知识层、编排层、可观测层、安全合规层。你可以把它理解成盖楼——模型是钢筋水泥但只有钢筋水泥盖不成写字楼你还得有水电、消防、电梯、物业。很多团队一上来就纠结“用哪个模型”其实这个问题在企业级场景里排不进前三真正卡脖子的是网关怎么做、知识库怎么管、权限怎么控、成本怎么算。这篇文章适合三类人看一是正在做 LLM 技术选型的架构师二是准备把 demo 推向生产的开发负责人三是想搞清楚企业级 LLM 全貌的技术管理者。我会尽量用从业者的视角把每个环节“为什么这么设计”讲透而不是甩一堆名词。文中涉及的具体参数和配置一部分来自我自己的实践一部分是基于行业常见方案的合理推演你落地时还是要结合自己的业务量级做压测和调整。2. 企业级 LLM 的整体架构设计与选型逻辑2.1 为什么不能“一个 API 调到底”个人开发者最常见的做法是业务代码里直接import openai然后到处调。这个做法在 demo 阶段没问题但到了企业级就会暴露一堆问题。我列几个真实踩过的坑第一模型供应商一换业务代码要全改因为各家 SDK 的入参格式、返回结构、错误码都不一样第二没有统一的限流和重试某个业务线疯狂调用把配额打满其他业务线全部挂掉第三密钥散落在各个服务里安全审计根本过不了第四出了 badcase 想追溯“当时到底发了什么 prompt、模型返回了什么”日志里啥都没有。所以企业级的第一条设计原则就是在业务和模型之间加一层网关。这层网关不是简单的反向代理它要承担协议适配、鉴权、限流、路由、缓存、日志、计费这几件事。你可以用现成的开源方案也可以自研但这一层绝对不能省。2.2 分层架构把职责切干净我习惯把企业级 LLM 系统切成五层从下往上说模型层包括商用 API各家的大模型服务和自部署模型比如用 vLLM、TGI 部署的开源模型。这一层的关键是“抽象”对上暴露统一的调用接口。网关层统一入口负责鉴权、限流、路由、协议转换、日志埋点、成本统计。这一层是整个系统的“咽喉”设计好坏直接决定后续扩展性。知识与检索层RAG 的核心。包括文档解析、切分、向量化、向量库、检索重排。企业级场景里这一层往往比模型本身更重要因为通用模型不知道你公司的业务。编排层负责把多个能力串起来比如“先检索知识库再调用模型再调用工具查数据库最后汇总”。Agent、工作流引擎都属于这一层。应用层面向具体业务比如智能客服、合同审核、代码助手、数据分析。这么分层的好处是每一层可以独立演进。比如你想把模型从 A 换成 B只改模型层想换向量库只改知识层业务代码基本不动。这就是企业级和 demo 的本质区别——可替换性。2.3 选型时最容易踩的三个坑第一个坑是“唯模型论”。很多团队花大量时间对比模型跑分却忽略了工程配套。实际上一个中等能力的模型配上好的 RAG 和好的提示词工程效果往往超过一个强模型裸调。模型选型要看的是上下文长度、函数调用能力、结构化输出稳定性、并发限制、价格、以及是否支持私有化。第二个坑是“忽略成本模型”。企业级调用量和 demo 不是一个量级。你得算清楚每千 token 的输入输出价格、缓存命中率、平均每次请求消耗多少 token、每天多少请求。我见过一个团队上线后才发现光是系统提示词就占了每次请求 40% 的 token因为提示词写得太啰嗦。优化提示词后成本直接降了三成。第三个坑是“没有降级方案”。商用 API 会限流、会抖动、会涨价。企业级系统必须有降级路径主模型不可用时切备用模型或者切到规则兜底。这个切换逻辑要提前设计好不能等出事再补。3. 网关层企业级 LLM 的“咽喉”怎么建3.1 网关到底要解决哪些问题网关层是企业级 LLM 最容易被低估的一层。我把它要解决的问题列成一张表你可以对照自己的系统看看缺了哪些能力解决的问题不做会怎样统一鉴权密钥集中管理按业务线分配密钥泄露审计不过限流熔断防止单业务打满配额一个业务拖垮全公司多模型路由按成本/能力/可用性选模型换模型要改业务代码协议适配屏蔽各家 API 差异业务代码到处是 if-else请求缓存相同请求直接返回重复烧钱日志追踪记录完整请求链路出问题无法定位成本统计按业务线算账月底不知道钱花哪了内容安全输入输出过滤合规风险这张表里我觉得最容易被忽略的是请求缓存和成本统计。缓存这块很多语义相同的请求其实可以复用结果尤其是知识库问答场景命中率能到 20% 以上。成本统计则是给管理层看的没有这个数据你没法证明 LLM 项目的 ROI。3.2 路由策略怎么决定用哪个模型路由策略是网关的核心逻辑。我一般会设计成多级路由第一级是按业务线路由。不同业务对模型能力要求不同客服场景可能用便宜的小模型就够代码生成场景必须用强模型。这一级在配置里写死简单可靠。第二级是按请求特征路由。比如根据输入长度、是否包含图片、是否需要函数调用动态选模型。长上下文请求路由到支持长上下文的模型简单问答路由到便宜模型。第三级是按可用性路由。主模型超时或报错自动切备用模型。这里要注意切换要有熔断机制不能主模型挂了还一直重试把备用模型也拖垮。路由配置我建议用配置中心管理支持热更新。这样调整策略不用重启服务运维成本低很多。3.3 一个可落地的网关配置示例下面是一个基于常见网关思路的配置示例用 YAML 表达你可以根据自己的技术栈翻译成对应实现gateway: auth: type: api_key key_header: X-LLM-Key key_store: redis rate_limit: default: 100/min per_business: customer_service: 500/min code_assistant: 200/min routes: - name: default_chat match: business: customer_service primary: provider: vendor_a model: small-chat timeout: 10s fallback: provider: vendor_b model: backup-chat timeout: 15s cache: enabled: true ttl: 3600 key_strategy: semantic_hash logging: level: full store: elasticsearch mask_fields: [user_phone, id_card]这个配置里mask_fields是安全合规的关键日志里不能出现敏感信息。key_strategy: semantic_hash表示用语义哈希做缓存键相同意思的问题能命中同一缓存。提示缓存策略要谨慎涉及实时数据的问答不能缓存否则会返回过期答案。建议按业务线配置是否开启缓存。4. 知识与检索层企业级 RAG 的工程细节4.1 为什么企业级 RAG 比想象中难RAG 这个词现在被说烂了但真正在企业里跑通 RAG 的团队不多。难点不在“向量检索”这个技术本身而在数据治理。企业文档格式五花八门PDF、Word、Excel、PPT、扫描件、网页、数据库。每种格式的解析质量直接决定 RAG 效果。我见过太多团队模型选得很好但文档解析一塌糊涂切出来的 chunk 全是乱码检索出来的内容驴唇不对马嘴。所以企业级 RAG 的第一步不是选向量库而是把文档解析和清洗做扎实。扫描件要 OCR表格要结构化多栏 PDF 要正确分栏页眉页脚要去掉。这些脏活累活才是决定 RAG 成败的关键。4.2 切分策略chunk 大小怎么定切分是 RAG 里最考验经验的地方。切太大检索精度下降因为一个 chunk 里混了多个主题切太小上下文不完整模型没法回答。我的经验是通用文档chunk 大小 300-500 token重叠 50-100 token。技术文档/法律合同chunk 可以大一些500-800 token因为条款之间关联性强。问答对/FAQ按问答对切不要硬切。重叠overlap的作用是防止关键信息被切断。比如一句话正好跨在两个 chunk 边界上有重叠就能保证至少一个 chunk 包含完整信息。另外我强烈建议在 chunk 里保留元数据来源文档、章节标题、页码、更新时间。这些元数据在检索时可以用于过滤比如“只检索最近一年的文档”也能在回答时给出引用来源提升可信度。4.3 检索优化从向量检索到混合检索纯向量检索有个问题对精确匹配不敏感。比如用户问“XX 型号的参数”向量检索可能召回一堆语义相近但型号不对的内容。所以企业级 RAG 一般用混合检索向量检索 关键词检索BM25然后做融合排序。融合排序常用 RRFReciprocal Rank Fusion原理很简单把两个检索结果列表按排名倒数加权求和排名越靠前权重越高。这个算法不需要调参鲁棒性好我实测下来比单独用向量检索召回率高不少。再往上还有重排Rerank先粗召回 50 条再用重排模型精排取前 5 条。重排模型比向量模型慢但精度高适合对准确率要求高的场景。企业级系统里重排几乎是标配。4.4 知识库的更新与版本管理企业知识是动态的文档会更新、会作废。RAG 系统必须支持增量更新和版本管理。我的做法是每个文档有唯一 ID 和版本号。文档更新时先标记旧版本失效再插入新版本。检索时默认只检索有效版本。保留历史版本方便追溯“当时为什么这么回答”。这套机制听起来简单但很多团队一开始没设计后期文档一多就乱套了。建议一开始就把版本字段加上成本很低收益很大。5. 编排层与 Agent让 LLM 真正干活5.1 从单次调用到工作流企业级场景里单次“问-答”往往不够。比如一个合同审核场景流程可能是解析合同 → 提取关键条款 → 检索法规库 → 对比风险点 → 生成审核意见 → 人工复核。这是一个多步骤工作流需要编排层来管理。编排层要解决的核心问题是状态管理和错误处理。多步骤流程中某一步失败了怎么办重试还是跳过中间状态存哪里这些在 demo 里不用考虑在生产里必须考虑。5.2 Agent 的边界什么时候该用什么时候不该用Agent 现在很火但我要泼盆冷水不是所有场景都适合 Agent。Agent 的优势是自主决策、动态调用工具但代价是不可控、难调试、成本高。企业级场景里如果流程是固定的用工作流Workflow比用 Agent 更合适因为工作流可预测、可测试、成本可控。我一般建议流程固定用工作流流程需要动态决策才用 Agent。比如“根据用户问题决定查哪个数据库”这种适合 Agent“每天定时生成报表”这种工作流就够了。5.3 工具调用的工程细节Agent 调工具这块有几个工程细节容易踩坑。第一工具描述要写清楚模型是根据描述决定调不调、怎么调的描述模糊模型就会乱调。第二参数校验要做模型生成的参数可能格式不对要在调用前校验。第三超时和重试要设工具调用可能失败不能让整个流程卡死。第四调用日志要全方便排查“模型为什么调了这个工具”。工具调用的返回结果也要处理。如果返回内容太长要截断或摘要否则会撑爆上下文。如果返回是结构化数据最好转成自然语言再给模型模型对自然语言的理解更稳。6. 可观测性与成本控制企业级绕不开的两件事6.1 可观测性出了问题怎么查LLM 系统的可观测性和传统系统不太一样。传统系统看 QPS、延迟、错误率就够了LLM 系统还要看token 消耗、缓存命中率、检索召回率、回答质量。尤其是回答质量这个最难量化但最重要。我的做法是建立全链路追踪每个请求有一个 trace_id记录从入口到出口的每一步——网关路由到了哪个模型、检索召回了哪些 chunk、模型返回了什么、耗时多少、花了多少 token。这样出问题时能快速定位是检索的问题还是模型的问题。质量监控方面我会做抽样人工评估自动评估。自动评估可以用另一个模型给回答打分或者用规则检查比如回答是否包含引用、是否包含敏感词。虽然不完美但能发现大部分明显问题。6.2 成本控制钱要花在刀刃上LLM 成本主要是 token 消耗。控制成本有几个抓手提示词精简系统提示词能短则短别写一堆废话。我见过一个系统提示词写了 2000 token其实 500 token 就能说清楚。缓存相同或相似请求直接返回缓存结果。模型分级简单任务用便宜模型复杂任务用强模型。上下文压缩检索回来的内容做摘要或截断别一股脑塞给模型。输出长度限制设置 max_tokens防止模型啰嗦。我算过一笔账一个中等规模的企业问答系统优化前每月 token 成本可能是五位数优化后能降到三分之一。关键是要有成本监控知道钱花在哪才能优化。6.3 一个成本监控的指标表指标含义优化方向平均输入 token每次请求输入长度精简提示词、压缩上下文平均输出 token每次请求输出长度限制 max_tokens、优化提示词缓存命中率缓存命中比例优化缓存策略模型分布各模型调用占比调整路由策略单次请求成本平均每次花费综合优化日/月总成本总消耗预算控制这张表建议做成看板每天看。成本异常时能第一时间发现。7. 安全合规企业级的底线7.1 数据安全什么能发什么不能发企业级 LLM 最敏感的就是数据。我的原则是敏感数据不出内网。如果必须用外部模型要在网关层做脱敏把手机号、身份证、银行卡这些敏感信息替换成占位符模型返回后再还原。这个逻辑要在网关层统一做不能靠业务代码自觉。另外日志里也不能存敏感信息。前面配置示例里的mask_fields就是干这个的。日志要存但敏感字段要脱敏。7.2 内容安全输入输出都要过滤输入过滤是防止提示词注入和恶意请求输出过滤是防止模型生成不当内容。这两块都要在网关层做用规则 模型双重过滤。规则过滤快但覆盖不全模型过滤准但慢两者结合效果最好。7.3 权限控制谁能访问什么企业级系统里不同角色能访问的知识库范围不同。比如 HR 能查人事文档财务能查财务文档但不能互相查。这个权限要在检索层做检索时带上用户权限过滤条件只召回用户有权限的文档。这个逻辑不能放在应用层否则容易被绕过。8. 实操心得与常见问题排查8.1 上线前必须做的几件事第一压测。LLM 系统的瓶颈往往不在模型本身而在网关、检索、数据库。压测要覆盖全链路找出瓶颈。第二降级演练。故意把主模型停掉看系统能不能自动切备用。这个演练一定要做不然真出事时手忙脚乱。第三成本预估。按预估的日活和请求量算成本设置预算告警。第四安全审计。检查密钥管理、日志脱敏、权限控制是否到位。8.2 常见问题速查表问题现象可能原因排查方向回答不准确检索召回差检查切分、检索策略、重排响应慢模型慢或检索慢分段计时定位瓶颈成本超预期提示词太长或缓存没生效检查 token 消耗和缓存命中模型报错限流或参数错误检查网关日志和模型配额回答不一致缓存或温度参数检查缓存策略和 temperature敏感信息泄露脱敏没做或日志没过滤检查网关脱敏和日志配置8.3 几个我踩过的坑第一个坑过度依赖模型能力。一开始我以为模型够强就能解决所有问题后来发现检索质量才是天花板。检索召回不对再强的模型也答不对。第二个坑忽略提示词版本管理。提示词改了之后效果变差想回滚却发现没存旧版本。后来我把提示词也纳入版本管理每次改动都记录。第三个坑没有做请求去重。上线后发现大量重复请求白白烧钱。加了缓存后成本降了不少。第四个坑日志存太多。全量存日志导致存储成本飙升后来改成采样存储 关键字段全存。9. 后续可以怎么扩展这个系列的第一篇我主要把企业级 LLM 的整体架构和关键环节讲了一遍。往下还可以展开很多比如自部署模型的性能优化、多模态场景的工程实践、Agent 的评测体系、RAG 的自动化评估。每一个都够写一篇。如果你正在做企业级 LLM 落地我的建议是先把网关和知识层做扎实再考虑 Agent 和复杂编排。地基不稳上面盖得越高越危险。另外别追求一步到位先跑通最小闭环再逐步迭代。企业级系统是演进出来的不是设计出来的。我个人在实际操作中的体会是企业级 LLM 项目失败的原因技术问题占三成工程问题占三成组织问题占四成。技术可以学工程可以练但组织问题——比如业务不配合、数据拿不到、预算批不下来——往往才是真正的拦路虎。所以做这个事技术之外沟通和推动能力同样重要。
