1. 企业级 LLM 到底在解决什么问题

1.1 从个人玩具到生产系统的鸿沟

很多人第一次接触 LLM 都是在个人电脑上跑个 Ollama，或者调个 API 写个聊天机器人，感觉这东西挺简单。但一旦要把 LLM 塞进企业的业务流里，问题就全冒出来了：模型响应不稳定、并发一上来就崩、知识库更新滞后、权限控制形同虚设、成本像脱缰的野马。个人玩票和企业级落地之间，隔着的不是一条河，而是一整套工程体系。

我见过太多团队兴冲冲地拿开源模型搭了个 Demo，给老板演示完就准备上线，结果真实用户一进来，各种脏数据、边界问题、安全合规要求全砸过来，最后项目烂尾。企业级 LLM 的核心命题从来不是“模型能不能回答问题”，而是“能不能在可控成本、可控风险、可控延迟的前提下，稳定地解决一类业务问题”。

1.2 企业级 LLM 的四个核心支柱

把企业级 LLM 拆开来看，本质上要解决四件事：知识接入、推理编排、服务治理、效果评估。知识接入解决“模型不知道企业私域信息”的问题，推理编排解决“复杂任务怎么拆解执行”的问题，服务治理解决“高并发下怎么稳定运行”的问题，效果评估解决“怎么证明它真的有用”的问题。这四个支柱缺一不可，少了任何一个，系统都跑不远。

热词里提到的llm wiki知识库、rag graphrag llm wiki 本体rag、企业级知识库搭建其实都指向第一个支柱。而n8n企业级部署方案、企业级 agent 平台、agentscope java 2.0企业级实战则更多落在第二个支柱。llm 网关、vibex怎么创建企业级共享密钥属于第三个支柱的范畴。至于企业级数据可视化、llm驱动的公立医院债务风险智能预警这些，则是具体场景下的应用层。

1.3 谁需要关注这个系列

这个系列我打算按企业级 LLM 的落地路径来写，第一篇先把整体框架和知识接入层讲透。适合三类人看：一是正在做企业 AI 应用的技术负责人，二是想从传统后端转 AI 工程方向的开发者，三是需要评估 LLM 项目可行性的产品经理。我不会堆砌论文里的公式，也不会只给个 GitHub 链接就完事，而是把每个环节的选型逻辑、踩坑经验、参数配置都摊开来讲。

2. 知识接入层：RAG 不是万能药，但没有它万万不能

2.1 为什么微调不是企业知识注入的首选

很多老板一听 LLM 就想着微调，觉得把企业数据喂进去模型就“懂”了。这个思路在特定场景下成立，比如固定格式的文本分类、特定风格的文案生成。但用来做企业知识问答，微调有几个致命问题：知识更新成本极高，每次业务数据变了都得重新训练；容易产生幻觉，模型会把训练时见过的相似内容混淆；无法追溯来源，回答错了你都不知道它从哪学的。

RAG 的思路完全不同，它把知识存在外部，模型只负责理解和生成。知识更新就是更新数据库，回答错了可以定位到具体文档片段。热词里的llm wiki和karpathy llm wiki其实就是在讨论这种“外部知识库 + LLM”的模式。Karpathy 提的那个 wiki 概念，核心思想是把知识组织成结构化的、可检索的单元，而不是一股脑塞进模型参数里。

2.2 文档解析：最脏最累但最重要的环节

企业里的文档格式五花八门：PDF、Word、Excel、PPT、扫描件、网页、数据库导出文件。我做过一个统计，在一个中等规模的企业知识库项目里，文档解析和清洗占到了整个项目工作量的 60% 以上。很多人低估了这个环节，以为调个 LangChain 的 loader 就完事了，结果 PDF 里的表格全乱、扫描件 OCR 出来全是错别字、Excel 里的合并单元格直接丢失结构。

PDF 解析我推荐用PyMuPDF或者pdfplumber，前者速度快，后者对表格支持更好。如果是扫描件，PaddleOCR的中文识别效果目前是第一梯队。Word 文档用python-docx，但要注意样式和批注的处理。Excel 用openpyxl或pandas，合并单元格需要特殊处理，否则读出来全是 NaN。

注意：文档解析完一定要做人工抽检，至少抽 5% 的样本看看解析质量。我见过太多项目因为解析阶段埋的雷，导致后面检索效果怎么调都上不去。

2.3 分块策略：固定长度是最偷懒也最危险的做法

分块（Chunking）是 RAG 里最容易被忽视但影响巨大的环节。最简单的做法是按固定字符数切，比如每 500 字一块，重叠 50 字。这种做法在技术文档上勉强能用，但在合同、报告、论文这类结构化文本上就是灾难，经常把一句话切成两半，或者把标题和内容分离。

