尧图网页设计 
企业级LLM这个系列写到第四篇。前三篇已经把模型选型、Prompt工程和基础架构串过一遍今天这篇不打算再讲概念专门聊落地时真正会卡住你的四件事RAG知识库怎么做扎实、LLM网关怎么收口、Agent编排怎么选平台、推理部署这笔账怎么算。写这篇的起因是这半年帮几个团队做技术评审发现大家最后都卡在同一个地方——模型早就接好了但业务跑不起来。这篇就是把那些“接好了却跑不起来”背后的工程问题摊开来讲适合正在做企业级LLM落地的架构师、后端工程师以及需要评估投入产出的技术决策者。1. 先把RAG这块硬骨头啃下来从向量库到知识工程1.1 为什么朴素RAG在企业里一定会翻车很多人都搭过最简单的RAG把文档切块、embedding、存向量库、检索、拼Prompt、喂给LLM。说实话做个Demo给我半天时间就够了。但这个东西一进企业环境基本上撑不过一周就会露馅。第一个坑是知识更新。企业知识库是活文档合同模板会改、产品手册会迭代、技术规范每年更新。朴素RAG没有版本概念向量库里旧版内容还在新文档也进来了用户问一个问题检索模块经常同时捞出两个版本的答案。模型这时候可不会客气它会把两个版本的内容都编进回答里于是法务部看到了过期条款销售部看到了已经作废的价格表。我在实际项目中见过不止一次因为RAG引用过时文档引发的投诉这东西一出就是事故级的问题。第二个坑是权限隔离。企业知识库里文档天然分密级财务数据、人事政策、客户合同、内部技术文档各有各的访问边界。向量检索是全局性的如果检索前不做权限过滤任何能打开问答机器人的员工都可以通过一些问法把不该看到的内容套出来。我见过一个团队把合同全文向量化后开放给全员问答结果第三天上线第二天法务就找上门了。直白说企业级RAG的权限控制必须在检索阶段就生效而不是靠LLM在生成阶段自行判断“能不能说”模型没有这个判断能力。第三个坑是召回精度。很多人以为embedding相似度就等于语义正确实际上向量检索对精确数字、型号、编号这类信息非常不敏感。用户问“XC-2000型设备的维护周期”文档里写的是“XC2000”两个字符串在语义上完全一致但token切分方式不同向量表示就可能差距很大。这种场景下纯向量检索的召回质量会低到让你怀疑人生。所以我的结论很明确朴素RAG只是玩具企业级RAG是一项知识工程要解决版本管理、权限过滤、检索质量三件事缺一不可。1.2 GraphRAG和本体RAG到底解决什么问题近两年GraphRAG这个概念很火本体RAG也开始被频繁提起。但很多团队是看到别人用就跟着上结果成本和复杂度都翻倍了。我先把这两个东西的适用边界说清楚。GraphRAG解决的是“跨文档的关联理解”问题。企业里的很多问题不是单点知识而是多实体、多关系的交叉查询比如“我们跟A供应商还有多少未结清的合同”“哪些客户的合同即将到期且金额超过100万”。这种问题落在朴素RAG上检索回来的是一堆零散片段模型很难拼出完整答案。GraphRAG的做法是用LLM从文档里抽取实体和关系构建知识图谱再用社区检测等算法生成社区摘要回答这类全局性问题时优势非常明显。但GraphRAG的成本也要说清楚。建图过程要用LLM对每篇文档做实体识别和关系抽取token消耗是肉眼可见的快。我做过一个测试大概两千页文档建图光抽取这一步就烧掉了几百万token。如果知识资产本身值钱、关系复杂度高这笔账划得来如果只是一个内部FAQ库就别碰GraphRAG了。本体RAG解决的是“领域约束”问题。本体的本质是一套schema规定领域里有哪些实体、哪些属性、实体之间允许哪些关系。你可以把它理解成给知识库建表结构——先定好骨架再灌数据。比如制造业里工序、设备、工单、物料之间的关系是明确的用本体约束后RAG不会出现“工序当设备”“工单当物料”这种离谱错配。对规则性强、格式固定的行业本体RAG的价值远大于堆更多的向量。我的建议很务实先用朴素RAG跑起来认真分析坏case集中在哪。坏case集中在实体关系说不清的上GraphRAG坏case集中在格式和约束容易违反的上本体RAG两者都不是的先优化检索质量别急着追新技术。1.3 一套能落地的知识库入库链路企业级RAG的入库流程我总结下来就是六步源文档清洗、结构化解析、语义切分、向量化、元数据标注、检索验证。源文档清洗这一步很多人会跳过结果就是向量库里塞了一堆页眉页脚、目录、水印之类的垃圾信息。PDF和Word的解析不能只靠开源库一把梭表格、多栏排版、扫描件都要单独处理。我的做法是清洗阶段就把无效内容剔除掉宁可少一点也不要脏数据进库。切分是整个链路里最容易被低估的一环。直接按固定字符数硬切是最省事也是最差的做法因为语义会被拦腰截断。我习惯先按文档结构切一级标题、二级标题、段落层级先识别出来以结构块为单位切超过长度的块再按递归切分处理。chunk大小一般控制在256到512个token之间重叠率10%到20%这个区间在召回效果和检索成本之间比较平衡。embedding模型选型不要只看榜单分数。开源模型里bge-m3在中文场景表现不错m3e也还行商用模型的上限更高但要考虑数据出域问题。最靠谱的做法是拿业务真实的问答对各跑一遍看召回命中率榜单分数和地方赛跑完全是两回事。检索端我强烈推荐混合检索BM25全文检索和向量检索双路召回用RRF方式合并排序再加一个reranker模型做精排。为什么因为企业用户的输入里经常夹着精确的型号、单号、人名这类模式向量检索天然不擅长BM25反而很稳。重排模型在前几十条召回结果里做精排虽然会多花几十毫秒但回答质量的提升是肉眼可见的。最后强调元数据和引用溯源。每篇文档入库时都要记录来源、版本、负责人、更新日期每个回答都要能点进原文段落。企业级RAG和玩具RAG的分水岭就是这一条——没有引用溯源你连回答对不对都不敢确认。2. LLM网关让所有模型流量从一条道走2.1 网关在企业里的职责边界很多团队把模型API直接暴露给内部系统各家自己管理密钥、自己记录用量、自己对接厂商看起来灵活实际上后患无穷。企业在模型流量上的诉求其实和API流量高度一致需要一个统一收口的地方这就是LLM网关。LLM网关的职责边界我通常划成六块统一入口、模型路由、密钥管理、限流与熔断、审计日志、成本统计。统一入口解决的是接入标准化问题。所有系统只认网关一个地址不管背后是开源模型、云厂商还是自部署模型对业务方来说都是同一个API。模型路由解决的是流量分发问题常见策略有按场景路由、按成本路由、按优先级故障切换。比如内部低风险问答走便宜的模型核心客服场景走高精度模型主模型挂了自动切到备用的。我个人经验是网关的逻辑一定要先做日志再做限流。你连哪个服务调了哪个模型、返回了什么都不知道限流规则根本无从设计。我见过一个团队线上出问题排查了整两天最后发现是某个内部系统在循环调用模型接口账单烧掉了几万块就是因为日志没提前做事后连数据都补不回来。2.2 密钥、路由与成本核算密钥管理这块最简单的原则是供应商API Key绝不落到前端和各个业务系统里。业务方只拿网关分配的clientId网关内部做密钥映射和加密存储。企业里如果部门多、项目多还要做按项目授权和密钥轮换机制。有些商业产品会提供“共享密钥”这类开箱即用的能力自研也不难核心是三件事加密存储、按项目授权、定期轮换。成本核算是我强烈建议第一天就做的功能。LLM调用不是按QPS计费的是按token计费的而token消耗和业务参与度直接相关。网关应该把每次调用的token数、模型、项目归属完整记录下来形成按部门、按项目的成本看板。企业管理者几乎都会问“上个月大模型花了多少钱”网关就是这个数字的唯一权威来源。这地方数据可视化也是刚需一张清晰的成本趋势图能帮你挡掉很多来自财务的追问。我曾经在处理一个成本异常时发现某个测试环境的token消耗是正式环境的五倍。查了半天原因是开发同学写了一个重试逻辑接口失败后无限循环调用网关侧没有设熔断直到账单出来才被发现。这个教训很简单限流和熔断不是防外部攻击用的防的是内部犯错。2.3 一个典型报错的完整排查实录前阵子线上环境遇到一个报错信息很直接“llm request failed: provider rejected the request schema or tool payload.”。一句话翻译就是模型供应商拒绝了我们的请求理由是schema或者tool payload不对。排查过程走了不少弯路这里直接给结论。第一步先确认报错来源是网关超时还是供应商主动拒绝。从网关返回的status code和错误内容看是供应商侧拒绝。第二步是拉出请求日志把发给供应商的完整请求体拿出来和供应商最新的schema要求做对比。第三步是最容易忽略的——网关对工具定义做了缓存而工具定义刚更新过。根因很简单团队给一个查询工具新增了可选参数但网关侧缓存的还是旧schema新参数的类型声明有误模型按旧定义生成了payload供应商校验直接拒绝。修复方案也不复杂更新工具后清掉网关缓存同时通知开发同学所有工具变更必须走网关发布接口发布前网关自动做一次schema校验校验不过就拦截并返回具体报错信息不给供应商拒绝的机会。这个报错背后其实是通用的经验tool payload不匹配的高发原因是参数类型不匹配比如模型把字符串填进了数字字段或者漏了必填参数。在网关层对工具参数做严格的类型校验和强制转换能拦截掉大部分这类问题不用每次都去改Prompt。3. Agent编排与自动化从n8n到企业级平台3.1 n8n企业级部署的完整方案n8n是开源的可视化工作流编排工具很适合企业内部把LLM能力和现有系统串起来比如飞书审批流触发模型分析、数据库变更后自动调用Agent生成报告。部署本身不难但企业级部署有几个关键点很容易被人忽略。我推荐的部署模式是Docker Compose三件套n8n主服务加PostgreSQL加Redis。PostgreSQL存工作流和所有执行记录Redis承担任务队列。关键的环境变量有几个EXECUTIONS_MODE必须设为queue这样任务执行会交给worker主进程只负责调度否则单进程跑大批量任务基本必挂N8N_ENCRYPTION_KEY必须显式设置并持久保存这个密钥一旦丢失或变更工作流里所有的连接凭证都会解密失败全部要重配DB_TYPE设为postgresdb并把PostgreSQL连接信息配好。在生产环境我习惯把n8n拆成三类进程分别扩容webhook进程负责接收外部触发器worker进程负责执行工作流主调度进程负责管理和分发。只跑一个n8n容器做所有事短期没问题一旦任务量上来队列堆积和内存增长会同时爆发。实测下来worker复制到4个副本处理大批量文档任务的吞吐基本够用了。最后一条忠告n8n适合做胶水层不适合承载复杂业务逻辑。我早期把一个多轮对话状态机整个画在n8n里几十个节点交叉连线后期维护成本高到想重构。现在的原则是n8n里只放清晰的线性编排复杂逻辑一律下沉到独立微服务通过HTTP节点调用。能画得让人一眼看懂的流程是好的画出来没人能看懂的流程迟早要还债。3.2 设计Agent工具的三个关键词key、query、value设计Agent工具时有一个思路非常受用llm的token三个点——key我是谁、query我在找什么、value我能提供什么。放在Agent工具调用里这三件事完全对应。工具定义告诉模型“我是谁”对应工具的name和description。请求参数是“我在找什么”对应JSON Schema定义的输入。工具执行后返回的结果是“我能提供的价值”对应结构化的输出。一个Agent系统能否稳定运行很大程度上取决于工具定义是否把这三个点讲清楚了。描述怎么写很关键。糟糕的写法是“查询订单”好的写法是“当用户提供订单号或手机号时查询订单状态如果用户没有提供任何标识请先向用户询问订单号不要自行猜测订单号”。这样一来模型触发工具的条件和边界都清晰了误调用的概率大幅下降。参数声明方面能用枚举值就不用自由字符串所有字段尽量声明类型必填和可选区分清楚模型在生成参数时才有据可依。返回值也一样宁可多花点力气整理成结构化JSON也不要让模型去解析大段自由文本。有意思的是这个key、query、value的思维和Transformer内部的注意力机制本质上是相通的Query是“我在找什么”Key是“我的身份标签”Value是“我能贡献的内容”。理解了这个底层逻辑你做工具设计、写Function Calling定义的时候整个思路都会顺很多。3.3 企业级Agent平台怎么选现在市面上的Agent平台大致分三层。底层是LangGraph这类可以完全掌控的编排框架中间是Dify、FastGPT、MaxKB这类开源平台开箱即用还能私有化上层是商业化的一站式Agent平台通常自带模型接入、工具市场和多维监控。选型的时候最忌讳的是“看哪个火选哪个”关键要对照自己的场景做切分。我评估企业级Agent平台主要看四个维度权限模型、可观测性、工具扩展能力、私有化程度。权限模型要能支持到部门级和角色级否则Agent能力一放开越权风险兜不住。可观测性要看能不能看到每次调用的完整链路——从用户问题到工具调用到最终回答以及每一步的token成本。工具扩展能力决定你能不能快速把内部系统接进来如果接一个内部API要等平台厂商排期这个平台在内部推广基本就凉了。私有化程度更直接很多企业对数据出域是有硬性要求的部署形态决定了能不能过合规那一关。行业里这几年的趋势很明显企业级data agent平台在向“统一”收敛统一的工具注册中心、统一的会话管理、统一的审计体系。我的经验是选型不要追求功能最多的要追求最稳的。一个能快速接入、权限清晰、日志完整的平台比一个功能强大但什么都定制不了的黑盒靠谱得多。4. 推理部署与成本账本地化不是唯一答案4.1 部署方式先把三个问题问清楚很多团队一提企业级LLM第一反应就是“必须私有化部署数据不能出去”。这个想法不能说错但容易走极端。部署方式不是拍脑袋定的先问三个问题数据能不能出域峰值并发是多少预算规模是多少数据敏感度决定了能不能用公有云API或托管模型。峰值并发决定了该准备多大的推理资源。预算决定了是采购显卡常驻部署还是按量弹性使用。这三个问题没有标准答案同一个企业里不同业务线的答案都可能不一样。我的通常做法是混合部署把对数据安全要求最高的RAG检索和工具调用完全放在内部模型调用部分评估后选择私有化推理或托管API同时在模型调用前做一层脱敏。这样做既守住了敏感数据又不用在每一条业务上都养一套GPU集群。4.2 ONNX部署模型的适用边界ONNX Runtime是个好东西但它不是万能的。企业里常见的边缘场景比如工位机、巡检一体机、没有GPU的办公网络想在本地跑一个小模型做文本分类、信息抽取或简答ONNX是合理的选型。把LLM用optimum导出成ONNX格式配合INT8甚至INT4量化在纯CPU环境也能获得可用的推理速度。我实际做过一个项目给工厂部署巡检一体机设备上没有GPU用的是ONNX Runtime跑量化后的7B模型处理一段语音质检文本大概三秒完全够用。这种场景去上vLLM反而不合适因为vLLM的设计目标是大吞吐高并发在单机低并发的边缘环境优势发挥不出来。但反过来如果是中心机房的高并发在线服务就不要试图用ONNX Runtime撑着了。同等级推理任务vLLM的PagedAttention、Continuous Batching这些专项优化换来的是数倍的吞吐提升。选型逻辑一句话边缘设备用ONNX或llama.cpp中心高并发用vLLM或TensorRT-LLM两边各干各的活。4.3 算力估算与Java业务系统集成模式推理资源估算其实有一个很简单的粗算公式模型权重显存约为参数量乘以精度字节数。FP16是2字节INT8是1字节INT4是0.5字节。拿7B模型举例FP16加载大约需要14GB显存INT4量化大约4GB。换成70B模型FP16大约140GB已经不是单卡能解决的量级了。但权重显存只是基础别忘了KV cache。KV cache的粗算方法是batch数量乘以序列长度乘以层数乘以注意力头维度贡献的字节数。简单估算的话一个7B模型在1024 token上下文、10并发请求、FP16精度下KV cache大约要占5GB左右。这也是为什么24GB显存的单卡跑7B模型看上去够实际并发一上来就会OOM。显存不是看模型能不能加载而是看并发扛不扛得住。集成模式这块企业里很大一部分后端是Java生态比如很多内部管理系统基于若依这类框架开发而AI服务基本是Python的天下。我的建议是Java和Python不搞Deep Integration各走各的Java侧负责业务权限、流程编排、页面展示Python侧负责模型推理、RAG检索、Agent执行两边通过HTTP或gRPC对接。长耗时任务千万别同步等Java侧把任务丢进消息队列Python worker消费完成后再回写状态前端轮询结果。这样Python服务出问题不会阻塞主流程两边也能各自独立扩容。我用过一个对比表格直接列出来参考部署方式适用场景优点注意点托管API数据可出域、快速上线零运维、模型升级方便成本逐月累积、需要评估数据合规私有化推理vLLM等数据敏感、高并发数据不出内网、完全可控要养GPU、需要优化经验边缘部署ONNX等离线/一体机/低功耗设备可用、延迟低、数据绝对本地模型规模受限、量化有精度损失混合部署大多数企业兼顾成本与安全架构复杂依赖网关统一路由5. 高频故障与排查技巧一张速查表5.1 高频故障速查表这几年做企业级LLM项目遇到的故障翻来覆去就那几类。整理成一张速查表大家可以CtrlF对着查现象根因处理方案RAG回答引用过时内容知识库没有版本管理入库时记录版本检索按更新时间过滤RAG答非所问切分不合理上下文丢失按文档结构切分加混合检索重排Agent工具调用参数错误工具schema定义不清网关层做schema校验和类型转换n8n执行任务堆积主进程单点执行未开queue模式配置EXECUTIONS_MODEqueue增加worker副本模型供应商限流业务突发或者有循环调用网关加熔断、重试、备用模型降级llm request rejected工具schema缓存过期或payload类型不匹配刷新schema缓存网关统一发布工具定义某项目token成本突增缺少成本维度统计网关按项目维度记录token设置预算告警本地模型推理OOM只看了权重显存没算KV cache按KV cache粗算公式重新评估并发上限5.2 几条用真金白银换来的经验第一条经验先让业务方定义“不能接受的坏回答”再谈准确率。很多团队一上来就跟业务方对齐准确率指标但双方对“准确”的定义往往完全是两回事。把坏回答明确下来比如“不能答非所问”“不能引用过期合同”“不能虚构客户名称”RAG和Agent的优化才有靶子。第二条经验可观测性永远排在性能前面。LLM系统是黑盒中的黑盒没有日志、没有trace、没有token计量任何问题排查都在裸奔。网关的审计日志、Agent的调用链追踪、RAG的检索日志这些第一天就该做好而不是上线之后再补。第三条经验先通后优别贪大。很多团队一上来就规划GraphRAG加Agent平台加大模型微调三个月过去连基础RAG的引用溯源都没做利索。先把一个最小场景打通让业务部门真正用起来再根据痛点逐项升级这是最稳妥的路径。第四条经验安全底线提前划。权限、审计、脱敏、恶意输入防护这些不应该等技术方案定型后再讨论。企业级LLM一旦涉足生产环境安全问题就是第一时间就要有的东西上线后再补安全代价会翻很多倍。最后再分享一点个人的体会文章写到这里我的一点核心感受是企业级LLM这几年真正卡人的不是模型能力而是工程体系。项目能不能落地看的是RAG做得多扎实、网关多可靠、Agent编排多清晰、推理成本算得过来算不过来。如果你正在搭或者准备搭这套体系我的建议是把这四件事单独立项推进别混在一个大项目里做。每一件事都有独立的评估指标和交付物混在一起最后往往哪个都做不透。像这个系列的标题写到的企业级LLM是一场持久战。模型会越来越强但工程问题不会自动消失。我之后会接着写第五篇重点拆解Agent在生产环境中的稳定性设计和评测方法——如果你在这个过程中也有自己踩过的坑带着具体的业务场景来交流比空聊模型排名要有用得多。 企业级LLM落地指南：RAG知识库、LLM网关、Agent编排与推理成本全解析
企业级LLM这个系列写到第四篇。前三篇已经把模型选型、Prompt工程和基础架构串过一遍今天这篇不打算再讲概念专门聊落地时真正会卡住你的四件事RAG知识库怎么做扎实、LLM网关怎么收口、Agent编排怎么选平台、推理部署这笔账怎么算。写这篇的起因是这半年帮几个团队做技术评审发现大家最后都卡在同一个地方——模型早就接好了但业务跑不起来。这篇就是把那些“接好了却跑不起来”背后的工程问题摊开来讲适合正在做企业级LLM落地的架构师、后端工程师以及需要评估投入产出的技术决策者。1. 先把RAG这块硬骨头啃下来从向量库到知识工程1.1 为什么朴素RAG在企业里一定会翻车很多人都搭过最简单的RAG把文档切块、embedding、存向量库、检索、拼Prompt、喂给LLM。说实话做个Demo给我半天时间就够了。但这个东西一进企业环境基本上撑不过一周就会露馅。第一个坑是知识更新。企业知识库是活文档合同模板会改、产品手册会迭代、技术规范每年更新。朴素RAG没有版本概念向量库里旧版内容还在新文档也进来了用户问一个问题检索模块经常同时捞出两个版本的答案。模型这时候可不会客气它会把两个版本的内容都编进回答里于是法务部看到了过期条款销售部看到了已经作废的价格表。我在实际项目中见过不止一次因为RAG引用过时文档引发的投诉这东西一出就是事故级的问题。第二个坑是权限隔离。企业知识库里文档天然分密级财务数据、人事政策、客户合同、内部技术文档各有各的访问边界。向量检索是全局性的如果检索前不做权限过滤任何能打开问答机器人的员工都可以通过一些问法把不该看到的内容套出来。我见过一个团队把合同全文向量化后开放给全员问答结果第三天上线第二天法务就找上门了。直白说企业级RAG的权限控制必须在检索阶段就生效而不是靠LLM在生成阶段自行判断“能不能说”模型没有这个判断能力。第三个坑是召回精度。很多人以为embedding相似度就等于语义正确实际上向量检索对精确数字、型号、编号这类信息非常不敏感。用户问“XC-2000型设备的维护周期”文档里写的是“XC2000”两个字符串在语义上完全一致但token切分方式不同向量表示就可能差距很大。这种场景下纯向量检索的召回质量会低到让你怀疑人生。所以我的结论很明确朴素RAG只是玩具企业级RAG是一项知识工程要解决版本管理、权限过滤、检索质量三件事缺一不可。1.2 GraphRAG和本体RAG到底解决什么问题近两年GraphRAG这个概念很火本体RAG也开始被频繁提起。但很多团队是看到别人用就跟着上结果成本和复杂度都翻倍了。我先把这两个东西的适用边界说清楚。GraphRAG解决的是“跨文档的关联理解”问题。企业里的很多问题不是单点知识而是多实体、多关系的交叉查询比如“我们跟A供应商还有多少未结清的合同”“哪些客户的合同即将到期且金额超过100万”。这种问题落在朴素RAG上检索回来的是一堆零散片段模型很难拼出完整答案。GraphRAG的做法是用LLM从文档里抽取实体和关系构建知识图谱再用社区检测等算法生成社区摘要回答这类全局性问题时优势非常明显。但GraphRAG的成本也要说清楚。建图过程要用LLM对每篇文档做实体识别和关系抽取token消耗是肉眼可见的快。我做过一个测试大概两千页文档建图光抽取这一步就烧掉了几百万token。如果知识资产本身值钱、关系复杂度高这笔账划得来如果只是一个内部FAQ库就别碰GraphRAG了。本体RAG解决的是“领域约束”问题。本体的本质是一套schema规定领域里有哪些实体、哪些属性、实体之间允许哪些关系。你可以把它理解成给知识库建表结构——先定好骨架再灌数据。比如制造业里工序、设备、工单、物料之间的关系是明确的用本体约束后RAG不会出现“工序当设备”“工单当物料”这种离谱错配。对规则性强、格式固定的行业本体RAG的价值远大于堆更多的向量。我的建议很务实先用朴素RAG跑起来认真分析坏case集中在哪。坏case集中在实体关系说不清的上GraphRAG坏case集中在格式和约束容易违反的上本体RAG两者都不是的先优化检索质量别急着追新技术。1.3 一套能落地的知识库入库链路企业级RAG的入库流程我总结下来就是六步源文档清洗、结构化解析、语义切分、向量化、元数据标注、检索验证。源文档清洗这一步很多人会跳过结果就是向量库里塞了一堆页眉页脚、目录、水印之类的垃圾信息。PDF和Word的解析不能只靠开源库一把梭表格、多栏排版、扫描件都要单独处理。我的做法是清洗阶段就把无效内容剔除掉宁可少一点也不要脏数据进库。切分是整个链路里最容易被低估的一环。直接按固定字符数硬切是最省事也是最差的做法因为语义会被拦腰截断。我习惯先按文档结构切一级标题、二级标题、段落层级先识别出来以结构块为单位切超过长度的块再按递归切分处理。chunk大小一般控制在256到512个token之间重叠率10%到20%这个区间在召回效果和检索成本之间比较平衡。embedding模型选型不要只看榜单分数。开源模型里bge-m3在中文场景表现不错m3e也还行商用模型的上限更高但要考虑数据出域问题。最靠谱的做法是拿业务真实的问答对各跑一遍看召回命中率榜单分数和地方赛跑完全是两回事。检索端我强烈推荐混合检索BM25全文检索和向量检索双路召回用RRF方式合并排序再加一个reranker模型做精排。为什么因为企业用户的输入里经常夹着精确的型号、单号、人名这类模式向量检索天然不擅长BM25反而很稳。重排模型在前几十条召回结果里做精排虽然会多花几十毫秒但回答质量的提升是肉眼可见的。最后强调元数据和引用溯源。每篇文档入库时都要记录来源、版本、负责人、更新日期每个回答都要能点进原文段落。企业级RAG和玩具RAG的分水岭就是这一条——没有引用溯源你连回答对不对都不敢确认。2. LLM网关让所有模型流量从一条道走2.1 网关在企业里的职责边界很多团队把模型API直接暴露给内部系统各家自己管理密钥、自己记录用量、自己对接厂商看起来灵活实际上后患无穷。企业在模型流量上的诉求其实和API流量高度一致需要一个统一收口的地方这就是LLM网关。LLM网关的职责边界我通常划成六块统一入口、模型路由、密钥管理、限流与熔断、审计日志、成本统计。统一入口解决的是接入标准化问题。所有系统只认网关一个地址不管背后是开源模型、云厂商还是自部署模型对业务方来说都是同一个API。模型路由解决的是流量分发问题常见策略有按场景路由、按成本路由、按优先级故障切换。比如内部低风险问答走便宜的模型核心客服场景走高精度模型主模型挂了自动切到备用的。我个人经验是网关的逻辑一定要先做日志再做限流。你连哪个服务调了哪个模型、返回了什么都不知道限流规则根本无从设计。我见过一个团队线上出问题排查了整两天最后发现是某个内部系统在循环调用模型接口账单烧掉了几万块就是因为日志没提前做事后连数据都补不回来。2.2 密钥、路由与成本核算密钥管理这块最简单的原则是供应商API Key绝不落到前端和各个业务系统里。业务方只拿网关分配的clientId网关内部做密钥映射和加密存储。企业里如果部门多、项目多还要做按项目授权和密钥轮换机制。有些商业产品会提供“共享密钥”这类开箱即用的能力自研也不难核心是三件事加密存储、按项目授权、定期轮换。成本核算是我强烈建议第一天就做的功能。LLM调用不是按QPS计费的是按token计费的而token消耗和业务参与度直接相关。网关应该把每次调用的token数、模型、项目归属完整记录下来形成按部门、按项目的成本看板。企业管理者几乎都会问“上个月大模型花了多少钱”网关就是这个数字的唯一权威来源。这地方数据可视化也是刚需一张清晰的成本趋势图能帮你挡掉很多来自财务的追问。我曾经在处理一个成本异常时发现某个测试环境的token消耗是正式环境的五倍。查了半天原因是开发同学写了一个重试逻辑接口失败后无限循环调用网关侧没有设熔断直到账单出来才被发现。这个教训很简单限流和熔断不是防外部攻击用的防的是内部犯错。2.3 一个典型报错的完整排查实录前阵子线上环境遇到一个报错信息很直接“llm request failed: provider rejected the request schema or tool payload.”。一句话翻译就是模型供应商拒绝了我们的请求理由是schema或者tool payload不对。排查过程走了不少弯路这里直接给结论。第一步先确认报错来源是网关超时还是供应商主动拒绝。从网关返回的status code和错误内容看是供应商侧拒绝。第二步是拉出请求日志把发给供应商的完整请求体拿出来和供应商最新的schema要求做对比。第三步是最容易忽略的——网关对工具定义做了缓存而工具定义刚更新过。根因很简单团队给一个查询工具新增了可选参数但网关侧缓存的还是旧schema新参数的类型声明有误模型按旧定义生成了payload供应商校验直接拒绝。修复方案也不复杂更新工具后清掉网关缓存同时通知开发同学所有工具变更必须走网关发布接口发布前网关自动做一次schema校验校验不过就拦截并返回具体报错信息不给供应商拒绝的机会。这个报错背后其实是通用的经验tool payload不匹配的高发原因是参数类型不匹配比如模型把字符串填进了数字字段或者漏了必填参数。在网关层对工具参数做严格的类型校验和强制转换能拦截掉大部分这类问题不用每次都去改Prompt。3. Agent编排与自动化从n8n到企业级平台3.1 n8n企业级部署的完整方案n8n是开源的可视化工作流编排工具很适合企业内部把LLM能力和现有系统串起来比如飞书审批流触发模型分析、数据库变更后自动调用Agent生成报告。部署本身不难但企业级部署有几个关键点很容易被人忽略。我推荐的部署模式是Docker Compose三件套n8n主服务加PostgreSQL加Redis。PostgreSQL存工作流和所有执行记录Redis承担任务队列。关键的环境变量有几个EXECUTIONS_MODE必须设为queue这样任务执行会交给worker主进程只负责调度否则单进程跑大批量任务基本必挂N8N_ENCRYPTION_KEY必须显式设置并持久保存这个密钥一旦丢失或变更工作流里所有的连接凭证都会解密失败全部要重配DB_TYPE设为postgresdb并把PostgreSQL连接信息配好。在生产环境我习惯把n8n拆成三类进程分别扩容webhook进程负责接收外部触发器worker进程负责执行工作流主调度进程负责管理和分发。只跑一个n8n容器做所有事短期没问题一旦任务量上来队列堆积和内存增长会同时爆发。实测下来worker复制到4个副本处理大批量文档任务的吞吐基本够用了。最后一条忠告n8n适合做胶水层不适合承载复杂业务逻辑。我早期把一个多轮对话状态机整个画在n8n里几十个节点交叉连线后期维护成本高到想重构。现在的原则是n8n里只放清晰的线性编排复杂逻辑一律下沉到独立微服务通过HTTP节点调用。能画得让人一眼看懂的流程是好的画出来没人能看懂的流程迟早要还债。3.2 设计Agent工具的三个关键词key、query、value设计Agent工具时有一个思路非常受用llm的token三个点——key我是谁、query我在找什么、value我能提供什么。放在Agent工具调用里这三件事完全对应。工具定义告诉模型“我是谁”对应工具的name和description。请求参数是“我在找什么”对应JSON Schema定义的输入。工具执行后返回的结果是“我能提供的价值”对应结构化的输出。一个Agent系统能否稳定运行很大程度上取决于工具定义是否把这三个点讲清楚了。描述怎么写很关键。糟糕的写法是“查询订单”好的写法是“当用户提供订单号或手机号时查询订单状态如果用户没有提供任何标识请先向用户询问订单号不要自行猜测订单号”。这样一来模型触发工具的条件和边界都清晰了误调用的概率大幅下降。参数声明方面能用枚举值就不用自由字符串所有字段尽量声明类型必填和可选区分清楚模型在生成参数时才有据可依。返回值也一样宁可多花点力气整理成结构化JSON也不要让模型去解析大段自由文本。有意思的是这个key、query、value的思维和Transformer内部的注意力机制本质上是相通的Query是“我在找什么”Key是“我的身份标签”Value是“我能贡献的内容”。理解了这个底层逻辑你做工具设计、写Function Calling定义的时候整个思路都会顺很多。3.3 企业级Agent平台怎么选现在市面上的Agent平台大致分三层。底层是LangGraph这类可以完全掌控的编排框架中间是Dify、FastGPT、MaxKB这类开源平台开箱即用还能私有化上层是商业化的一站式Agent平台通常自带模型接入、工具市场和多维监控。选型的时候最忌讳的是“看哪个火选哪个”关键要对照自己的场景做切分。我评估企业级Agent平台主要看四个维度权限模型、可观测性、工具扩展能力、私有化程度。权限模型要能支持到部门级和角色级否则Agent能力一放开越权风险兜不住。可观测性要看能不能看到每次调用的完整链路——从用户问题到工具调用到最终回答以及每一步的token成本。工具扩展能力决定你能不能快速把内部系统接进来如果接一个内部API要等平台厂商排期这个平台在内部推广基本就凉了。私有化程度更直接很多企业对数据出域是有硬性要求的部署形态决定了能不能过合规那一关。行业里这几年的趋势很明显企业级data agent平台在向“统一”收敛统一的工具注册中心、统一的会话管理、统一的审计体系。我的经验是选型不要追求功能最多的要追求最稳的。一个能快速接入、权限清晰、日志完整的平台比一个功能强大但什么都定制不了的黑盒靠谱得多。4. 推理部署与成本账本地化不是唯一答案4.1 部署方式先把三个问题问清楚很多团队一提企业级LLM第一反应就是“必须私有化部署数据不能出去”。这个想法不能说错但容易走极端。部署方式不是拍脑袋定的先问三个问题数据能不能出域峰值并发是多少预算规模是多少数据敏感度决定了能不能用公有云API或托管模型。峰值并发决定了该准备多大的推理资源。预算决定了是采购显卡常驻部署还是按量弹性使用。这三个问题没有标准答案同一个企业里不同业务线的答案都可能不一样。我的通常做法是混合部署把对数据安全要求最高的RAG检索和工具调用完全放在内部模型调用部分评估后选择私有化推理或托管API同时在模型调用前做一层脱敏。这样做既守住了敏感数据又不用在每一条业务上都养一套GPU集群。4.2 ONNX部署模型的适用边界ONNX Runtime是个好东西但它不是万能的。企业里常见的边缘场景比如工位机、巡检一体机、没有GPU的办公网络想在本地跑一个小模型做文本分类、信息抽取或简答ONNX是合理的选型。把LLM用optimum导出成ONNX格式配合INT8甚至INT4量化在纯CPU环境也能获得可用的推理速度。我实际做过一个项目给工厂部署巡检一体机设备上没有GPU用的是ONNX Runtime跑量化后的7B模型处理一段语音质检文本大概三秒完全够用。这种场景去上vLLM反而不合适因为vLLM的设计目标是大吞吐高并发在单机低并发的边缘环境优势发挥不出来。但反过来如果是中心机房的高并发在线服务就不要试图用ONNX Runtime撑着了。同等级推理任务vLLM的PagedAttention、Continuous Batching这些专项优化换来的是数倍的吞吐提升。选型逻辑一句话边缘设备用ONNX或llama.cpp中心高并发用vLLM或TensorRT-LLM两边各干各的活。4.3 算力估算与Java业务系统集成模式推理资源估算其实有一个很简单的粗算公式模型权重显存约为参数量乘以精度字节数。FP16是2字节INT8是1字节INT4是0.5字节。拿7B模型举例FP16加载大约需要14GB显存INT4量化大约4GB。换成70B模型FP16大约140GB已经不是单卡能解决的量级了。但权重显存只是基础别忘了KV cache。KV cache的粗算方法是batch数量乘以序列长度乘以层数乘以注意力头维度贡献的字节数。简单估算的话一个7B模型在1024 token上下文、10并发请求、FP16精度下KV cache大约要占5GB左右。这也是为什么24GB显存的单卡跑7B模型看上去够实际并发一上来就会OOM。显存不是看模型能不能加载而是看并发扛不扛得住。集成模式这块企业里很大一部分后端是Java生态比如很多内部管理系统基于若依这类框架开发而AI服务基本是Python的天下。我的建议是Java和Python不搞Deep Integration各走各的Java侧负责业务权限、流程编排、页面展示Python侧负责模型推理、RAG检索、Agent执行两边通过HTTP或gRPC对接。长耗时任务千万别同步等Java侧把任务丢进消息队列Python worker消费完成后再回写状态前端轮询结果。这样Python服务出问题不会阻塞主流程两边也能各自独立扩容。我用过一个对比表格直接列出来参考部署方式适用场景优点注意点托管API数据可出域、快速上线零运维、模型升级方便成本逐月累积、需要评估数据合规私有化推理vLLM等数据敏感、高并发数据不出内网、完全可控要养GPU、需要优化经验边缘部署ONNX等离线/一体机/低功耗设备可用、延迟低、数据绝对本地模型规模受限、量化有精度损失混合部署大多数企业兼顾成本与安全架构复杂依赖网关统一路由5. 高频故障与排查技巧一张速查表5.1 高频故障速查表这几年做企业级LLM项目遇到的故障翻来覆去就那几类。整理成一张速查表大家可以CtrlF对着查现象根因处理方案RAG回答引用过时内容知识库没有版本管理入库时记录版本检索按更新时间过滤RAG答非所问切分不合理上下文丢失按文档结构切分加混合检索重排Agent工具调用参数错误工具schema定义不清网关层做schema校验和类型转换n8n执行任务堆积主进程单点执行未开queue模式配置EXECUTIONS_MODEqueue增加worker副本模型供应商限流业务突发或者有循环调用网关加熔断、重试、备用模型降级llm request rejected工具schema缓存过期或payload类型不匹配刷新schema缓存网关统一发布工具定义某项目token成本突增缺少成本维度统计网关按项目维度记录token设置预算告警本地模型推理OOM只看了权重显存没算KV cache按KV cache粗算公式重新评估并发上限5.2 几条用真金白银换来的经验第一条经验先让业务方定义“不能接受的坏回答”再谈准确率。很多团队一上来就跟业务方对齐准确率指标但双方对“准确”的定义往往完全是两回事。把坏回答明确下来比如“不能答非所问”“不能引用过期合同”“不能虚构客户名称”RAG和Agent的优化才有靶子。第二条经验可观测性永远排在性能前面。LLM系统是黑盒中的黑盒没有日志、没有trace、没有token计量任何问题排查都在裸奔。网关的审计日志、Agent的调用链追踪、RAG的检索日志这些第一天就该做好而不是上线之后再补。第三条经验先通后优别贪大。很多团队一上来就规划GraphRAG加Agent平台加大模型微调三个月过去连基础RAG的引用溯源都没做利索。先把一个最小场景打通让业务部门真正用起来再根据痛点逐项升级这是最稳妥的路径。第四条经验安全底线提前划。权限、审计、脱敏、恶意输入防护这些不应该等技术方案定型后再讨论。企业级LLM一旦涉足生产环境安全问题就是第一时间就要有的东西上线后再补安全代价会翻很多倍。最后再分享一点个人的体会文章写到这里我的一点核心感受是企业级LLM这几年真正卡人的不是模型能力而是工程体系。项目能不能落地看的是RAG做得多扎实、网关多可靠、Agent编排多清晰、推理成本算得过来算不过来。如果你正在搭或者准备搭这套体系我的建议是把这四件事单独立项推进别混在一个大项目里做。每一件事都有独立的评估指标和交付物混在一起最后往往哪个都做不透。像这个系列的标题写到的企业级LLM是一场持久战。模型会越来越强但工程问题不会自动消失。我之后会接着写第五篇重点拆解Agent在生产环境中的稳定性设计和评测方法——如果你在这个过程中也有自己踩过的坑带着具体的业务场景来交流比空聊模型排名要有用得多。