1. 企业级 LLM 落地为什么“能跑通 Demo”和“能上生产”之间隔着一整条鸿沟做过 LLM 项目的人大概都有这种体验本地拿个开源模型接上 LangChain写个 RAG 问答半天就能跑出一个看起来像模像样的 Demo。可一旦要把这套东西搬到企业环境里面对几十个业务部门、上百个并发用户、一堆合规审计要求之前那套“能跑就行”的代码瞬间就崩了。企业级 LLM 和实验室里的 LLM 完全是两码事前者要解决的核心问题不是“模型能不能回答”而是“回答得稳不稳、快不快、准不准、管不管得住、花不花得起”。我前后参与过几个从零到一的企业级 LLM 平台搭建踩过的坑从模型选型一路延伸到网关限流、Token 计费、知识库权限隔离、Agent 工具调用的幂等性。这个系列写到第九篇我打算把之前散落在各篇里的工程细节收拢一下重点聊企业级场景下那些“Demo 阶段根本不会遇到、生产阶段天天遇到”的问题。如果你正在负责公司内部的 LLM 平台建设或者准备把某个 RAG 应用推给真实用户使用这篇内容应该能帮你少走至少三个月的弯路。先明确一下“企业级 LLM”在我这里的定义它不是指某个具体的大模型而是指一套围绕 LLM 构建的、能满足企业生产要求的完整技术栈。这套栈至少包含模型服务层、网关层、知识库层、Agent 编排层、可观测层和成本管控层。任何一层缺失系统都会在某个时刻以你意想不到的方式出问题。下面我按实际落地顺序把这六层里最关键的工程决策和实操细节拆开讲。2. 模型服务层企业级场景下模型选型的五个硬指标2.1 为什么“榜单排名”在企业选型里几乎没用Open LLM Leaderboard 这类公开榜单我每周都会看但说实话它对企业选型的参考价值非常有限。榜单测的是 MMLU、GSM8K 这类学术基准而企业真实场景里跑的是“从一份 80 页的合同里抽出甲方违约责任条款并对比三个版本差异”这种任务。学术分数高的模型在长文档结构化抽取上未必比一个中等规模但经过针对性微调的模型强。我自己的选型流程是这样的先根据业务场景列出 5 到 10 个真实任务每个任务准备 20 到 50 条测试样本然后拿候选模型跑一遍看准确率、延迟、Token 消耗三个指标。这个过程大概需要两天但能避免后面几个月的返工。榜单只用来做初筛把明显不合适的模型排除掉比如参数量太小导致中文理解能力不足的或者上下文窗口不够处理长文档的。2.2 显存、并发与量化三个必须一起算的账企业级部署绕不开显存计算。一个 70B 参数的模型FP16 精度下光权重就要占 140GB 左右加上 KV Cache 和中间激活值单卡 80GB 的 A100 至少需要两张才能跑起来。如果业务要求并发 50 路每路上下文 8KKV Cache 的显存占用会迅速吃掉剩余空间。这时候要么上更多卡要么用量化。量化方案我实测下来INT8 量化对大多数抽取和分类任务的影响在可接受范围内精度损失大概 1 到 3 个百分点但显存直接减半。INT4 量化就要谨慎了生成类任务容易出现重复和逻辑断裂尤其是中文长文本生成。我的建议是抽取、分类、路由这类判别式任务可以用 INT4生成和推理类任务至少保持 INT8关键业务用 FP16。并发能力的估算有个粗略公式单卡吞吐量 ≈ (显存总量 - 模型权重占用) / (单请求 KV Cache 占用 × 平均并发数)。以 2×A100 80GB 跑 70B INT8 为例权重约 70GB剩余 90GB 给 KV Cache8K 上下文单请求约 1.2GB理论上能支撑 70 路左右并发。但实际还要留 20% 余量给激活值和碎片所以标称 50 路并发是比较稳妥的。2.3 推理框架选型vLLM、TGI 还是 TensorRT-LLM这三个框架我都用过简单说结论vLLM 的 PagedAttention 对变长请求的吞吐优化最好社区活跃部署简单适合大多数企业场景TGI 对 HuggingFace 生态兼容性最好但吞吐略逊TensorRT-LLM 性能最强但编译和调优成本高适合有专门推理优化团队的大厂。vLLM 的部署命令大概长这样python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-72B-Instruct-AWQ \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --max-num-seqs 64 \ --quantization awq这里--gpu-memory-utilization 0.90是关键参数默认 0.9 已经比较激进如果发现 OOM 就降到 0.85。--max-num-seqs控制同时处理的请求数设太高会导致 KV Cache 频繁换入换出反而降低吞吐。我一般从 32 开始压测逐步加到 64 或 128找到吞吐拐点。注意vLLM 启动时会预分配显存如果和其他服务共享 GPU一定要用--gpu-memory-utilization限制否则会把整张卡吃满导致其他进程崩溃。3. LLM 网关层企业级流量的统一入口与管控中枢3.1 网关到底要解决什么问题很多人觉得网关就是个反向代理把请求转发到后端模型服务就行。但在企业环境里网关承担的责任远不止转发。它要处理认证鉴权、限流熔断、Token 计量、请求路由、敏感词过滤、日志审计、多模型适配这一整套事情。没有网关每个业务应用都要自己实现这些逻辑重复造轮子不说安全策略还无法统一。我见过最典型的事故是某个业务团队直接调用模型服务的内网地址绕过了网关的限流结果一个批量任务把 GPU 打满导致其他所有业务线的 LLM 功能全部超时。所以企业级部署的第一条铁律是模型服务只对网关暴露任何业务应用不得直连。3.2 多模型路由策略按任务类型分发企业里通常不会只用一个模型。便宜的小模型处理简单分类和路由贵的大模型处理复杂推理和生成这是最基本的成本优化手段。网关需要支持按请求内容或元数据路由到不同后端。路由策略我一般配三层第一层按model字段显式指定业务方明确知道自己要用哪个模型第二层按任务类型自动路由比如请求里带task: classification就走小模型第三层是兜底默认走主力模型。这样既给了业务方灵活性又能在他们不指定时自动做成本优化。3.3 Token 计量与成本分摊财务最关心的一层企业级 LLM 平台如果不对 Token 做计量月底财务找过来问“这个月 AI 花了多少钱、哪个部门用的”你答不上来就很尴尬。Token 计量要在网关层做因为只有网关能看到完整的请求和响应。计量逻辑不复杂请求进来时用 tokenizer 算 prompt tokens响应返回时算 completion tokens然后按模型单价乘出费用打上部门、应用、用户三个维度的标签写入时序数据库。这里有个坑流式响应的 completion tokens 需要在流结束时统计不能边流边算否则会重复计数。另外不同模型的 tokenizer 不一样网关要维护一个 tokenizer 映射表按模型名加载对应的 tokenizer。成本分摊表大概长这样维度示例值用途部门风控部部门成本核算应用合同审核助手应用级成本分析用户zhangsan个人用量查询模型qwen-72b模型成本对比任务类型extraction场景成本优化3.4 限流与熔断保护后端不被冲垮限流策略要分两个维度按用户/应用的 QPS 限流和按全局 Token 消耗速率的限流。前者防止单个应用占用过多资源后者防止整体成本失控。我一般给每个应用配一个 Token 预算比如每分钟 10 万 Token超了就返回 429 并提示稍后重试。熔断则是当后端模型服务响应时间超过阈值或错误率超过阈值时网关自动切断流量并返回降级响应。降级响应可以是一个缓存的标准答案或者提示用户“当前服务繁忙”。这个机制在模型服务重启或升级时特别有用能避免大量请求堆积导致雪崩。4. 知识库与 RAG企业级知识管理的核心工程4.1 为什么企业知识库不是“把文档塞进向量库”这么简单RAG 的 Demo 版本确实简单文档切块、embedding、存向量库、检索、拼 prompt。但企业级知识库要处理的问题复杂得多。首先是权限不同部门的文档不能互相看见检索时必须带上权限过滤。其次是版本同一份制度文档有 2023 版和 2024 版检索时要优先返回最新版。再次是结构化表格、流程图、附件这些非纯文本内容怎么处理。最后是更新文档改了之后向量库怎么增量同步。我踩过最大的坑是权限过滤。早期版本忘了在检索时加权限条件结果测试时用 A 部门的账号搜出了 B 部门的薪酬文档虽然只是测试环境但足以说明问题的严重性。后来我们在向量库的 metadata 里强制写入dept_id和acl字段检索时用 filter 表达式做前置过滤确保不会召回无权限的文档。4.2 文档切块策略按语义切还是按固定长度切固定长度切块比如 512 token实现简单但会把一个完整的段落或表格切断导致检索到的片段语义不完整。语义切块用 NLP 方法识别段落、标题、列表边界切出来的块更完整但实现复杂且依赖文档格式。我的折中方案是对 Markdown 和 HTML 这类有明确结构的文档用语义切块按标题层级切对 PDF 和 Word 这类格式先用解析工具转成 Markdown再走语义切块对纯文本用固定长度加重叠窗口重叠 20% 左右保证边界信息不丢失。切块大小我一般控制在 300 到 800 token 之间太小检索精度高但上下文不足太大检索精度下降但上下文完整。4.3 混合检索向量检索加关键词检索才是企业级标配纯向量检索在语义相似度上表现好但对专有名词、产品型号、人名这类精确匹配的场景容易漏召回。企业知识库里大量存在“XX-2024-001 号文件”这种精确标识纯向量检索经常找不到。所以企业级 RAG 必须上混合检索向量检索负责语义召回BM25 负责关键词召回然后用 RRFReciprocal Rank Fusion融合两路结果。RRF 的公式很简单score Σ 1/(k rank_i)k 一般取 60。两路检索各返回 top 50融合后取 top 10 送给 LLM。实测下来混合检索比纯向量检索在专有名词查询上的召回率能提升 30% 以上。4.4 GraphRAG 与 LLM Wiki知识组织的进阶玩法最近 GraphRAG 和 LLM Wiki 这两个概念很热。GraphRAG 的核心思路是把文档里的实体和关系抽出来构建知识图谱检索时同时走图谱和向量两条路。LLM Wiki 则是用 LLM 自动把零散文档整理成结构化的 Wiki 页面每个页面有明确的主题和交叉引用。我在一个内部技术文档场景试过 GraphRAG效果确实比纯 RAG 好尤其是需要跨文档推理的问题比如“A 系统的接口变更会影响哪些下游服务”。但构建图谱的成本不低实体抽取和关系抽取都要调 LLM一个 1000 篇文档的库大概要花几十万 Token 的处理费用。所以我的建议是核心知识库值得上 GraphRAG边缘知识库用混合检索就够了。5. Agent 编排层从“问答”到“办事”的关键一跃5.1 企业级 Agent 和 Demo Agent 的本质区别Demo Agent 通常是“给 LLM 几个工具让它自己决定调哪个”。企业级 Agent 要考虑的问题多得多工具调用的权限控制、调用的幂等性、失败重试、超时处理、人工审批节点、调用链追踪。我见过一个 Agent 因为工具调用没有做幂等重试时重复提交了两次工单虽然最后人工发现并撤销了但这种问题在生产环境是绝对不能接受的。企业级 Agent 的编排我一般用状态机而不是纯 ReAct。状态机的好处是每一步的输入输出都明确容易做校验和审计。比如一个报销审批 Agent状态机定义“解析申请→校验预算→校验合规→主管审批→财务审批→打款”六个状态每个状态之间的转移条件明确LLM 只在需要理解自然语言的地方介入其他环节用确定性代码处理。5.2 工具调用的三个安全原则第一最小权限。Agent 能调用的工具列表要按业务场景配置不能给一个通用 Agent 开放所有工具。第二参数校验。LLM 生成的工具参数必须经过 schema 校验类型不对、范围不对的直接拒绝。第三敏感操作二次确认。涉及资金、权限变更、数据删除的操作必须有人工确认环节不能全自动执行。5.3 Agent 的可观测性调用链追踪怎么做Agent 的执行链路比普通 API 调用长得多一个请求可能经过 LLM 推理、工具调用、再推理、再调用来回五六轮。没有调用链追踪出了问题根本不知道是哪一步卡住了。我的做法是在网关层生成一个 trace_id贯穿整个 Agent 执行过程每一步的输入输出、耗时、Token 消耗都记录到追踪系统里。追踪数据我一般保留 30 天热数据存 Elasticsearch 方便查询冷数据归档到对象存储。查询界面支持按 trace_id、用户、应用、时间段检索能快速定位到具体是哪一步出了问题。6. 可观测与成本管控让 LLM 平台“花得明白、跑得放心”6.1 四个必须监控的核心指标企业级 LLM 平台的监控指标不用多但四个核心指标必须有请求成功率、P99 延迟、Token 消耗速率、缓存命中率。成功率低于 99% 就要告警P99 延迟超过 5 秒要排查Token 消耗速率突增要查是不是有异常调用缓存命中率下降要检查缓存策略。缓存这块我单独说一下。LLM 的缓存分两种精确缓存和语义缓存。精确缓存就是相同的 prompt 直接返回缓存结果实现简单但命中率低。语义缓存是把 prompt 做 embedding相似度超过阈值就返回缓存结果命中率高但有误命中风险。企业场景里对准确性要求高的任务用精确缓存对客服问答这类容错率高的场景可以用语义缓存。6.2 成本优化的五个实操手段第一prompt 压缩。把冗余的 system prompt 精简把 few-shot 示例从 5 个减到 2 个能省不少 Token。第二模型分级。简单任务用小模型复杂任务用大模型。第三缓存。高频问题走缓存。第四批处理。非实时任务攒批处理提高 GPU 利用率。第五输出长度限制。在 prompt 里明确要求“回答不超过 200 字”避免模型长篇大论。我实测过一个客服场景用这五个手段组合优化后月度 Token 成本从 1.2 万降到 4000 左右降幅超过 60%而用户满意度基本没变化。6.3 常见问题速查表问题现象可能原因排查方向解决方案响应突然变慢GPU 显存不足导致 KV Cache 换出查看 GPU 显存和利用率降低并发数或升级显卡回答质量下降检索召回不准或 prompt 被截断检查检索结果和 prompt 长度调整切块策略或增大上下文窗口Token 消耗异常某应用循环调用或 prompt 膨胀按应用维度查 Token 消耗限流或修复调用逻辑工具调用失败参数 schema 不匹配或权限不足查看工具调用日志修正 schema 或补充权限缓存命中率低缓存 key 设计不合理分析缓存 key 分布改用语义缓存或调整 key 策略7. 一些踩坑之后的个人体会企业级 LLM 平台的建设技术选型只占三成剩下七成是工程规范和运维体系。我见过太多团队在模型选型上纠结几周却在权限隔离、成本计量、调用链追踪这些“不性感”的事情上偷懒结果上线后问题频出。如果让我给正在起步的团队一个建议我会说先把网关和可观测性做好再考虑上多复杂的 Agent 和 RAG。网关是流量的入口可观测性是问题的出口这两个做好了后面的迭代才有基础。模型可以换框架可以换但这两个基础设施一旦缺位每次换东西都是一次事故。另外企业级场景里“稳定”比“先进”重要得多。一个新出的框架再酷如果社区不活跃、文档不完善、出了问题没人能帮你排查就不要用在核心链路上。我自己的原则是核心链路只用经过至少一年生产验证的技术新东西先在边缘场景试。最后分享一个很小但很实用的技巧给每个 LLM 请求打上业务标签比如bizcontract_review、bizcustomer_service。这个标签在排查问题、分析成本、做容量规划时特别有用而且实现成本几乎为零。很多团队等到出问题才想起来要加标签那时候历史数据已经丢了只能从头再来。
企业级LLM平台落地实战：从Demo到生产的六层架构与工程避坑指南
1. 企业级 LLM 落地为什么“能跑通 Demo”和“能上生产”之间隔着一整条鸿沟做过 LLM 项目的人大概都有这种体验本地拿个开源模型接上 LangChain写个 RAG 问答半天就能跑出一个看起来像模像样的 Demo。可一旦要把这套东西搬到企业环境里面对几十个业务部门、上百个并发用户、一堆合规审计要求之前那套“能跑就行”的代码瞬间就崩了。企业级 LLM 和实验室里的 LLM 完全是两码事前者要解决的核心问题不是“模型能不能回答”而是“回答得稳不稳、快不快、准不准、管不管得住、花不花得起”。我前后参与过几个从零到一的企业级 LLM 平台搭建踩过的坑从模型选型一路延伸到网关限流、Token 计费、知识库权限隔离、Agent 工具调用的幂等性。这个系列写到第九篇我打算把之前散落在各篇里的工程细节收拢一下重点聊企业级场景下那些“Demo 阶段根本不会遇到、生产阶段天天遇到”的问题。如果你正在负责公司内部的 LLM 平台建设或者准备把某个 RAG 应用推给真实用户使用这篇内容应该能帮你少走至少三个月的弯路。先明确一下“企业级 LLM”在我这里的定义它不是指某个具体的大模型而是指一套围绕 LLM 构建的、能满足企业生产要求的完整技术栈。这套栈至少包含模型服务层、网关层、知识库层、Agent 编排层、可观测层和成本管控层。任何一层缺失系统都会在某个时刻以你意想不到的方式出问题。下面我按实际落地顺序把这六层里最关键的工程决策和实操细节拆开讲。2. 模型服务层企业级场景下模型选型的五个硬指标2.1 为什么“榜单排名”在企业选型里几乎没用Open LLM Leaderboard 这类公开榜单我每周都会看但说实话它对企业选型的参考价值非常有限。榜单测的是 MMLU、GSM8K 这类学术基准而企业真实场景里跑的是“从一份 80 页的合同里抽出甲方违约责任条款并对比三个版本差异”这种任务。学术分数高的模型在长文档结构化抽取上未必比一个中等规模但经过针对性微调的模型强。我自己的选型流程是这样的先根据业务场景列出 5 到 10 个真实任务每个任务准备 20 到 50 条测试样本然后拿候选模型跑一遍看准确率、延迟、Token 消耗三个指标。这个过程大概需要两天但能避免后面几个月的返工。榜单只用来做初筛把明显不合适的模型排除掉比如参数量太小导致中文理解能力不足的或者上下文窗口不够处理长文档的。2.2 显存、并发与量化三个必须一起算的账企业级部署绕不开显存计算。一个 70B 参数的模型FP16 精度下光权重就要占 140GB 左右加上 KV Cache 和中间激活值单卡 80GB 的 A100 至少需要两张才能跑起来。如果业务要求并发 50 路每路上下文 8KKV Cache 的显存占用会迅速吃掉剩余空间。这时候要么上更多卡要么用量化。量化方案我实测下来INT8 量化对大多数抽取和分类任务的影响在可接受范围内精度损失大概 1 到 3 个百分点但显存直接减半。INT4 量化就要谨慎了生成类任务容易出现重复和逻辑断裂尤其是中文长文本生成。我的建议是抽取、分类、路由这类判别式任务可以用 INT4生成和推理类任务至少保持 INT8关键业务用 FP16。并发能力的估算有个粗略公式单卡吞吐量 ≈ (显存总量 - 模型权重占用) / (单请求 KV Cache 占用 × 平均并发数)。以 2×A100 80GB 跑 70B INT8 为例权重约 70GB剩余 90GB 给 KV Cache8K 上下文单请求约 1.2GB理论上能支撑 70 路左右并发。但实际还要留 20% 余量给激活值和碎片所以标称 50 路并发是比较稳妥的。2.3 推理框架选型vLLM、TGI 还是 TensorRT-LLM这三个框架我都用过简单说结论vLLM 的 PagedAttention 对变长请求的吞吐优化最好社区活跃部署简单适合大多数企业场景TGI 对 HuggingFace 生态兼容性最好但吞吐略逊TensorRT-LLM 性能最强但编译和调优成本高适合有专门推理优化团队的大厂。vLLM 的部署命令大概长这样python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-72B-Instruct-AWQ \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --max-num-seqs 64 \ --quantization awq这里--gpu-memory-utilization 0.90是关键参数默认 0.9 已经比较激进如果发现 OOM 就降到 0.85。--max-num-seqs控制同时处理的请求数设太高会导致 KV Cache 频繁换入换出反而降低吞吐。我一般从 32 开始压测逐步加到 64 或 128找到吞吐拐点。注意vLLM 启动时会预分配显存如果和其他服务共享 GPU一定要用--gpu-memory-utilization限制否则会把整张卡吃满导致其他进程崩溃。3. LLM 网关层企业级流量的统一入口与管控中枢3.1 网关到底要解决什么问题很多人觉得网关就是个反向代理把请求转发到后端模型服务就行。但在企业环境里网关承担的责任远不止转发。它要处理认证鉴权、限流熔断、Token 计量、请求路由、敏感词过滤、日志审计、多模型适配这一整套事情。没有网关每个业务应用都要自己实现这些逻辑重复造轮子不说安全策略还无法统一。我见过最典型的事故是某个业务团队直接调用模型服务的内网地址绕过了网关的限流结果一个批量任务把 GPU 打满导致其他所有业务线的 LLM 功能全部超时。所以企业级部署的第一条铁律是模型服务只对网关暴露任何业务应用不得直连。3.2 多模型路由策略按任务类型分发企业里通常不会只用一个模型。便宜的小模型处理简单分类和路由贵的大模型处理复杂推理和生成这是最基本的成本优化手段。网关需要支持按请求内容或元数据路由到不同后端。路由策略我一般配三层第一层按model字段显式指定业务方明确知道自己要用哪个模型第二层按任务类型自动路由比如请求里带task: classification就走小模型第三层是兜底默认走主力模型。这样既给了业务方灵活性又能在他们不指定时自动做成本优化。3.3 Token 计量与成本分摊财务最关心的一层企业级 LLM 平台如果不对 Token 做计量月底财务找过来问“这个月 AI 花了多少钱、哪个部门用的”你答不上来就很尴尬。Token 计量要在网关层做因为只有网关能看到完整的请求和响应。计量逻辑不复杂请求进来时用 tokenizer 算 prompt tokens响应返回时算 completion tokens然后按模型单价乘出费用打上部门、应用、用户三个维度的标签写入时序数据库。这里有个坑流式响应的 completion tokens 需要在流结束时统计不能边流边算否则会重复计数。另外不同模型的 tokenizer 不一样网关要维护一个 tokenizer 映射表按模型名加载对应的 tokenizer。成本分摊表大概长这样维度示例值用途部门风控部部门成本核算应用合同审核助手应用级成本分析用户zhangsan个人用量查询模型qwen-72b模型成本对比任务类型extraction场景成本优化3.4 限流与熔断保护后端不被冲垮限流策略要分两个维度按用户/应用的 QPS 限流和按全局 Token 消耗速率的限流。前者防止单个应用占用过多资源后者防止整体成本失控。我一般给每个应用配一个 Token 预算比如每分钟 10 万 Token超了就返回 429 并提示稍后重试。熔断则是当后端模型服务响应时间超过阈值或错误率超过阈值时网关自动切断流量并返回降级响应。降级响应可以是一个缓存的标准答案或者提示用户“当前服务繁忙”。这个机制在模型服务重启或升级时特别有用能避免大量请求堆积导致雪崩。4. 知识库与 RAG企业级知识管理的核心工程4.1 为什么企业知识库不是“把文档塞进向量库”这么简单RAG 的 Demo 版本确实简单文档切块、embedding、存向量库、检索、拼 prompt。但企业级知识库要处理的问题复杂得多。首先是权限不同部门的文档不能互相看见检索时必须带上权限过滤。其次是版本同一份制度文档有 2023 版和 2024 版检索时要优先返回最新版。再次是结构化表格、流程图、附件这些非纯文本内容怎么处理。最后是更新文档改了之后向量库怎么增量同步。我踩过最大的坑是权限过滤。早期版本忘了在检索时加权限条件结果测试时用 A 部门的账号搜出了 B 部门的薪酬文档虽然只是测试环境但足以说明问题的严重性。后来我们在向量库的 metadata 里强制写入dept_id和acl字段检索时用 filter 表达式做前置过滤确保不会召回无权限的文档。4.2 文档切块策略按语义切还是按固定长度切固定长度切块比如 512 token实现简单但会把一个完整的段落或表格切断导致检索到的片段语义不完整。语义切块用 NLP 方法识别段落、标题、列表边界切出来的块更完整但实现复杂且依赖文档格式。我的折中方案是对 Markdown 和 HTML 这类有明确结构的文档用语义切块按标题层级切对 PDF 和 Word 这类格式先用解析工具转成 Markdown再走语义切块对纯文本用固定长度加重叠窗口重叠 20% 左右保证边界信息不丢失。切块大小我一般控制在 300 到 800 token 之间太小检索精度高但上下文不足太大检索精度下降但上下文完整。4.3 混合检索向量检索加关键词检索才是企业级标配纯向量检索在语义相似度上表现好但对专有名词、产品型号、人名这类精确匹配的场景容易漏召回。企业知识库里大量存在“XX-2024-001 号文件”这种精确标识纯向量检索经常找不到。所以企业级 RAG 必须上混合检索向量检索负责语义召回BM25 负责关键词召回然后用 RRFReciprocal Rank Fusion融合两路结果。RRF 的公式很简单score Σ 1/(k rank_i)k 一般取 60。两路检索各返回 top 50融合后取 top 10 送给 LLM。实测下来混合检索比纯向量检索在专有名词查询上的召回率能提升 30% 以上。4.4 GraphRAG 与 LLM Wiki知识组织的进阶玩法最近 GraphRAG 和 LLM Wiki 这两个概念很热。GraphRAG 的核心思路是把文档里的实体和关系抽出来构建知识图谱检索时同时走图谱和向量两条路。LLM Wiki 则是用 LLM 自动把零散文档整理成结构化的 Wiki 页面每个页面有明确的主题和交叉引用。我在一个内部技术文档场景试过 GraphRAG效果确实比纯 RAG 好尤其是需要跨文档推理的问题比如“A 系统的接口变更会影响哪些下游服务”。但构建图谱的成本不低实体抽取和关系抽取都要调 LLM一个 1000 篇文档的库大概要花几十万 Token 的处理费用。所以我的建议是核心知识库值得上 GraphRAG边缘知识库用混合检索就够了。5. Agent 编排层从“问答”到“办事”的关键一跃5.1 企业级 Agent 和 Demo Agent 的本质区别Demo Agent 通常是“给 LLM 几个工具让它自己决定调哪个”。企业级 Agent 要考虑的问题多得多工具调用的权限控制、调用的幂等性、失败重试、超时处理、人工审批节点、调用链追踪。我见过一个 Agent 因为工具调用没有做幂等重试时重复提交了两次工单虽然最后人工发现并撤销了但这种问题在生产环境是绝对不能接受的。企业级 Agent 的编排我一般用状态机而不是纯 ReAct。状态机的好处是每一步的输入输出都明确容易做校验和审计。比如一个报销审批 Agent状态机定义“解析申请→校验预算→校验合规→主管审批→财务审批→打款”六个状态每个状态之间的转移条件明确LLM 只在需要理解自然语言的地方介入其他环节用确定性代码处理。5.2 工具调用的三个安全原则第一最小权限。Agent 能调用的工具列表要按业务场景配置不能给一个通用 Agent 开放所有工具。第二参数校验。LLM 生成的工具参数必须经过 schema 校验类型不对、范围不对的直接拒绝。第三敏感操作二次确认。涉及资金、权限变更、数据删除的操作必须有人工确认环节不能全自动执行。5.3 Agent 的可观测性调用链追踪怎么做Agent 的执行链路比普通 API 调用长得多一个请求可能经过 LLM 推理、工具调用、再推理、再调用来回五六轮。没有调用链追踪出了问题根本不知道是哪一步卡住了。我的做法是在网关层生成一个 trace_id贯穿整个 Agent 执行过程每一步的输入输出、耗时、Token 消耗都记录到追踪系统里。追踪数据我一般保留 30 天热数据存 Elasticsearch 方便查询冷数据归档到对象存储。查询界面支持按 trace_id、用户、应用、时间段检索能快速定位到具体是哪一步出了问题。6. 可观测与成本管控让 LLM 平台“花得明白、跑得放心”6.1 四个必须监控的核心指标企业级 LLM 平台的监控指标不用多但四个核心指标必须有请求成功率、P99 延迟、Token 消耗速率、缓存命中率。成功率低于 99% 就要告警P99 延迟超过 5 秒要排查Token 消耗速率突增要查是不是有异常调用缓存命中率下降要检查缓存策略。缓存这块我单独说一下。LLM 的缓存分两种精确缓存和语义缓存。精确缓存就是相同的 prompt 直接返回缓存结果实现简单但命中率低。语义缓存是把 prompt 做 embedding相似度超过阈值就返回缓存结果命中率高但有误命中风险。企业场景里对准确性要求高的任务用精确缓存对客服问答这类容错率高的场景可以用语义缓存。6.2 成本优化的五个实操手段第一prompt 压缩。把冗余的 system prompt 精简把 few-shot 示例从 5 个减到 2 个能省不少 Token。第二模型分级。简单任务用小模型复杂任务用大模型。第三缓存。高频问题走缓存。第四批处理。非实时任务攒批处理提高 GPU 利用率。第五输出长度限制。在 prompt 里明确要求“回答不超过 200 字”避免模型长篇大论。我实测过一个客服场景用这五个手段组合优化后月度 Token 成本从 1.2 万降到 4000 左右降幅超过 60%而用户满意度基本没变化。6.3 常见问题速查表问题现象可能原因排查方向解决方案响应突然变慢GPU 显存不足导致 KV Cache 换出查看 GPU 显存和利用率降低并发数或升级显卡回答质量下降检索召回不准或 prompt 被截断检查检索结果和 prompt 长度调整切块策略或增大上下文窗口Token 消耗异常某应用循环调用或 prompt 膨胀按应用维度查 Token 消耗限流或修复调用逻辑工具调用失败参数 schema 不匹配或权限不足查看工具调用日志修正 schema 或补充权限缓存命中率低缓存 key 设计不合理分析缓存 key 分布改用语义缓存或调整 key 策略7. 一些踩坑之后的个人体会企业级 LLM 平台的建设技术选型只占三成剩下七成是工程规范和运维体系。我见过太多团队在模型选型上纠结几周却在权限隔离、成本计量、调用链追踪这些“不性感”的事情上偷懒结果上线后问题频出。如果让我给正在起步的团队一个建议我会说先把网关和可观测性做好再考虑上多复杂的 Agent 和 RAG。网关是流量的入口可观测性是问题的出口这两个做好了后面的迭代才有基础。模型可以换框架可以换但这两个基础设施一旦缺位每次换东西都是一次事故。另外企业级场景里“稳定”比“先进”重要得多。一个新出的框架再酷如果社区不活跃、文档不完善、出了问题没人能帮你排查就不要用在核心链路上。我自己的原则是核心链路只用经过至少一年生产验证的技术新东西先在边缘场景试。最后分享一个很小但很实用的技巧给每个 LLM 请求打上业务标签比如bizcontract_review、bizcustomer_service。这个标签在排查问题、分析成本、做容量规划时特别有用而且实现成本几乎为零。很多团队等到出问题才想起来要加标签那时候历史数据已经丢了只能从头再来。
