大模型向企业渗透的速度，这两年明显加快。近年来行业讨论的焦点还是"数智化转型要不要做"，"用自然语言查数"正成为企业数字化讨论中的常见议题，已经变成了"用自然语言查数"。部分业务人员希望缩短获取报表和数据分析结果的等待时间，张嘴就问"上季度华东区哪个产品回款最慢"，期望系统在几秒内返回一张图表。 这类对话式分析的需求，在部分BI产品中有所体现，热度持续走高，但落地见效的项目数量可能有限。
要让"人说话、系统出数"这件事与AI深度融合、切实走向智能化，仅靠一个会对话的模型通常不够。基础需要先打牢。这块地基，就是数据库Schema的自动理解和元数据管理。
智能问数的重要环节之一，不仅是让模型学会表达，也需要先为企业库表建立可理解、可对应的数据地图。
Schema自动理解：先给企业数据画张地图
定义需要讲清楚。Schema自动理解，是系统主动扫描数据库里的表结构、字段名、字段注释，再统计一些分布特征，比如某字段空值占比、取值区间、是否主键、基数高低，可基于库表、注释和统计特征生成数据地图初稿，供业务人员校验和补充。这张图回答两个核心问题。企业究竟有哪些数据，每个字段在业务上到底意味着什么。
不少企业数据库里的表，字段名是ab_amt、cust_id、region这类缩写，光看名字很难判断ab对应什么业务。数据地图的价值，正是把这些黑话翻译成业务人员能读懂的语义，让模型和人都看得明白。
模型如何"读懂"一张表
系统先把库表的Schema和字段注释读进来。这一步看似普通，实际暗藏不少坑，许多老系统的注释要么缺失，要么只写了"字段1"。
接下来用大模型做字段语义消歧。模型会把"amt"解读为金额，"region"对应到地区，"cust_id"关联到客户维度。这一步依靠模型结合注释与上下文去推断，而非写死的规则硬翻。注释越清晰，推断通常越准确。系统还会利用统计特征辅助判断字段类型，例如"订单日期"空值少且均为日期格式，模型就知道它适合做时间聚合；"status"基数很低，则适合做分组维度。
再往上，系统会构建一张"表-字段-业务词-同义词"的四层映射。举一个具体场景，"销售额"和"营收"在某些公司是两个不同字段，在另一些公司就是同一个，这张表把这种关系显式记录下来，后续翻译SQL时有助于减少指错目标的情况。映射的第四层同义词，解决的正是"同一含义多种说法"的麻烦。
顺带，系统还会对注释质量打分。发现某个字段注释为空或过于敷衍，会标出并提示补全。源头数据如果失真，后续链路可能受到影响。
元数据质量卡住了问数的上限
从工程角度看，缺少这张数据地图，NL2SQL的准确性可能受到较大影响。模型不知道库里究竟有哪些表，可能只能依赖训练时记下的通用表名去猜，猜出来的名字在真实库里可能并不存在，报错信息也可能不够直观。
通常有助于提升字段匹配和SQL生成的可用性，实际效果仍受数据质量和业务规则影响。两者可能存在正相关关系，喂给模型的上下文越干净，它犯的错通常越少。实际项目里，不少团队堆模型参数、更换更大尺寸的底座，问数准确率却卡在某个水位上不去，瓶颈可能在元数据这一层。
元数据管理的质量，在很大程度上影响问数准确性和稳定性的关键因素之一。把RAG的思路搬过来也成立：检索阶段找回的字段片段质量差，生成阶段模型效果也可能受到较大限制。地图画准了，后面的检索、权限、翻译才更有可能准确。
小艾智能体可提供元数据管理模块。它可自动抽取库表的字段、注释和统计特征，把前面所说的数据地图构建起来，具体支持范围及抽取效果以产品版本、数据源权限和实施配置为准，同时可支持同义词和业务词的手动配置，帮助补充系统自动推断不准的地方。
这个模块是问数链路的重要环节之一。后续的自然语言翻译、向量检索、权限控制可基于它生成的数据地图运行。如同先浇筑地基，其上的Agent工作流、RAG问答才更有可能稳定运行。业务侧的应用也顺着这条链路长出来，例如财务问"本月各事业部毛利对比"、供应链问"华东仓哪些SKU周转低于15天"、HR问"研发岗上月离职率"，在数据地图、指标口径和权限配置正确的前提下，可辅助生成SQL;结果应经业务或数据人员复核，一个重要前提是数据地图先画对。模块还可按配置对新增或变更表进行增量扫描，有助于减少地图过期的情况。