1. 从能跑通到敢上线企业级 LLM 到底卡在哪很多人第一次接触 LLM 应用都是从一个几十行的脚本开始的调个 API拼一段 prompt本地跑通效果惊艳然后兴冲冲地跟老板说我们能做 AI 了。结果真到了要接入公司业务、要面对真实用户、要处理敏感数据的时候才发现从 demo 到生产之间隔着一整条鸿沟。这条鸿沟就是企业级三个字的分量。我自己踩过这个坑。早期给一个内部团队做知识问答本地用开源模型跑得好好的一上测试环境就各种问题并发一上来响应时间从 2 秒飙到 30 秒用户上传的文档里混着各种格式解析全乱模型偶尔还会把 A 部门的内部数据答给 B 部门的同事。这些问题没有一个是模型不够强导致的全都是工程层面的缺失。所以这个系列我想系统地把企业级 LLM 落地这件事拆开讲第一篇先解决最根本的问题企业级和玩具级的分界线到底在哪里以及我们该用什么心态和架构去面对它。这篇文章适合几类人正在做 LLM 应用但准备上生产的工程师、需要评估 LLM 方案可行性的技术负责人、以及想搞清楚企业级这个词到底意味着什么的开发者。我不会只讲概念会把每个环节的取舍逻辑、参数计算、实操细节都摊开说让你看完能直接对照自己的项目做体检。先给一个我自己的判断标准一个 LLM 系统能不能叫企业级不看它用了多强的模型而看它在模型出错、流量暴涨、数据敏感、需求变更这四种压力下还能不能稳住。模型能力只是其中一个变量而且往往不是最关键的变量。下面我按这个逻辑把企业级 LLM 的几个核心战场逐个拆解。2. 企业级 LLM 的四道生死线2.1 数据边界什么能进 prompt什么打死都不能进企业场景和公开 demo 最大的区别是数据有归属、有分级、有合规要求。你在个人项目里可以把任何文本丢给任意 API但在企业里一段客户合同、一份财务报表、一条员工薪资记录能不能离开内网、能不能进入第三方模型的上下文是有明确红线的。我见过最危险的做法是把整个知识库不加区分地灌进向量库然后让模型自由检索。问题在于向量检索是基于语义相似度的它不理解权限这个概念。一个普通员工问今年的调薪方案检索器很可能就把 HR 的敏感文档召回出来喂给模型模型再老老实实答出来。这不是模型的问题是架构里根本没有权限这一层。正确的做法是在检索和生成之间插入权限过滤。具体来说每一条进入向量库的文档都要打上元数据标签至少包括所属部门、密级、可访问角色。检索时先按用户的身份做一次硬过滤再在过滤后的子集里做语义排序。伪代码大概是这样def retrieve(query, user): # 第一步基于用户身份确定可见范围这是硬约束 allowed_scopes get_user_scopes(user) # 例如 [dept:finance, level:public] # 第二步在可见范围内做向量检索 candidates vector_store.search( query_embeddingembed(query), filter{scope: {$in: allowed_scopes}}, top_k20 ) # 第三步重排序后再截断 return rerank(query, candidates)[:5]这里的关键是filter必须作用在检索阶段而不是生成之后。很多人图省事先检索一堆再让模型注意不要泄露这是把安全寄托在模型的自觉上而模型是没有权限概念的它只会顺着上下文往下写。权限必须是代码层面的硬逻辑不能是 prompt 里的软约束。还有一个容易被忽略的点日志。企业级系统里用户的 query 和模型的 response 往往都要落库做审计。这时候如果 query 里带了敏感信息日志本身就变成了泄露源。我的做法是对日志做脱敏身份证、手机号、银行卡这类结构化敏感字段用正则先替换掉非结构化的敏感内容则依赖前面的权限过滤来保证根本不会进入链路。2.2 稳定性模型挂了、超时了、限流了怎么办demo 阶段我们默认模型 API 永远可用、永远秒回。生产环境里这是奢望。第三方模型服务会限流、会超时、会偶发 5xx自建模型会 OOM、会被其他任务抢占 GPU。企业级系统的要求是上游抖动下游不能雪崩。我一般会做三层防护。第一层是超时与重试。给每次模型调用设一个合理的超时比如首 token 3 秒、整体 30 秒超时后做有限次数的重试重试要带指数退避避免把已经过载的服务打得更死。第二层是降级。当主模型不可用时切到备用模型或者规则兜底。比如一个客服问答系统主模型挂了可以降级到 FAQ 精确匹配虽然体验差一点但至少不会整个页面转圈。第三层是熔断。当错误率超过阈值直接快速失败给用户一个明确的服务繁忙提示而不是让请求堆积把线程池耗尽。这里有个参数值得算一下。假设你的服务 QPS 是 50模型平均响应 2 秒那么理论上同时会有 100 个请求在途。如果你的线程池只有 50 个线程第 51 个请求就得排队排队时间会随着负载非线性增长。所以线程池大小、连接池大小、超时时间这三个参数必须一起调不能拍脑袋。我的经验公式是线程池大小 ≈ 峰值 QPS × P99 响应时间 × 安全系数1.5 左右。按上面的例子50 × 2 × 1.5 150 个线程再配合合理的队列长度和拒绝策略。2.3 成本token 是怎么悄悄烧掉预算的LLM 应用的成本结构和传统 Web 服务完全不同。传统服务扩容主要看 CPU 和内存LLM 应用的大头是 token。而 token 消耗有个特点它对用户是不可见的对开发者是滞后的。你可能上线一周才发现账单超了预期十倍。成本失控通常来自三个地方。第一是上下文过长。很多人为了让模型知道更多把检索到的文档一股脑塞进去top_k 设成 20每篇 1000 字一次请求就是两万 token。实际上真正有用的往往就前 3 篇。第二是重复调用。同一个问题用户刷新一下又问一遍系统老老实实再调一次模型。第三是没有缓存。高频的、答案稳定的问题完全可以缓存。我的做法是给每次调用都打上 token 计量按用户、按接口、按天做聚合设一个预算告警线。同时在检索环节严格控制 top_k 和单篇长度用重排序把真正相关的挑出来。缓存则分两级精确匹配的 query 直接返回缓存结果语义相近的 query 用向量相似度做模糊缓存。实测下来一个中等规模的知识问答系统加上这两级缓存后 token 成本能降 40% 以上。2.4 可观测性出问题时你拿什么排查传统服务出问题看日志、看监控、看链路追踪基本能定位。LLM 应用多了一层不确定性同样的输入模型可能给出不同的输出。用户投诉它答错了你复现的时候可能根本复现不出来。所以企业级 LLM 必须把每次调用的完整上下文记下来用户的原始 query、经过处理的 prompt、检索到的文档、模型的原始输出、耗时、token 数、用的哪个模型版本。这些数据一方面用于排查问题另一方面是后续做效果评估和模型迭代的基础。我习惯把这条记录叫调用快照它比传统日志重但比传统日志值钱得多。有了快照你才能回答一些关键问题这个错误答案是因为检索没召回对的文档还是召回了但模型没用好还是模型本身能力不够这三种情况的修复方向完全不同。没有快照你只能靠猜。3. 架构选型自建、调用还是混合3.1 三种路线的真实成本对比企业做 LLM绕不开一个决策模型是自己部署还是调 API。这个问题没有标准答案取决于你的数据敏感度、调用量、团队能力和预算。我把三种常见路线的特点整理成表方便对照。维度纯 API 调用纯自建部署混合方案数据出境有风险需评估完全可控敏感走本地其余走 API前期投入极低高GPU、运维中等单位成本随量线性增长量大后摊薄按敏感度分流模型能力最强随时更新受限于开源模型兼顾运维复杂度低高中高弹性好差扩容慢较好我个人的经验是大多数企业最终会走向混合方案。原因很现实真正需要严格数据隔离的场景其实只占一部分比如涉及核心商业机密、个人隐私的请求而大量的通用问答、文案生成、代码辅助用 API 完全没问题还能享受最强模型的能力。把这两类流量分开路由既守住了安全底线又控制了成本。3.2 路由层怎么设计才不添乱混合方案的核心是一个路由层它决定每个请求走本地还是走 API。路由的依据可以是数据分级标签、用户身份、请求类型甚至可以是 query 本身的敏感度检测结果。这里有个坑路由逻辑如果写得太复杂会变成新的故障点。我见过一个系统路由规则有十几条还依赖一个外部配置服务结果配置服务一抖动整个 LLM 链路全挂。所以路由规则要尽量简单、可预测最好能本地缓存配置变更走灰度发布而不是实时拉取。另一个细节是降级路径要对称。如果本地模型挂了能不能临时把非敏感流量也切到 API如果 API 挂了本地模型能不能扛住一部分这些都要提前设计好而不是等出事再临时改代码。3.3 别被开源榜单带偏选型选模型的时候很多人第一反应是看各种公开榜单的排名。榜单有参考价值但直接拿来选型往往会翻车。原因有几个榜单的评测集和你的业务场景可能完全不搭榜单测的是通用能力而你的场景可能高度垂直榜单不反映推理成本、延迟、并发能力这些工程指标。我的做法是自建一个小型评测集从真实业务里抽 100 到 200 个典型问题人工标注期望答案然后让候选模型都跑一遍按准确率、延迟、成本三个维度打分。这个评测集不需要很大但一定要真实。实测下来榜单第一的模型在你的场景里未必最好有时候一个中等规模的开源模型经过针对性微调效果反而更稳。4. 落地第一步把需求翻译成技术指标4.1 要准到底是多少准确率业务方提需求的时候说的都是要准要快要好用。这些词没法直接指导开发。企业级落地的第一步是把这些模糊需求翻译成可量化、可验收的技术指标。要准翻译过来是在什么评测集上达到多少准确率。比如在 200 条历史工单的测试集上答案完全正确的比例不低于 85%包含正确答案的比例不低于 95%。注意这里要区分完全正确和包含正确信息因为 LLM 的输出往往是段落严格逐字匹配不现实通常用人工评估或者用另一个模型做裁判。要快翻译过来是首 token 延迟和整体延迟的 P95 指标。对话类场景对首 token 延迟敏感用户等 3 秒还没出字就会觉得卡而文档生成类场景更关注整体完成时间。这两个指标要分开定。要好用则涉及交互设计、错误提示、多轮上下文管理等等这部分我会在后续文章里专门展开。4.2 一个可落地的指标模板我一般用这样一张表来对齐需求每个指标都要有明确的数值、测量方法和验收标准指标类别具体指标目标值测量方式效果答案准确率≥85%人工评测 200 条效果检索召回率≥90%标注集验证性能首 token 延迟 P95≤2s线上监控性能整体延迟 P95≤8s线上监控稳定服务可用性≥99.5%监控统计成本单次调用平均 token≤3000计量统计安全敏感信息泄露0 起审计 红队测试这张表的价值在于它把做得好不好变成了可以争论、可以验收的具体数字。项目上线后对着这张表逐项核对比任何主观评价都靠谱。4.3 指标之间是要打架的必须提醒一点这些指标不是孤立的它们经常互相冲突。想要更准往往要检索更多文档、用更强的模型这会让延迟和成本上升。想要更快就得减少上下文、用小模型准确率可能下降。所以定指标的时候不能每项都往高了定要找到平衡点。我的经验是先确定哪个是不可妥协的底线。比如金融场景准确率和安全性是底线延迟可以放宽到 10 秒而闲聊类场景延迟是底线准确率可以松一些。把底线定死其他指标在这个约束下优化决策就清晰了。5. 那些没人告诉你但一定会踩的坑5.1 文档解析比想象中难十倍做知识库问答第一步是把企业文档喂进去。很多人以为这就是读文件、切块、向量化。真做起来才发现企业文档的格式之混乱超乎想象扫描版 PDF 没有文字层、Word 里嵌着图片表格、Excel 有合并单元格、PPT 一页里塞了十几个文本框。这些解析不好后面检索再强也是垃圾进垃圾出。我的建议是解析环节要单独做质量抽检。随机抽 50 个文档人工看解析出来的文本是不是完整、顺序对不对、表格有没有错乱。这一步花的时间远比后面调模型参数值。表格尤其麻烦简单的表格可以转成 Markdown复杂的嵌套表格往往需要专门处理甚至考虑保留图片让多模态模型来读。5.2 切块策略没有银弹文本切块chunking是另一个重灾区。切太大检索精度下降还会浪费 token切太小语义不完整模型拿到半句话没法回答。常见的固定长度切块比如每 500 字一刀简单但粗暴经常把一句话、一个表格切断。我比较推荐按语义结构切块优先按标题、段落、列表项这些自然边界切再对过长的段落做二次切分。同时给每个块加上它所属的章节路径作为上下文比如第三章 3.2 报销流程 差旅报销这样即使块本身很短检索时也能借助路径信息判断相关性。切块大小我一般控制在 300 到 800 字之间具体看文档类型技术文档可以小一点叙述性文档可以大一点。5.3 多轮对话的上下文会失控单轮问答好做多轮对话就麻烦了。用户说它多少钱这个它指什么得从历史里找。但如果把全部历史都塞进 prompt几轮之后上下文就爆了而且早期无关的内容还会干扰模型。我的做法是对历史做摘要压缩。保留最近两三轮的完整对话更早的对话用模型压缩成一段简短摘要。同时维护一个对话状态记录当前讨论的对象、已确认的信息这样即使历史被压缩关键信息也不丢。这个状态可以用结构化的 JSON 存比纯文本更可靠。5.4 评测集要持续维护前面说自建评测集这里补充一个容易忽略的点评测集不是建一次就完事它要跟着业务一起长。上线后用户问的新问题、暴露的新错误都应该沉淀进评测集。我习惯每次模型迭代或 prompt 调整后都跑一遍全量评测集看有没有回归。没有这个机制你改了一处可能悄悄弄坏了另一处而线上未必马上暴露。6. 写在系列开头的一点个人体会做企业级 LLM 这几年我最大的感受是这个领域的难点八成不在模型而在模型之外。权限、稳定性、成本、可观测性、数据质量这些传统软件工程的老问题在 LLM 场景下以新的形式重新出现而且因为模型的不确定性处理起来更棘手。我见过太多团队把精力全花在换更强的模型调更好的 prompt上却对权限过滤、超时降级、调用快照这些基础设施敷衍了事。结果就是 demo 惊艳、上线翻车。反过来那些把工程底座打扎实的团队哪怕用的是中等模型系统也能稳定跑起来然后在这个基础上慢慢优化效果。这个系列我会沿着数据、稳定性、成本、可观测性、评测这条主线继续往下写每一篇都尽量给到能直接抄的配置和能直接避的坑。如果你正在做类似的事欢迎对照着给自己的项目做个体检看看哪道生死线还没守住。