一句话看懂：InfoQ 刊发平安寿险高级工程师张阳的实践复盘，指出纯 LLM 方案做自然语言转 SQL（NL2SQL）在金融场景中会产生”静默错误”，提出用本体工程把业务口径变成机器可校验的显性规则。对正在做企业级 AI 问数的团队，这是一份来自生产环境的踩坑参考。
事件核心：发生了什么
文章把数据分析工具的演进划为四个阶段：固定报表（准但慢）、自助 BI（活但难）、AI 问数 NL2SQL（快但飘）、本体驱动的认知智能（准且懂）。核心论点是：大模型的本质是基于概率预测下一个 token，它并不真正理解”有效保单”在库里对应 status_code = 1 还是 status_flag = ‘Y’。生成的 SQL 语法可能完全正确，但字段映射一旦猜错，返回的就是错误结果，且这种错误是”静默的”，业务人员很难从结果形态上察觉。作者以此论证，金融场景必须引入本体，充当口径统一、可追溯的”语义导航系统”。
为什么重要
NL2SQL 目前是企业数据民主化的热门入口，但金融数据对准确性要求极高，一个”看起来差不多”的查询可能对应监管口径偏差甚至合规事故。文章提出”精准优先、推理按需”的务实定位：本体不必追求 Palantir 式跨实体多跳推理的上限，而应优先保证最准执行。另一层价值在于复用——一套本体可同时服务智能分析与面向数仓的 AI Coding（自然语言生成数据查询代码），数仓、业务、AI 团队共享同一套”业务语言”，降低沟通成本。目前公开信息显示，这一判断来自方法分享与脱敏示意案例，未披露具体量化指标。
对开发者/企业采购的影响
对做企业 AI 问数的开发者，纯 prompt 工程加 RAG 检索表结构，难以稳定解决口径映射问题；本体更适合作为独立于模型的语义层沉淀。对企业采购方，评估 NL2SQL 产品时应重点考察是否支持显式口径定义与结果可追溯，而非只看自然语言交互的流畅度。对数据团队，本体建设不是一次性投入，而更像可复用的长期资产。
值得关注的后续
一是本体建设能否从方法论走向可落地的工程工具链；二是头部 NL2SQL 产品是否会把语义层做成标配能力；三是金融监管口径变化后，本体规则的更新与审计机制如何设计。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
来源：InfoQ CN