我的经验是按语义结构分块：先按标题层级切，再按段落切，最后才考虑按长度切。对于 Markdown 文档，直接按##和###切；对于 PDF，先用版面分析识别出章节结构；对于对话记录，按轮次切。每个块要保留足够的上下文，比如在块的开头加上所属章节的标题路径。

分块大小没有标准答案，但有个经验值：中文 300-800 字，英文 200-500 词。太小了检索时缺乏上下文，太大了检索精度下降且浪费 token。重叠部分建议 10%-20%，防止关键信息正好落在边界上。

2.4 向量化模型选型：别只看排行榜

向量化模型（Embedding Model）决定了检索的天花板。选型时不能只看 MTEB 排行榜，还要考虑：语言支持（中文场景必须选中文优化过的）、维度大小（维度越高存储和计算成本越大）、推理速度（企业级场景下吞吐量很重要）、部署方式（能不能本地部署，数据能不能出境）。

目前中文场景下，BGE系列和M3E系列是比较稳妥的选择。如果追求极致效果且预算充足，可以用OpenAI text-embedding-3-large，但要注意数据合规问题。热词里提到的onnx部署llm模型也适用于 embedding 模型，用 ONNX Runtime 推理能比原生 PyTorch 快 2-3 倍，而且资源占用更低。

提示：embedding 模型和 LLM 最好用同一家或兼容的 tokenizer，否则可能出现语义空间不匹配的问题。我实测过混用不同厂商的 embedding 和 LLM，检索出来的内容经常驴唇不对马嘴。

2.5 向量数据库：从 FAISS 到 Milvus 的选型路径

小规模场景（百万级向量以下）用 FAISS 就够了，单机部署简单，检索速度快。但企业级场景往往需要：分布式部署、实时增删改、元数据过滤、多租户隔离。这时候 FAISS 就不够用了。

主流选择有 Milvus、Qdrant、Weaviate、PGVector。Milvus 功能最全但运维复杂，Qdrant 性能好且部署简单，Weaviate 自带混合检索，PGVector 胜在能和业务数据库共用一套 PostgreSQL。我的建议是：如果团队没有专职的向量数据库运维，优先选 Qdrant 或 PGVector；如果数据量上亿且需要复杂过滤，再考虑 Milvus。

热词里的rag和llm wiki讨论的其实就是检索策略。纯向量检索有个问题：对精确匹配不敏感。比如用户问“XX 型号的额定功率是多少”，向量检索可能返回一堆语义相似但型号不对的文档。这时候需要混合检索：向量检索 + 关键词检索（BM25），再用 RRF 算法融合排序。

3. 推理编排层：Agent 不是银弹，工作流才是

3.1 从 Chain 到 Agent 的演进逻辑

最早大家用 LangChain 的 Chain 把 LLM 调用串起来，后来发现固定流程太死板，就出现了 Agent 的概念。Agent 的核心是让 LLM 自己决定下一步做什么：调用哪个工具、查哪个知识库、要不要反问用户。热词里的llm powered autonomous agents和企业级 agent 平台说的就是这个方向。

但 Agent 在企业级场景下有个大问题：不确定性太高。LLM 可能选错工具、可能陷入循环、可能生成不合规的调用参数。我见过一个 Agent 在查天气时反复调用同一个 API 十几次，就因为第一次返回的结果它“不满意”。所以企业级场景下，我倾向于工作流为主，Agent 为辅：主流程用确定性代码编排，只在需要灵活决策的节点上引入 Agent。

3.2 工具调用的参数校验与容错

LLM 生成工具调用参数时经常出错：日期格式不对、枚举值超出范围、必填字段缺失。如果直接把 LLM 的输出传给后端 API，轻则报错，重则产生脏数据。必须在中间加一层参数校验和修正。

我的做法是用 Pydantic 定义每个工具的参数 schema，LLM 输出后先做校验，校验失败就把错误信息返回给 LLM 让它重新生成，最多重试 3 次。对于日期、金额这类关键字段，再加一层正则或规则引擎做二次确认。热词里的llm request failed: provider rejected the request schema or tool payload就是典型的 schema 不匹配问题，八成是参数校验没做好。

3.3 多步推理的上下文管理

复杂任务往往需要多步推理，比如“帮我分析上季度销售数据并生成报告”。这涉及查数据库、做统计、生成图表、写文字多个步骤。每一步的输出都要作为下一步的输入，但 LLM 的上下文窗口是有限的，不能把所有中间结果都塞进去。

