1. 从能跑通到敢上线企业级LLM的鸿沟到底在哪很多团队做LLM项目的路径都差不多拿一个开源模型配个向量库搭个RAG流程跑几个demo问题效果看着还行然后老板问什么时候能上线大家面面相觑。这个场景我见过太多次了。问题不在于模型不够强而在于从能跑通到敢上线之间隔着一整套工程化体系——而这一整套东西才是企业级三个字的真正分量。我自己参与过几个从零到一的企业LLM项目也帮朋友的公司做过技术评审。说实话模型选型在整个工程里大概只占20%的权重剩下80%全是围绕稳定性、可观测性、成本控制、安全合规、评测体系这些不性感的活儿。但恰恰是这些不性感的东西决定了一个LLM应用是停留在PPT里还是能真正扛住生产环境的流量。这篇内容适合谁看如果你正在做LLM相关的项目不管是内部知识库、智能客服、代码助手还是文档分析只要你的目标是从原型走向生产那这里面的经验应该对你有用。如果你还在选模型阶段也可以看看后面关于评测和成本的部分能帮你少走一些弯路。我打算按企业级LLM落地的几个核心模块来展开先聊评测体系怎么建再说RAG在生产环境里的真实挑战然后是Agent的可靠性问题接着是成本与延迟的工程优化最后说说安全与合规的底线。每个部分我都会给出具体的做法和踩过的坑不搞虚的。2. 评测体系没有它你根本不知道模型什么时候变笨了2.1 为什么感觉还行是最危险的信号我见过太多团队用感觉来评估LLM效果。产品经理试几个问题觉得回答挺像样的就认为可以了。这种做法在demo阶段没问题但一旦上线用户的问题分布和你的测试用例完全不是一回事。更麻烦的是模型版本更新、prompt调整、检索策略变化任何一个环节改动都可能让效果悄悄退化而你根本不知道。企业级LLM的第一个基础设施就是评测体系。没有评测所有的优化都是盲人摸象。评测体系的核心不是跑一个公开榜单看分数而是建立一套贴合你自己业务场景的、可重复执行的、能给出明确信号的评估流程。2.2 三层评测框架的搭建方法我一般会把评测分成三层基础能力评测、场景任务评测、线上效果追踪。基础能力评测关注模型在通用任务上的表现比如指令遵循、推理能力、格式输出稳定性。这部分可以参考公开榜单的思路但不要迷信分数。公开榜单的题目和你的业务场景往往差距很大一个在榜单上排名靠前的模型在你的垂直领域可能表现平平。我的做法是从公开榜单里筛选出和业务相关的维度比如中文理解、长文本处理、结构化输出自己构造一批测试用例来验证。场景任务评测是最关键的一层。你需要把业务场景拆解成具体的任务类型每个任务类型准备一批标注好的测试集。比如做智能客服任务类型可能包括意图识别、知识检索、答案生成、多轮追问处理。每个类型准备50到200条测试用例覆盖典型问题和边界情况。评测指标也要分类型设计——意图识别看准确率和召回率答案生成看事实一致性和完整性多轮对话看上下文保持能力。线上效果追踪是最后一层也是最容易被忽略的。上线之后你需要持续收集用户反馈信号点赞点踩、追问率、会话时长、转人工率。这些信号比任何离线评测都真实。我通常会做一个简单的反馈看板把关键指标按天聚合一旦发现某个指标异常波动就触发排查流程。2.3 LLM as Judge好用但有陷阱用LLM来评估LLM的输出这个思路现在很流行也确实能解决人工评估成本高的问题。但这里面有几个坑必须注意。第一个坑是位置偏见。如果你让模型比较两个回答哪个更好它倾向于选择排在前面或者更长的那个。解决办法是交换顺序多评几次取平均结果。第二个坑是评分膨胀。模型倾向于给高分尤其是当prompt里暗示请评估以下回答的质量时它往往会给出偏正面的评价。我的做法是设计更具体的评分维度比如事实准确性、完整性、格式规范性每个维度单独打分而不是笼统地问好不好。第三个坑是评估模型和被评估模型的能力差距。如果你用一个弱模型去评估强模型的输出它可能根本识别不出错误。所以评估模型的选择很重要通常建议用比被评估模型更强或者同级别的模型来做Judge。注意LLM as Judge适合做粗筛和趋势监控不适合做最终的质量判定。关键场景的评测结果还是需要人工抽检来校准。2.4 评测集的建设与维护评测集不是建一次就完事了。业务在变用户的问题分布在变评测集也需要持续更新。我一般会按季度做一次评测集的review把线上出现的bad case补充进去把已经不再出现的场景移除。评测集的规模不需要很大但覆盖面要全。我的经验是每个任务类型100条左右的测试用例就能给出比较稳定的评估信号。关键是这些用例要经过人工审核确保标注质量。标注标准也要写清楚不然不同的人标注结果不一致评测就失去了意义。另外评测集要版本化管理。每次模型更新或者prompt调整都用同一版本的评测集来跑这样才能对比出变化。如果评测集本身也在变那就没法判断效果波动是来自模型还是来自评测集。3. RAG在生产环境里的真实挑战检索不准只是冰山一角3.1 文档解析最脏最累但最重要的一步RAG的第一道坎不是检索算法而是文档解析。企业里的文档格式五花八门PDF、Word、Excel、PPT、扫描件、网页、邮件每种格式的解析难度都不一样。PDF尤其麻烦有文字层的还好扫描件就得走OCR而OCR的准确率又受扫描质量影响。我踩过最大的坑是表格解析。很多企业的核心知识藏在表格里但普通的PDF解析工具会把表格结构打乱变成一堆无法理解的文字碎片。后来我们专门针对表格做了处理先用版面分析识别表格区域再用表格识别模型提取结构最后转成Markdown格式保留行列关系。这一步做不好后面的检索和生成全是白搭。还有一个容易被忽略的点是文档分块策略。很多人直接用固定长度切分比如每500个token一块。这种做法在简单场景下能用但遇到结构化文档就会出问题——一个完整的章节被切到两个块里检索时只能召回一半生成时自然就不完整。我的做法是按文档结构分块标题、段落、列表、表格各自成块块与块之间保留层级关系。这样检索时能精确定位到具体章节生成时也能保持上下文完整。3.2 检索策略向量检索不是银弹向量检索是RAG的标配但它有几个天然缺陷。第一它对精确匹配不敏感。用户问2024年Q3的营收数据向量检索可能召回一堆关于营收的段落但就是找不到那个具体的数字。第二它对长尾query效果差。训练数据里少见的表达方式向量化之后可能偏离语义空间。第三它无法处理否定和排除条件。用户问除了A方案还有哪些选择向量检索很难理解除了这个逻辑。所以生产环境里的检索策略通常是混合的向量检索关键词检索元数据过滤。向量检索负责语义匹配关键词检索比如BM25负责精确匹配元数据过滤负责缩小范围。三路召回之后再做融合排序效果比单路检索稳定得多。融合排序的算法也有讲究。简单的方法是加权求和但权重怎么定需要根据业务调。更精细的做法是用一个rerank模型对召回结果重新排序把最相关的排到前面。Rerank模型的选择上我建议用交叉编码器cross-encoder而不是双编码器bi-encoder虽然慢一些但准确率明显更高。3.3 上下文窗口的取舍塞得越多不一定越好很多人觉得既然模型支持长上下文那就把所有检索到的内容都塞进去。这种做法有两个问题一是成本高token消耗大二是效果反而可能变差因为无关信息会干扰模型判断。我的经验是检索召回可以多但塞给模型的上下文要精。一般控制在3到5个最相关的块每个块200到500字。如果确实需要更多信息可以用摘要的方式压缩而不是直接堆原文。另外上下文的排列顺序也有影响。模型对开头和结尾的内容注意力更强中间部分容易被忽略。所以最重要的信息应该放在开头或者结尾而不是埋在中间。3.4 幻觉抑制让模型说我不知道RAG的一个核心目标是减少幻觉但实际做下来幻觉并没有消失只是换了一种形式。模型不再凭空编造而是会过度解读检索到的内容——把不相关的信息强行关联到问题上或者把部分信息补全成完整答案。抑制幻觉的关键是让模型学会说我不知道。这需要在prompt里明确指示如果检索到的内容不足以回答问题就如实告知不要猜测。同时在生成结果里加上引用来源让用户能自己判断答案的可信度。还有一个技巧是答案一致性检查。让模型生成答案后再用一个独立的prompt让它检查答案是否完全基于检索内容。如果发现有不一致的地方就重新生成或者标记出来。这个步骤会增加一些延迟但在关键场景下值得做。4. Agent可靠性从演示很酷到生产可用的距离4.1 Agent的失败模式比你想的多Agent在演示的时候很惊艳你给它一个任务它自己规划步骤、调用工具、处理异常最后给出结果。但到了生产环境失败模式多得让人头疼。常见的失败模式包括工具调用参数错误比如日期格式不对、必填字段缺失、多步推理偏离目标走着走着就忘了最初要干什么、循环调用同一个工具反复调用陷入死循环、错误处理缺失工具返回错误后不知道怎么办直接卡住。这些问题的根源在于Agent的决策过程是概率性的不像传统程序那样有确定的控制流。所以企业级Agent的设计思路和传统软件开发完全不同——你需要假设它随时会出错然后设计容错机制。4.2 工具设计的防御性原则工具是Agent和外部世界交互的接口。工具设计得好不好直接决定了Agent的可靠性。我总结了几条防御性设计原则参数校验前置。不要让Agent直接调用底层API而是在中间加一层参数校验。比如日期参数先检查格式是否正确不正确就返回明确的错误信息让Agent重新生成。返回值结构化。工具的返回值要尽量结构化包含状态码、错误信息、数据内容。这样Agent能清楚地知道调用是成功还是失败失败的原因是什么。幂等性保证。对于写操作比如创建工单、发送邮件要保证幂等性。Agent可能会因为超时或者重试而重复调用同一个工具如果没有幂等性保证就会产生重复数据。超时和重试策略。每个工具调用都要设置超时时间超时后要有明确的重试策略。重试次数不宜过多一般2到3次就够了再多可能说明问题不在网络层面。4.3 记忆管理短期记忆和长期记忆的分工Agent的记忆管理是个容易被低估的问题。短期记忆当前会话的上下文和长期记忆跨会话的知识积累需要分开处理。短期记忆的关键是上下文压缩。随着对话轮次增加上下文会越来越长最终超出模型窗口。我的做法是保留最近几轮的完整对话更早的对话用摘要代替。摘要的生成可以用一个轻量模型来做成本低且不影响主流程。长期记忆的关键是写入和检索策略。不是所有信息都值得记住需要有选择地写入。我一般会设置一些触发条件用户明确说记住这个、某个事实被多次提及、某个偏好被反复确认。写入之后检索时要能快速找到相关的记忆片段这又回到了RAG的那套逻辑。4.4 人机协作该放手时放手该介入时介入企业级Agent不可能完全自主运行必须设计人机协作机制。关键是要明确哪些决策Agent可以自己做哪些需要人工确认哪些必须人工处理。我的经验是分三档低风险操作比如查询信息、生成草稿Agent自主执行中风险操作比如发送邮件、修改数据Agent执行前需要人工确认高风险操作比如删除数据、涉及资金的操作必须人工执行Agent只提供建议。这个分档不是固定的需要根据业务场景调整。但核心原则是Agent的能力边界要清晰用户要知道什么时候该信任它什么时候该接管。5. 成本与延迟企业级LLM的工程优化实战5.1 Token成本的精算与控制LLM的成本主要来自token消耗。输入token和输出token的价格通常不一样输出一般更贵。所以控制成本要从两头入手。输入侧的控制策略包括精简prompt去掉不必要的说明和示例、压缩上下文用摘要代替原文、缓存常用结果比如系统提示词和固定知识片段。输出侧的控制策略包括限制输出长度在prompt里明确要求简洁回答、结构化输出用JSON格式减少冗余文字、流式输出虽然不直接省钱但能改善用户体验。我做过一个粗略的测算一个中等规模的LLM应用如果每天处理1万次请求每次请求平均消耗2000个输入token和500个输出token按主流模型的价格一个月的成本大概在几千到几万块之间。这个数字看起来不大但如果请求量翻十倍或者模型换成更贵的版本成本就会迅速上升。所以从项目第一天起就要有成本意识把token消耗纳入监控指标。5.2 延迟优化的几个实用手段延迟是用户体验的直接杀手。LLM应用的延迟主要来自三部分检索延迟、模型推理延迟、网络传输延迟。检索延迟的优化手段包括索引预加载把常用索引加载到内存、并行检索多路召回同时进行、结果缓存对高频query缓存检索结果。模型推理延迟的优化手段包括流式输出让用户先看到部分结果、模型蒸馏用更小的模型处理简单任务、批处理把多个请求合并成一个批次。网络传输延迟的优化手段包括就近部署把服务部署在离用户近的区域、连接复用避免频繁建立新连接。这些手段里我觉得性价比最高的是流式输出和模型分级。流式输出能让用户感知到的延迟大幅降低模型分级能让简单任务走轻量模型复杂任务才走大模型整体延迟和成本都能降下来。5.3 缓存策略什么该缓存什么不该缓存缓存是降低成本和延迟的利器但不是所有东西都适合缓存。我一般会把缓存分成三类确定性缓存对于完全相同的输入直接返回缓存结果。适合FAQ类问题、固定格式的查询。缓存key就是输入的hash简单有效。语义缓存对于语义相似但不完全相同的输入返回缓存结果。这需要用一个向量模型来判断相似度实现复杂度高一些但命中率也更高。适合用户表达方式多样但意图相同的场景。部分缓存对于检索结果、系统提示词、固定知识片段可以缓存中间结果避免重复计算。这类缓存不直接返回给用户而是在流程中复用。注意缓存要有过期策略。业务数据在变缓存太久会导致答案过时。我一般设置几小时到一天的过期时间具体根据数据更新频率来定。5.4 模型分级路由的落地方法模型分级路由的核心思想是不是所有请求都需要最强的模型。简单任务用轻量模型复杂任务用大模型这样能在保证效果的前提下降低成本。实现分级路由的关键是任务复杂度判断。我一般用几个信号来判断输入长度、问题类型、历史对话轮次、用户等级。比如短问题、FAQ类问题走轻量模型长文本分析、多步推理走大模型VIP用户优先走大模型。分级路由的难点在于效果监控。你需要确保轻量模型处理的任务质量达标不然省了成本但丢了体验。我的做法是对轻量模型处理的请求做抽样评估如果发现质量下降就调整路由策略把更多任务分配给大模型。6. 安全与合规企业级LLM不可逾越的底线6.1 输入输出的安全过滤企业级LLM必须有一套完整的安全过滤机制覆盖输入和输出两端。输入侧要过滤的是恶意prompt注入、敏感信息查询、违规内容请求。输出侧要过滤的是敏感信息泄露、不当内容生成、事实性错误。实现方式通常是规则引擎模型审核双层过滤。规则引擎处理明确的违规模式比如关键词匹配、正则表达式。模型审核处理更隐蔽的违规内容比如隐晦的诱导、变相的敏感信息套取。两层过滤各有侧重组合使用效果更好。6.2 数据隐私与权限控制企业数据往往涉及商业机密和个人信息LLM应用必须做好数据隔离和权限控制。核心原则是用户只能访问自己有权访问的数据。实现上检索阶段就要做权限过滤。每个文档块都要打上权限标签检索时根据用户身份过滤掉无权访问的内容。生成阶段也要做检查确保输出内容不包含用户无权查看的信息。另外和外部模型API交互时要注意数据传输安全。敏感数据要么脱敏后再发送要么走私有化部署的模型。这个选择取决于数据的敏感程度和合规要求。6.3 可观测性与审计日志生产环境的LLM应用必须有完善的可观测性。我一般会记录这几类信息请求日志输入、输出、耗时、token消耗、检索日志召回了哪些文档、相关性分数、工具调用日志调用了什么工具、参数是什么、返回结果如何、错误日志什么错误、在哪个环节、影响范围。这些日志不仅用于排查问题也是审计的依据。万一出现数据泄露或者违规输出能通过日志追溯原因。日志的保留时间根据合规要求来定一般至少保留几个月。6.4 合规红线与应对策略不同行业对LLM应用的合规要求不一样。金融、医疗、法律这些强监管行业要求会更严格。通用的合规红线包括不能生成违法违规内容、不能泄露用户隐私、不能提供专业领域的确切建议除非有资质。应对策略上我建议从项目初期就把合规纳入设计。具体做法包括内容审核前置在生成阶段就过滤违规内容、免责声明明确告知用户AI生成内容的局限性、人工兜底关键场景保留人工审核环节、定期审计定期检查系统输出是否符合合规要求。7. 一些踩坑之后的个人体会做企业级LLM这几年最大的体会是技术选型不是最重要的工程能力才是。模型会迭代框架会更新但一套好的工程实践是能沉淀下来的。评测体系、监控告警、容错机制、成本控制这些东西看起来不酷但它们是应用能活下去的基础。另一个体会是不要追求一步到位。我见过太多团队想一开始就搭一个完美的系统结果迟迟上不了线。更好的做法是先跑通最小闭环然后根据线上反馈持续迭代。第一版可能只有基础的RAG第二版加上评测和监控第三版优化成本和延迟第四版完善安全和合规。每一步都有明确的改进目标而不是一开始就追求大而全。最后一个建议多和业务方沟通。技术团队容易陷入技术细节忘了业务真正需要什么。我定期会和业务方过一遍bad case听听他们的反馈往往能发现一些技术指标看不出来的问题。LLM应用最终是要解决业务问题的技术只是手段。