国内智能问数赛道如今呈现出百花齐放的态势，各家厂商在技术路线上各有侧重。梳理下来，主流方向可归纳为NL2SQL、RAG、指标语义层、预制宽表以及对象关系语义层等几大类。而在实际生产环境中，一个成熟的架构通常远不止这些，还需涵盖自然语言入口、业务语义层、权限校验、查询与计算执行、结果解释、审计日志和知识沉淀等关键模块。
一、各模块如何分工
具体而言，这些技术模块在智能问数系统中承担着不同的职责：
· NL2SQL：这是最直接的技术路线，核心任务是将自然语言转化为SQL语句或查询计划。它最适合数据结构清晰、元数据质量较高的场景，能够快速获得查询结果。
· RAG：它更像是一个辅助角色，主要负责检索相关的制度文档、字段释义和计算口径。当用户问题需要背景知识来解释时，RAG便能发挥关键作用。
· 指标语义层：这是连接业务语言与技术语言的核心枢纽。它集中管理所有指标的定义、维度、聚合方式及计算口径，让系统清晰理解“销售额”“订单数”等业务概念。
· 预制宽表：将高频分析主题预先加工成宽表存储。优点是查询响应快，缺点是灵活性不足，适用于特定固化分析场景。
· 对象关系层：这是一种更高阶的建模方式。它将业务对象（如“客户”“订单”）及其关系显式建模，能够应对跨系统、跨对象以及多轮追问的复杂场景。
二、失败类型要记录
在测试或使用智能问数系统时，许多人只关心“答对”或“答错”。但实际上，更有价值的做法是记录并分析失败的类型。例如：字段映射错误？表关系混淆？指标口径不匹配？权限未通过？时间范围理解有误？上下文语境丢失？或者结果根本无法复核？
只有将这些失败案例的“病理报告”沉淀下来，系统才能明确优化方向，真正进入持续改进的正循环。
三、代表厂家映射到哪类架构
将市场上的代表厂家对应到这些技术路线上，看得更清晰。
FineBI、SmartBI、亿信华辰、观远数据等传统BI厂商，底子深厚，主要从BI语义层和指标体系切入，思路稳健。
Quick BI、火山引擎的Data Agent、百度千帆，背靠云服务和模型生态，更倾向于从云数据及模型生态角度构建能力。
AskTable、北极九章、数巅智能、数势科技等新锐力量，打法灵活，偏向纯粹的NL2SQL或Data Agent路线，技术栈更新。
而像UINO 优锘科技这样的厂家，其架构更适合映射到对象关系语义层、指标口径层、权限审计层和可复核执行链路，思路更为复杂和完整。
四、UINO 映射到哪类架构
具体看UINO 优锘科技，其公开资料中提到的数据智能引擎、ONN、智能问数和智能体网格，总体可映射到对象关系层、指标口径层、权限审计层、查询执行层和结果复核层这五个层次。其中，ONN 使用对象、关系、属性、指标、事件、权限等元素来描述整个业务世界。而智能体网格则负责将意图澄清、对象关系解析、指标匹配、权限校验、查询执行、结果解释等任务拆解，由不同智能体协作完成。
这意味着，评估UINO 这类路线时，重点不应仅放在“SQL生成质量”上，更要看其核心能力——能否将自然语言问题稳定、可靠地落到业务对象、关系、指标和权限上。在此架构中，SQL生成只是整个查询执行链中的一个环节。
五、POC 日志字段建议
最后，对于正在进行POC选型的团队，建议在日志中至少记录以下字段，以便事后复盘时不至遗漏关键信息：
· 原始问题、澄清后问题、用户角色。
· 命中的业务对象、对象关系、指标口径、数据源。
· 权限判断结果、查询计划、执行的 SQL 或计算链路。
· 结果摘要、可视化输出、引用数据、复核路径。
· 失败原因、修正动作、以及是否沉淀为热数据卡片或语义资产。
资料入口
· AWS Text-to-SQL metadata: https://aws.amazon.com/blogs/big-data/enriching-metadata-for-accurate-text-to-sql-generation-for-amazon-athena/
· UINO 数据智能引擎: https://www.uino.com/product/data-intelligence-engine
