乐正雕漆很多人一听到“AI问答系统连接ERP”，第一反应是：接个数据库，把表结构告诉大模型，然后让它生成SQL查数据，不就完事了吗？真这么干过的朋友应该已经踩过坑了。实际做企业级落地你会发现，问题根本不在“大模型能不能生成对SQL”，而在于数据权限怎么控制、上下文怎么组织、主数据怎么对齐、生产环境怎么扛住并发、模型胡说八道怎么兜底。这些才是AI问答系统连ERP真正让人掉头发的部分。
这篇内容是我在多个制造和流通类企业项目里，把AI问答系统接到ERP上的一些实战总结。从架构设计逻辑、数据接入路线，到RAG链路的关键细节，再到生产部署的容器编排和模型服务规划，最后是权限安全和踩坑记录。适合准备做企业知识库问答、ERP智能助手的架构师和技术负责人参考。看完不敢说让你一步到位，但至少能帮你避开我踩过的那些大坑。
1. 先想清楚：AI问答系统到底要从ERP里拿什么
很多项目一开始就做歪了，团队连“要回答什么问题”都没定义清楚，就开始灌数据、调模型。我见过最典型的案例是某企业领导要求“把所有ERP数据都喂给AI”，结果数据同步做了三周，模型一上线就开始胡说八道。原因很简单：ERP里几千张表，真正适合用自然语言问答去访问的，通常只占很小一部分。
1.1 业务数据问答与知识库问答是两条路线
先区分两个概念：知识库问答和业务数据问答。
知识库问答，是把操作手册、制度文件、培训材料这些非结构化文档切块、向量化，然后做RAG（检索增强生成）。这种方案回答的是“采购申请单怎么填”“库存冻结流程是什么”这类规范性、流程性问题。
业务数据问答，则是让用户用自然语言查询ERP里的结构化数据，比如“上个月华东区销售额是多少”“A产品当前可用库存多少”。这种问题本质上是NL2SQL的问题，大模型要把自然语言转成SQL，再到数据库里去执行。
这两条路线的技术栈、数据准备方式、权限模型完全不一样，混在一起做很容易两头都做不好。我看到很多失败的AI ERP项目，就是把流程文档和数据表一股脑倒进向量库，结果模型既找不到准确的数据，生成的流程答案也模棱两可。所以第一步不是选模型，而是定义清楚你的核心使用场景到底走哪条路线。
还有一条折中路线——语义检索加数据摘要。比如把ERP里的物料主数据、供应商信息先抽象成描述性的文本记录，再走向量检索。这样可以避开复杂的NL2SQL，但缺点是回答不了“某个月某个维度汇总多少”这类动态聚合问题。对于早期试点项目，这是一条成本很低的验证路线，但长期看还是要上结构化查询能力。
1.2 ERP数据不像你想象的那样干净，接口选型要趁早
ERP系统的数据质量，是AI问答项目最大的隐性成本。很多企业ERP用了七八年，物料编码重复、供应商名称不统一、单位字段混用（有“PCS”也有“个”）、历史单据里大量未审批的草稿数据。这些脏数据直接决定了你的检索和生成效果。
我建议在做架构之前，先做一次针对问答场景的数据质量盘点。具体做法是：挑出最核心的几张表（物料主数据、客户、供应商、库存、销售订单），逐个字段检查空值率、枚举值分布、数据更新时间。这个盘点结果会直接影响你的同步策略和检索设计。比如，如果物料主数据里“规格型号”字段空值率超过三成，那你在做检索增强时就要考虑这部分内容用什么兜底，否则用户问“有没有XX规格的物料”，模型会检索出大量残缺记录然后自圆其说。
另一个容易忽略的点是：不要一上来就直连ERP的生产数据库。我知道很多团队图省事，直接把问答服务连到ERP的数据库上，让模型动态生成SQL去查询。这在测试环境没问题，但在生产环境是灾难——一是会给ERP带来不可控的查询压力，二是权限控制很难做到字段级，三是ERP后续升级或重构会让你的SQL兼容性崩溃。我通常建议通过两种方式做数据对接，后面会详细展开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 架构设计：问答系统与ERP之间的数据流怎么走
这一节是全文的核心。AI问答系统连ERP，本质上不是在“连系统”，而是在建立一条从业务数据到大模型应答的完整数据链路。架构设计的目的不是搞一堆新潮组件，而是把这条链路稳定、安全、可维护地串起来。
2.1 分层架构：接入层、检索层、生成层、权限层
我用的分层架构分四层，这里直接画出来说明：
- 接入层：负责对接ERP数据源，包括数据库同步、API接口调用、消息队列订阅三种方式。
- 检索层：包括向量检索、结构化数据查询（NL2SQL）、混合检索编排。
- 生成层：负责大模型调用、Prompt编排、结果校验和兜底。
- 权限层：贯穿所有层的身份认证、行级权限过滤和审计日志。
这里最关键的架构决策是：检索层和生成层必须解耦，权限层必须前置到检索层。也就是说，用户提问进来之后，权限过滤不是在生成完回答之后才做，而是在检索数据和组装上下文之前就要完成。举例来说，销售总监问“所有大客户的应收账款”，他在检索层就只能拿到他权限范围内的客户数据，而不是靠模型生成回答后再“自觉”过滤。
这个分层设计的另一个好处是：每一层都可以独立扩展。检索层可以切换不同的向量库或SQL生成策略；生成层可以替换底层大模型，而不影响上游数据接入。很多项目一开始没注意分层，把所有逻辑写在同一个服务里，最后改任何一个环节都要重新回归整个链路，维护成本极高。
2.2 数据同步与API直连的取舍
数据从ERP到问答系统，通常有三条路线，各有各的适用场景。
第一条路线是定时批量同步。用ETL工具或自研同步任务，把ERP里的核心主数据和业务单据同步到问答系统的独立数据存储中。这套方案对ERP本身影响最小，查询性能可控，适合数据实时性要求不高的场景。缺点是数据会有延迟，不适合那种“用户刚在ERP里改了数据马上就要问”的场景。
第二条路线是API实时查询。通过ERP开放的API接口（比如SAP的RFC接口或REST网关），在收到问题后实时查询原始数据。这种做法的实时性最好，也能直接复用ERP里已有的权限逻辑，但高并发下会给ERP带来额外负载，而且API的响应延迟会成为整个问答链路的主要瓶颈。我一般只在数据量不大、查询频率低的管理驾驶舱类场景用。
第三条路线是消息队列消费ERP的增量事件。比如订阅物料变更、订单状态变更等事件，实时更新本地数据。这个是实时性和系统解耦之间的折中方案，适合对时效性要求高的场景。缺点是ERP侧要有消息推送能力，没有的话改造工作量会比较大。
我做过的项目里，最稳的组合是“主数据走批量同步 + 业务单据走增量订阅 + 少量高动态数据走API直查”。单一方案解决不了所有问题，这点在规划阶段就要跟业务方对齐。
2.3 权限控制在架构中的位置
ERP权限体系普遍比较复杂：有组织维度的（比如只看得到自己公司或工厂的数据）、有功能维度的（某些菜单和功能不开放）、还有数据维度的高级权限（比如只能看到某些特定客户或供应商）。
AI问答系统如果不继承这套权限体系，就等于在机密数据上开了一扇门。我之前遇到过一个血泪教训：某项目上线了财务问答功能，销售岗位的用户可以直接问“公司总体的毛利率是多少”。数据本身是准的，但问题在于，这个数据并不应该对销售岗位开放。系统查得到、答得出，模型本身没错，错的是没做权限控制。
所以权限控制一定要在做架构时就设计进去。我的做法是：在检索层做行级权限拼接。具体来说，问题进来之后，先从统一身份认证拿到用户信息，再根据用户的组织归属和角色去ERP权限系统同步权限规则，然后把权限条件拼到查询逻辑里。如果是向量检索，就把文档的权限标签过滤拼进检索条件；如果是SQL查询，就在WHERE条件里拼接数据范围条件。
这里有个很容易踩的坑：很多人以为权限只靠后端过滤就够了，但实际上大模型在生成回答时，会把你注入的权限条件“忽略”。比如你在上下文中明确“只看本部门数据”，模型可能仍然会生成一个查询全公司数据的SQL。所以必须在SQL执行阶段做强制改写，不能让模型生成的SQL直接执行，一定要经过一层业务规则校验。
3. 关键链路拆解：从ERP字段到大模型回答
有了整体架构，接下来要解决的是核心工作流问题。这节我会按数据接入、检索、生成三个阶段拆解，每个阶段都有不少反直觉的细节。
3.1 数据接入：主数据与业务单据的处理差异
ERP的数据接入不能一股脑全同步，要先分清两类数据：主数据和业务单据。
主数据（物料、客户、供应商、员工、BOM等）相对稳定，更新频率低，适合全量加增量同步，主要服务知识库类的问答（供应商联系方式、物料编码规则）。这类数据同步的关键在于ID映射，因为ERP里的内部ID（GUID或自增ID）和业务编码（物料编码、客户编码）经常是两套体系，在问答链路里要用业务编码和用户交互，内部ID只做关联。
业务单据（销售订单、采购单、生产工单、库存流水）数据量大、更新频繁、时效性要求高。这类数据同步的关键是增量抽取的“水位线”设计。我建议用数据库日志或数据更新时间戳做增量同步，并且一定要记录每个表的同步时间戳和影响行数。否则等上线后出问题，你很难判断某个数据是不是同步丢了。
在数据接入阶段就要做好字段的语义化Mapping。ERP里的字段名往往是缩写或者编码，比如“KUNNR”“VBELN”这种，模型看到这种字段名是无法理解的。我的做法是接入阶段就生成一份字段语义字典，把ERP字段翻译成业务术语，同时保留ERP底层字段的映射关系。这份字典既是检索阶段的提示词素材，也是SQL生成阶段的关键输入。
3.2 索引与检索：为什么直接向量化不够
很多人做RAG，默认就是把文档切块、向量化，然后存进向量库。但ERP问答场景下，直接向量化是远远不够的。
第一个问题：ERP的数据格式高度结构化，而且强关联。比如一张销售订单包含客户、物料、数量、单价、交期等字段，你直接把这行数据转成一段文本再向量化，语义信息会丢失得非常厉害。用户问“A客户的B物料最近三个月下单趋势”，向量检索很难把这种多条件、带时间范围的问题，和你切出来的那些孤立的订单文本块对齐。
第二个问题：同一个业务对象在不同表里的描述不一致。比如物料编码在订单表里是物料ID，在物料主数据表里是物料描述。直接向量化会让检索召回的关联性很差。
所以我在这个环节用的混合检索方案是：结构化查询走NL2SQL，非结构化知识走向量检索，两者结果再做一个融合排序。具体来说，先把用户问题分类，判断它是“数据查询型”还是“知识查询型”还是“混合型”。数据查询型的直接走NL2SQL链路；知识查询型走向量检索链路；混合型则两条链路同时进行，最后把两部分结果打包给大模型组织回答。
NL2SQL链路有个工程化的小细节：不要直接把整库表结构扔给大模型让AI生成SQL。数据库可能有几百张表，一旦表结构超出上下文窗口，模型就会选择性失忆。我的做法是只把核心业务表的结构和字段字典注入，加上几个优秀示例查询，限定模型生成的SQL只访问这些表和字段。这样既能提高生成准确率，又能防止模型去“探索”你不想开放的敏感表。
3.3 大模型生成与ERP数据校验
当大模型拿到检索结果后，真正的考验才开始。之前在企业项目里见过太多模型一本正经地报出错误的库存数字——不是检索不到，而是检索到的数据是过期的，或者干脆是模型自己从别的地方“脑补”的。
我总结了一套三层校验机制：
第一层是数据新鲜度校验。在检索阶段，给每条检索结果都带上数据时间戳。如果用户问的是“实时库存”，而检索到的数据是昨天同步的，模型必须在回答中说明数据时点，或者触发API直查获取最新数据。
第二层是答案来源的引用校验。生成结果必须附带引用来源ID，至少要能说明“这个数字来自哪张表、哪个同步批次、什么时候更新的”。模型输出结果后，系统自动校验引用是否真实存在。如果模型生成的答案找不到对应数据来源，直接判为幻觉，返回“无法确认”。
第三层是对比校验。同一个问题，如果之前有相似查询，可以把历史结果拿来做参考。比如用户上周问过“库存数量”，这次又问同样问题，如果结果差异巨大，系统会触发告警。尤其是在数值型答案上，这种方法效果很好。
4. 生产部署：容器编排、模型服务与稳定性
架构设计和链路验证完成后，下一步就是上生产。这节我会重点讲部署架构、模型服务配置和稳定性保障。很多人死在这一步，原因是本地Demo跑通了，但生产环境的各种问题还没遇到过。
4.1 部署架构：推理服务、RAG服务、连接器服务拆分部署
AI问答系统连ERP的生产部署，至少需要拆成三个独立服务：
- 模型推理服务：负责大模型的推理，可以是一个私有化部署的开源模型，也可以是外部API，但企业场景我强烈建议私有化——数据不出内网这条红线，能避免绝大多数麻烦。
- RAG服务：负责检索、Prompt编排、结果校验逻辑，是一个无状态API服务，可水平扩展。
- ERP连接器服务：负责对接ERP系统，包括数据同步任务、API直查、权限同步。
这三个服务的部署策略可以这样理解：推理服务是重型资源消耗方，需要GPU或高速CPU资源；RAG服务是无状态计算，可以跑在普通容器里，按请求量弹性扩容；ERP连接器服务则要靠近ERP环境部署，尤其是涉及内网专线连接的场景。
用Docker Compose或Kubernetes都能部署，取决于你的运维能力。我之前给中小型企业做项目，直接用docker-compose反代加三个服务就能跑得很稳。如果是大型企业，建议上Kubernetes，主要看重它的自动扩容和滚动更新能力。下面是生产环境docker-compose一个参考片段：
yaml复制version: "3.8"
services:
vllm-server:
image: vllm/vllm-openai:latest
command: ["--model", "/models/Qwen2.5-14B-Instruct", "--served-model-name", "erp-assistant", "--port", "8000", "--gpu-memory-utilization", "0.85"]
shm_size: "16gb"
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 2
capabilities: [gpu]
volumes:
- /data/models:/models
ports:
- "8000:8000"
rag-service:
build: ./rag
environment:
- LLM_BASE_URL=http://vllm-server:8000/v1
- VECTOR_STORE_URI=redis://redis-stack:6379
- ERP_CONNECTOR_URL=http://erp-connector:8080
ports:
- "8082:8000"
depends_on:
- vllm-server
- redis-stack
erp-connector:
build: ./erp-connector
environment:
- DB_HOST=10.0.0.8
- DB_NAME=erp_prod
- KAFKA_BROKERS=10.0.0.5:9092,10.0.0.6:9092
ports:
- "8083:8080"
restart: unless-stopped
redis-stack:
image: redis/redis-stack:latest
volumes:
- redis-data:/data
ports:
- "6379:6379"
需要格外注意的是shm_size。我用vLLM部署时，如果不设置shm_size为“16gb”，很容易在加载模型时出现共享内存不足导致的进程崩溃。这个小细节排查起来特别费劲，因为日志里只会报一个很笼统的CUDA错误。
4.2 模型服务的关键配置：显存规划与并发度
模型推理服务的容量规划是生产部署的重头戏。这里我先说明一个常见的误区：很多人只看模型参数量，以为7B模型只需要7 × 2GB显存（FP16）就可以。实际上还要算上KV Cache和推理时的激活值，按经验值，7B模型至少需要20GB以上的显存（FP16），14B模型至少40GB，32B模型建议直接上80GB的卡。
KV Cache是推理并发时的最大变量。并发每增加一个，KV Cache的显存占用就相应增加。我用vLLM时，一般通过--max-num-seqs限制最大并发数，同时强制设置--gpu-memory-utilization在0.85到0.9之间，留出一部分管理开销余量。这样既能保证吞吐，又不容易OOM。
另一个部署层面的关键参数是--max-model-len，也就是最大上下文长度。之前我为了让模型能处理超长检索内容，把上下文设得非常大，结果并发只能降到1，等于一个问答要排队。后来发现一个更务实的做法：上下文长度按业务场景压到4096或8192，通过前端把超长检索内容做摘要，去掉不必要的内容。因为ERP问答大多是“数据加流程说明”，用长上下文去承载大量冗余段落，性价比很低。
4.3 配置管理、灰度发布与可观测性
生产部署不是“容器跑起来”就结束了，后面还有配置管理、监控、灰度的问题。
配置文件要跟代码分离。不同环境（开发、测试、生产）的ERP连接串、模型地址、权限同步规则，都不该写死在代码里。用环境变量加一个配置中心，能让你在升级时不动代码就能调整参数。生产环境至少要有日志、指标、Trace三件套，否则排查问题时寸步难行。
灰度发布是容易被忽视的一环。模型升级不是“换个API地址”那么简单。比如从Qwen2.5-7B升级到Qwen2.5-14B，回答风格和准确率都会变。要避免一次性全量切到新模型，先让5%的流量走新模型，对比一段时间的效果指标（回答采纳率、追问率、超时率），稳定后再逐步放量。我用的是一个简单的流量分流开关：在RAG服务里配置按用户ID做hash分流，不需要额外的网关组件。
可观测性的核心是日志。AI问答系统跟普通Web系统不一样，普通系统只需要记录“请求-响应-状态码”，而AI问答系统需要记录完整链路：用户问题、检索到的文档列表、拼接后的Prompt、模型输出、校验结果、最终答案。这样一旦用户反馈某个回答不对，你可以回溯到具体的检索和生成环节，快速定位是哪个部分出了问题。
5. 权限与安全：AI问答连ERP绕不开的底线
这一章我放在部署之后讲，是因为很多团队先实现功能后补权限，最后返工成本巨大。如果你的AI问答系统要接生产ERP，权限设计必须是一等公民，从第一天就融进架构。
5.1 行级权限与字段级脱敏
前面提到过，权限控制必须前置到检索层。这里具体说说怎么做行级权限和字段级脱敏。
行级权限的核心是权限规则同步。ERP侧有一个用户数据权限配置表，比如“张三可以看到华东区的销售数据”“李四是A、B两家客户共享账户的管理员”。AI问答系统要定期同步这套规则，存到本地。在用户发起查询时，从统一身份认证获取用户信息，再查本地的权限规则，把用户可访问的数据范围作为强制过滤条件。
字段级脱敏则是控制每个用户能看哪些字段。比如普通销售能看到订单金额但看不到利润率，高管能看到全量字段。这个在NL2SQL场景实现方式是：权限在SELECT列层面做过滤——解析模型生成的SQL，根据用户角色过滤掉无权访问的列，同时修改SELECT后面对应的列名，禁止“SELECT *”或“SELECT所有字段”这类写法。
这里有一个很实用的补充策略：字段级脱敏不一定只在SQL层做，也可以在结果层做标记。比如模型生成答案后在返回前端之前，识别其中是否包含敏感字段（手机号、合同金额），命中规则就脱敏替换。这种方式对结构化查询和知识库问答都适用。
5.2 多轮追问的权限保持与审计设计
多轮对话是另一个容易漏权限控制的场景。用户第一问问“华东区的销售额”，第二问问“那利润呢”。如果第二问没有带上上下文里的权限范围，模型可能会按全局利润来回答。解决方案是在多轮会话中把权限上下文持久化，每一轮请求都要重新校验用户权限，不能因为同一会话就默认权限不变。
审计日志方面，为了满足ERP的合规要求，问答系统的每一个问题和答案都要能追溯到用户、时间、数据范围和引用来源。审计日志不该只记录用户的问题和模型的回答，还要记录“模型实际查询了哪些表、哪些行”。特别是当用户问的涉及ERP敏感模块时，这个审计能力会成为合规审查的关键依据。
我碰到过一种情况：某次企业内部审计发现一个AI问答工具有人问过“某个员工的薪酬数据”，好在审计日志完整记录了该用户没有权限、系统拒绝了请求。如果没有这套审计，责任很难说清楚。所以，日志不光是技术问题，也是企业的管理护身符。
6. 实操过程中的踩坑记录
这章记录我在实际项目中遇到的最典型问题，每一条都是真金白银踩出来的。写出来希望能帮后来的人少走弯路。
6.1 数据权限穿透：用户问出了他看不到的数据
第一个大坑是数据权限穿透。
现象：某用户在ERP里明明看不到某个客户的订单，但在AI问答系统里，通过自然语言提问，竟然能问到那个客户的订单数据。
排查过程：我用了两周时间才定位到根因。最初以为是权限过滤的WHERE条件没生效，后来发现过滤条件是生效的，但问题出在“权限参照系”上。ERP里的权限是根据“组织节点共享策略”来控制的——一个用户属于销售一部，销售一部共享销售二部的部分客户数据，所以权限不是简单的“所属组织等于某个节点”，而是一套复杂的继承关系。AI问答系统的权限同步任务只同步了用户的直属组织，没有同步共享策略，导致权限计算结果比ERP窄了，用户的权限被“缩小”，反而没有越权。但在另一个角色上又出现反过来的问题：集团高管看所有组织数据，权限规则是“数据范围包含所有下级”，而AI问答系统的权限过滤条件只写了“组织ID IN（当前用户直属组织）”，导致高管在AI问答系统里虽然能看到所有数据，但权限判断逻辑让人误解为“所有数据都对所有人开放”。排查中我们一度以为“是不是权限在什么地方被放宽了”，验证之后才发现是权限实现维度不完整。
修复方案：权限同步改成直接调用ERP的权限查询接口，而不是本地规则映射。每次请求问答时，实时调用ERP权限接口获取用户的实际数据范围，再注入查询。虽然多了一轮网络开销，但权限准确性大幅提升。后来发现，与其在本地维护一份永远可能过期的权限规则，不如在请求量大时加缓存、在关键时刻实时校验。
6.2 模型“自信地胡说”：数据源引用与校验机制的必要性
第二个坑是模型编造数据。
现象：用户问“本月有多少个未发货的销售订单”，模型答“327个”。实际系统里是319个。这个误差不是SQL算错，而是模型没真正执行SQL，它根据我灌进去的历史摘要“猜”了一个数字。或者在某些场景下，模型把ERP知识库文档里的一句话，当成数据库里的统计结果来输出。
排查过程：一开始怀疑是SQL生成错了，反复查看NL2SQL生成日志，SQL没问题，执行结果就是319。但模型回答是327。问题出在生成阶段。模型在拿到SQL执行结果后，把结果和某个统计口径的历史数据做了融合，而历史数据的统计口径和当前查询并不一致。更麻烦的是，模型“自信”地没有提示用户这个数字和实际查询结果不一致。
修复方案：强制在Prompt中声明“如果当前查询结果与参考历史数据不一致，一律以当前查询结果为准”，同时对所有数值型回答做答案与引用的对齐校验。校验规则是：答案中出现的数值必须在检索结果的数据或某个引用来源中出现过，否则拦截。
这个机制上线后，数值类问题的准确性提升了非常多。我觉得核心思路是“不要相信大模型的记忆，只相信大模型的推理能力”。模型擅长的是把检索到的信息组织成优质答案，而不是凭记忆给你报数字。企业数据集里各个年份的历史数据就是天然的“记忆”，在需要判断与推理时引导它调用。
6.3 增量同步的“幽灵数据”：索引更新滞后问题
第三个坑是数据同步和检索之间的延迟。
现象：ERP里一条数据刚被修改，AI问答系统却在十秒后问“这个数据为什么没变”。用户认为AI问的是实时数据，但AI查的是同步库。
排查过程：查了同步任务，任务正常执行了，数据也到了目标库。问题出在检索层的查询路由上。混合检索链路里，向量检索的索引要等同步任务完成后异步重建索引，而新数据到达后索引重建需要几秒到几十秒。这期间如果有查询打到刚变更的数据，检索结果是旧的。看起来就像“数据丢失”。
修复方案：把“数据变更时间”和“索引更新时间”绑定，查询时带上最新数据时间戳。如果数据更新时间和索引更新时间存在差距，就动态切换查询路径——实时性要求高的走API直查，不敏感的走索引查询。另外，给每条检索结果打上“数据截止时间”，让模型在回答中体现这个时点，避免用户误以为看到的是实时数据。
这个坑提醒我一个重要原则：在AI问答的链路里，“知道数据的截止时间”和“给出答案”同样重要。不提示时效性的数字问答，在业务上是不可信的。
7. 上线后的效果评估与持续迭代
生产部署只是开始，真正决定项目成败的是上线后的评估与迭代体系。AI问答系统不能像传统系统一样，交付完就撒手不管。
7.1 评估指标：超出聊天满意度之外的三件套
我给企业项目做上线评估时，用的主要指标不是“用户满意度”，而是三个更硬性的指标：
第一是问题覆盖率，也就是所有提问里，AI真正能够回答出有效答案的比例。如果大量问题无法匹配到任何数据或知识，说明数据接入和检索范围有问题，需要补充数据源或调整检索策略。
第二是答案采纳率，也就是用户对回答的反馈质量。最直接的方式是加“已解决/未解决”按钮，或者分析用户是否在AI回答后继续追问或转人工。之前做的一个项目里，答案采纳率达到75%以上，业务方就会觉得AI确实能干活。
第三是幻觉率，也就是回答中数据和引用来源对不上的比例。这个指标主要通过抽检和用户反馈来监控。我见过最好的做法是：每周从日志中抽样100条问答，人工标注是否存在“AI编造数据”的情况，作为模型升级和Prompt调优的基准数据。
7.2 效果迭代：从数据质量到Prompt调优
迭代优化的优先级我建议是“先提升数据质量，再调Prompt，最后换模型”。
第一步优化数据质量。对日志中出现频率高但回答不准确的问题，去检查对应的ERP数据是否完整，字段映射是否正确。很多时候，回答差是因为数据源本身就缺字段。
第二步调Prompt。针对特定类型的bad case，在Prompt里补充few-shot示例。比如用户问“库存不足的物料”，如果你希望模型优先展示“可用库存”而非“总库存”，就可以在示例里加入一个“库存不足SQL生成规则”。
第三步才是换模型或调参数。我的经验是，在数据质量和Prompt都优化到位之前，换模型的收益并不明显。之前有个项目从7B模型升级到14B模型，回答流畅度提升了一些，但幻觉率并没有显著下降，因为问题出在检索阶段，而不是生成阶段。
我觉得做这个项目跟做传统软件开发最大的不同是：传统软件交付的是确定逻辑，AI问答交付的是一个需要持续喂养和校正的系统。如果业务方没有这个预期，项目上线三个月后大概率会变成“摆设”。前期在架构上预留好日志、评估、反馈闭环这些能力，比后期补要省力得多。
8. 最后的建议和一点个人体会
结合几年里做过的大小项目，最后给准备做企业AI问答连接ERP的团队几个直接建议。
第一个建议是：从核心的高价值窄场景切入，不要一上来就想覆盖全部ERP模块。 比如先做“库存查询和物料主数据问答”，验证链路通顺之后，再做销售分析、财务指标这类复杂场景。窄场景的好处是权限、数据质量、评测都容易做扎实，给业务方建立信心。
第二个建议是：把权限设计和数据同步设计放在功能开发前面。 我见过太多项目在Demo阶段效果惊艳，一旦接到生产ERP环境，因为权限问题被安全团队卡住，整个项目延期。权限设计不是功能之后的“补丁”，而是架构的一部分。
第三个建议是：在“做什么”上多花时间。 AI问答系统连接ERP，本质上是一个“翻译器”——把业务问题翻译成数据请求，再把数据翻译成人话。这个翻译质量不仅取决于模型聪明不聪明，更取决于你前面的业务定义是否清晰。你问业务方“想要什么”，业务方说“想要一个能智能回答问题的助手”，这不够。你要继续问“回答哪个领域的问题、给谁回答、回答错了会有什么后果、回答需要多及时”。这些问题的答案，往往比技术选型更能决定项目的命运。
如果让我用一句话总结这个项目的核心经验：AI问答连接ERP、生产部署，技术难度其实远低于业务复杂度。 把数据理清楚、权限管住、并发的坑提前踩完、日志和评估体系搭好，这个项目基本就成功了大半。剩下的，无非是花时间持续调优而已。