我的策略是分层摘要：每一步的原始输出存到外部存储，只把摘要和关键数据放进上下文。比如查数据库返回 1000 行，摘要成“共 1000 条记录，总销售额 XXX，环比增长 X%”，原始数据用 ID 引用。这样既保留了关键信息，又控制了 token 消耗。

3.4 人工介入节点的设计

企业级场景下，完全自动化的 Agent 往往不可接受，因为一旦出错就是生产事故。必须在关键节点设置人工确认。比如 Agent 要执行退款操作，必须先弹给人工审核；Agent 要发送对外邮件，必须先让人看一眼。

这个设计看起来简单，但实现起来要考虑：人工确认的界面怎么展示上下文、超时未确认怎么处理、确认后如何恢复执行流。我一般用状态机来管理整个流程，每个需要人工介入的节点都是一个状态，确认后触发状态转移。

4. 服务治理层：让 LLM 应用像传统后端一样可靠

4.1 LLM 网关：统一入口的价值

企业里往往有多个 LLM 供应商：OpenAI、Claude、国产大模型、本地部署的开源模型。如果每个业务系统都直接调各自的 API，会带来几个问题：密钥管理混乱、成本无法统一核算、限流策略各自为政、故障切换没有统一机制。LLM 网关就是解决这些问题的。

网关的核心功能包括：统一鉴权（业务系统用内部密钥，网关负责换成真实 API Key）、限流熔断（按业务线、按用户、按模型维度限流）、成本核算（记录每次调用的 token 消耗和费用）、故障转移（主模型挂了自动切备用模型）、日志审计（所有请求响应留痕）。热词里的vibex怎么创建企业级共享密钥和llm 网关说的就是这个层面的事。

开源方案里，One API和Higress的 AI 网关插件是比较成熟的选择。如果团队有自研能力，用 FastAPI 或 Spring Cloud Gateway 自己写一个也不复杂，核心就是代理转发 + 策略插件。

4.2 缓存策略：省钱又提速的关键

LLM 调用又贵又慢，但很多请求其实是重复的。比如“公司年假怎么休”这个问题，可能一天被问几十次。如果每次都调 LLM，纯属浪费。语义缓存是解决这个问题的利器：把用户问题和答案存起来，新问题来了先做向量相似度匹配，相似度超过阈值就直接返回缓存答案。

缓存粒度要设计好：太粗了容易返回过时答案，太细了命中率低。我的经验是按知识库版本 + 问题语义做缓存键，知识库更新时自动失效相关缓存。对于时效性强的查询（比如“今天股价”），直接跳过缓存。

4.3 可观测性：没有监控就是裸奔

LLM 应用的可观测性比传统后端更复杂，因为多了几个维度：token 消耗、首 token 延迟、生成速度、检索命中率、答案质量。这些指标不监控，出了问题根本不知道从哪查。

我一般用 OpenTelemetry 做链路追踪，每个请求打上 trace_id，串联起检索、LLM 调用、工具执行各个环节。指标用 Prometheus + Grafana 展示，日志用 ELK 或 Loki 收集。特别要关注P99 延迟和错误率，LLM 应用的尾延迟往往比平均值高一个数量级。

注意：LLM 的日志里可能包含用户敏感信息，存储前必须做脱敏。我见过一个项目把用户身份证号直接打进日志，后来被安全审计查出来，整个项目回滚重做。

4.4 成本控制：从被动账单到主动预算

LLM 成本失控是很多企业踩过的坑。月初预算 1 万，月底账单 5 万，老板直接叫停项目。成本控制要从几个层面入手：模型分级（简单问题用小模型，复杂问题才用大模型）、token 限制（限制单次请求的最大 token 数）、预算告警（达到预算 80% 时自动告警）、配额管理（每个业务线分配固定配额）。

模型分级我实测下来效果很明显：把意图识别、简单问答这类任务切到 7B 小模型，复杂推理才用 70B 或闭源大模型，整体成本能降 60% 以上，而用户体验几乎无感知。

5. 效果评估层：怎么证明你的 LLM 应用真的有用

5.1 离线评估：构建测试集是第一步

没有测试集就没法评估。企业级 LLM 应用的测试集要覆盖：常见问题（高频 query）、边界问题（容易出错的 query）、对抗问题（故意诱导出错的 query）、多轮对话（需要上下文理解的 query）。测试集不用很大，200-500 条就能看出问题，但必须持续维护，每次模型或知识库更新都要跑一遍。

评估指标不能只看准确率，还要看召回率（该检索到的文档有没有检索到）、忠实度（答案是否忠于检索内容）、相关性（答案是否回答了问题）。RAGAS 是目前比较成熟的评估框架，可以自动化计算这些指标。

