一位做工业零部件的业务负责人聊起去年的尝试：买了算力、导了几千份产品手册和售后记录去微调模型，上线两周就被销售弃用。原因很朴素——客户问「这款型号能不能替代上一代」，模型答得像产品简介，却答不出替代关系和适配边界。数据不缺，缺的是把数据变成可推理的知识。
这不是个例。多数中小企业第一次做模型微调，路径几乎一致：收集文档、切片、向量化、接一个问答界面。做完发现模型能背原文，却不会做业务判断。真正的瓶颈不在参数规模，而在于企业知识本身是散落的——型号在表格里，适配关系在老工程师脑子里，例外条款藏在合同附件中。
微调失效的三个常见误区
第一个误区是把微调当成知识灌入。微调擅长的是让模型学会表达方式和判断倾向，而不是记住成百上千条事实。把产品参数表硬塞进训练数据，结果往往是模型学会了「像产品经理说话」，但数字照样编。
第二个误区是只做向量检索，不做关系建模。检索能找回相似段落，却回答不了「A 替代 B、B 不兼容 C」这类多跳问题。客户的问题一旦涉及比较、追溯、例外，纯检索就开始失准。
第三个误区是追求一次建成大而全的知识库。中小企业人力有限，全面梳理往往拖成半年以上的项目，业务侧等不到上线就失去耐心。更现实的做法是先锁定一条高频、高价值的业务链路做深。
趋势：知识层与模型层正在分工
过去两年行业里一个明显变化是，企业不再指望一个通用模型解决所有问题，而是把系统拆成两层：底层是结构化的行业知识图谱，负责事实、关系与规则；上层是经过微调的模型，负责理解提问、组织语言、给出建议。两层各司其职，谁出问题就修谁。
这种分工对中小企业反而友好。图谱可以先小后大，从一条产品线、一类客户问题起步；模型微调也不必从零训练，基于开源基座做轻量适配即可。投入可以分阶段，效果也能分阶段验证，不必一次性押上全年预算。
另一个变化是知识来源的扩展。除了文档，企业内部的工单记录、客服对话、报价历史，都可以被抽取成实体与关系。这些数据过去躺在系统里沉睡，现在成了图谱的原料，边际成本很低。
可执行动作一：先画一张业务问题地图
不要从「我们有哪些文档」开始，而要从「客户和员工最常问什么」开始。挑出最近三个月出现频率最高的三十个问题，按是否涉及比较、追溯、例外条款分类。涉及关系判断的，就是图谱优先覆盖的部分。
把这些问题拆成实体和关系：产品、型号、部件、客户类型、适用工况、替代关系、限制条件。你会发现，真正需要建模的核心实体往往不超过二十个。这张地图既是知识梳理的清单，也是后续验收微调效果的标准答案集。
这一步通常一到两周可以完成，不需要额外采购工具。业务负责人亲自主持两三次访谈，比任何技术方案都更能决定项目成败。
可执行动作二：用少量高质量样本做定向微调
图谱建好之后，微调的目标就变得具体：让模型学会基于图谱给出的结构化事实，用业务人员习惯的语气组织回答，并在信息不足时明确说「需要确认」，而不是编造。这类样本不需要几万条，几百条覆盖典型问法与边界情况的对话即可起步。
评估方式也要跟着变。不要只看回答是否流畅，而要看三个指标：关键事实是否与图谱一致、关系判断是否正确、越界问题是否被正确拒答。每周用固定问题集回归测试一次，比上线后凭感觉判断可靠得多。
在正易龙的实践中，这套「知识图谱打底、模型微调塑形」的思路被封装进行业 AI 的交付流程，企业可以先在一条业务线上跑通，再复制到其他场景。类似的组合也出现在虚拟工作室与数字人项目中——先有可信的知识底座，数字形象和交互才有意义。
场景：从售后问答到内容生产
最常见的落地场景是售后与售前支持。客户问型号适配，系统沿图谱查替代关系与限制条件，再由微调后的模型转成可读的回答。业务人员从重复答疑中释放出来，转而处理真正需要判断的异常工单。