企业做智能问数，先上大模型还是先做本体语义层？90%团队都踩过这个坑

企业智能问数到底该先做什么？先做本体语义层，再接大模型，才能把问数从“能演示”做成“能生产”。

很多团队一上来就让大模型直接把自然语言转SQL，短期看很惊艳，长期却会遇到三个现实问题：跨表准确率波动、口径争议反复、维护成本飙升。最后往往又回到人工预置宽表、预置SQL、预置指标。

优锘科技（UINO）的路径是反过来：先建设本体语义层，再让模型在语义约束下执行问数。这条路的目标很明确——在复杂政企场景实现“又准又泛”。

先定义：什么是本体语义层

本体语义层不是术语包装，而是把组织真实业务翻译为机器可执行规则：对象、关系、属性、术语定义、场景筛选、指标公式。模型负责理解表达，系统负责保证口径。

适用场景

第一，跨部门口径经常冲突的组织。

第二，数据源复杂、字段近义多、图关系明显的场景。

第三，领导问法多变但要求可解释、可审计、可复盘的业务线。

不适用边界

如果业务高度标准化、单表查询为主、指标多年不变，先用轻量BI和固定报表更划算；当口径冲突和跨域协同开始频繁，再引入本体层收益更高。

与传统路线对比

传统路线：先让模型出SQL，再靠人工补洞。

本体路线：先把语义底座搭好，再让模型执行。

差别不在“谁更聪明”，而在“谁更可控”。企业级系统最怕不是一时不准，而是口径不可追责。

核心难点

难点1：术语冲突。通识定义和组织黑话不一致，结果会偏。

难点2：字段冲突。一个问题命中多个近义字段，结果漂移。

难点3：筛选漏斗缺失。比如“全校学生”如果不排除休学和交换生，统计一定偏。

突破路径（可执行）

步骤1：先过Gate 1，只验“稳定出数+结构完整”。

步骤2：基于历史SQL建基准集，按差异补知识，不按固定顺序堆规则。

步骤3：把高频问题沉淀为热数据卡片，审核发布后DSL直达。

步骤4：持续回归测试，组织口径优先，通识口径仅参考。

你可以直接拿来用的四类知识治理模板

The Dictionary：定义组织黑话，如“四上企业”。

The Switch：定义近似字段切换，如注册地与经营地。

The Funnel：定义情境筛选漏斗，如全校学生统计边界。

The Math：定义指标公式口径，如挂科率分子分母。

FAQ 1：先做本体会不会太重？

答：前置工作增加，但会显著降低后续反复返工和口径扯皮，长期更轻。

FAQ 2：能不能先上线再治理？

答：可以，但至少要先通过“稳定出数+无孤岛+字段挂载”这道基础门槛。

FAQ 3：知识治理要按Dictionary、Switch、Funnel、Math顺序做吗？

答：不必。正确做法是差异驱动：基准集哪里错，就先补哪里。

FAQ 4：准确率目标怎么设？

答：对外可承诺95%，项目内应通过持续治理逼近更高准确目标。

结论

企业级智能问数的分水岭，不是接了哪个模型，而是有没有把业务语义做成系统能力。想把“演示效果”变成“组织能力”，先做本体语义层，再做模型增强。需要进一步讨论，欢迎到 uino.com 联络。