5.2 在线评估：用户反馈是最真实的信号

离线评估再好，也不如真实用户的反馈。在线评估要收集：点赞点踩、追问率（用户追问说明第一次没答好）、转人工率（转人工说明 AI 没解决）、会话时长。这些指标要按天、按周做趋势分析，发现异常及时排查。

我一般会在答案下面加“这个回答有帮助吗”的按钮，用户点踩时弹出输入框让用户补充原因。这些反馈数据积累起来，就是优化检索和 prompt 的宝贵素材。

5.3 持续迭代：从 bad case 到优化闭环

LLM 应用没有“上线即完成”的说法，必须持续迭代。我的做法是每周做一次bad case 复盘：把用户点踩的、转人工的、追问的 case 拉出来，人工分析原因。是检索没召回？是 prompt 没写好？是模型能力不够？还是知识库本身就没有这个信息？

找到原因后针对性优化：检索问题就调分块和检索策略，prompt 问题就改 prompt 模板，模型问题就换模型或加 few-shot 示例，知识缺失就补充文档。这个闭环跑起来，效果会肉眼可见地提升。

6. 常见问题与排查技巧实录

6.1 检索到了但答案不对

这是最常见的 bad case。排查思路：先看检索到的文档片段是否真的包含答案，如果包含但 LLM 没答对，是 prompt 问题；如果不包含，是检索问题。检索问题再细分：是分块把答案切碎了？是 embedding 模型对这类问题不敏感？还是向量数据库的相似度阈值设得太高？

我遇到过一个典型案例：用户问“报销流程是什么”，检索返回的全是“报销标准”“报销时间”的文档，就是没有流程说明。后来发现流程说明在一个 PDF 的表格里，解析时表格结构丢了。重新解析后问题解决。

6.2 LLM 回答不稳定，同样的问题有时对有时错

LLM 本身有随机性，temperature参数越高越明显。企业级场景下，temperature建议设 0 或 0.1，保证输出稳定。如果设了低 temperature 还不稳定，检查是不是检索结果在变：向量数据库的索引更新可能导致相似度排序变化。

另一个原因是 prompt 里的示例顺序或措辞有细微差异。我建议把 prompt 模板固化下来，用版本管理工具管理，每次改动都记录 diff。

6.3 并发一高就超时

LLM 推理是计算密集型任务，并发能力远不如传统 Web 服务。排查方向：是 LLM 服务本身的并发限制？是网关的限流配置太严？还是检索环节拖慢了整体响应？我一般先用压测工具（如 Locust）摸清系统的吞吐上限，再根据业务峰值做容量规划。

如果用的是 API 方式调 LLM，要注意供应商的 RPM（每分钟请求数）和 TPM（每分钟 token 数）限制。超了就会返回 429 错误，需要在网关层做队列和重试。

6.4 知识库更新后答案没变

这是缓存惹的祸。检查几个地方：向量数据库的索引有没有重建？语义缓存的键有没有包含知识库版本？LLM 的 prompt 里有没有硬编码旧知识？我一般会在知识库更新后触发一个回调，自动清理相关缓存并重建索引。

还有一个隐蔽的问题：如果用了 GraphRAG 或本体 RAG，知识图谱的更新可能比向量索引更慢。热词里的llm ontology和rag graphrag llm wiki 本体rag说的就是这种更复杂的知识组织方式，更新链路更长，需要更细致的版本管理。

6.5 常见问题速查表

7. 一些踩坑后的个人体会

企业级 LLM 项目最容易犯的错误是技术驱动而非场景驱动。看到别人用 Agent 就上 Agent，看到 GraphRAG 火就上 GraphRAG，结果做出来的东西没人用。我的经验是：先从一个小而具体的场景切入，比如“内部 IT 支持问答”或“合同关键条款检索”，把 RAG 的基本链路跑通，把评估指标建起来，再逐步扩展。

另一个体会是数据质量决定上限。模型再强，检索再准，如果知识库里的文档本身就是过时的、矛盾的、错误的，输出不可能好。我见过一个项目花了大价钱买 GPU 部署大模型，结果知识库里的产品手册还是三年前的版本，用户问新功能一概不知。所以在知识接入层投入再多精力都不为过。

最后，不要追求 100% 自动化。企业级场景下，人工介入不是缺陷，而是特性。把 AI 定位成“辅助人类决策”而不是“替代人类决策”，项目的推进阻力会小很多，容错空间也大很多。我现在的做法是：AI 给出建议和依据，人来做最终判断，系统记录人的判断结果用于后续优化。这个闭环跑顺了，AI 的准确率会越来越高，人的工作量会越来越小。