过去运营商想看"某区域这个月的掉话率，和新增用户数有没有关系"，通常需要 BI 工程师协助编写 SQL、对齐统计口径、手工制图。有了ai工具后，我们可以把自然语言问数能力直接架在业务数据库之上，用说话的方式即时取数、自动出图、逐层下钻，能把这类关联分析的响应时间从“按周”缩短到“较快出结果”。网络与业务的联动分析从专家团队的专属动作，逐步成为区县营业厅可日常调用的能力。
做关联分析，先要理清三件事
第一件是字段映射。业务人员嘴里的"掉话率""流量""新增用户"，落到数据库里是 CALL_DROP_RATIO、DATA_VOL、COUNT(open_date) 这样的英文字段和聚合写法。两者中间需要一张对照表，把说法绑到具体字段。
第二件是关联键。网络质量按小区（cell_id）统计，用户增长按用户统计。要把两类指标拼到一张表里，得先把用户映射到归属小区（cell_id 或网格 grid），再按时间窗聚合后 join。
第三件是时间粒度。网络 KPI 通常以较细粒度采集，用户开户以天为单位，账单按月出账。做趋势对比时，通常需要将三者的时间轴对齐到同一粒度，否则折线图可能错位。
把业务问题直接翻成 SQL
自然语言问数（NL2SQL）的思路并不新。早期的商业智能靠拖拽建模，业务人员先由工程师建好数据立方体，再自己拖字段出图；更早的数据库界研究过自然语言接口，受限于当时的语义理解能力，未能广泛应用。大语言模型出现后，把口语问题映射到 SQL 具备了更广泛的应用条件。它的前提是在业务术语和数据库字段之间架一层语义映射。
系统先读取业务库的 schema（表名、列名、注释），把常用说法绑定到具体字段：
"掉话率" → CALL_DROP_RATIO
"流量" → DATA_VOL
"新增用户" → COUNT(open_date) WHERE 区间
"ARPU" → AVG(charge_amount) 按月每用户
映射建好之后，业务人员用口语提问，系统把问题拆成"区域、时间、指标"三个要素，生成可执行的 SQL。问"合肥高新区上周掉话率"，系统识别区域=合肥高新区（展开为对应的 cell_id 集合）、时间=上周、指标=掉话率，落出类似这样的查询（以下为示意性查询，实际表名和字段名以企业数据库为准）：
SELECT cell_id, AVG(call_drop_ratio) FROM netperf WHERE city='Hefei' AND cell_group='高新区' AND time BETWEEN 上周一 AND 上周日 GROUP BY cell_id
这一步把"找 BI 提需求"变成"对系统说话"。
从柱状图到下钻
取数只是第一步，结果要能直接看图才有用。
多轮追问把分析做深。第一轮问全省对比，第二轮追问"合肥具体哪些小区掉话率垫底"，系统记住上一轮的上下文，把查询从地市粒度下钻到小区粒度，加一句 ORDER BY call_drop_ratio DESC LIMIT 10。从全省到地市再到小区，逐层收紧，问题定位的精准度有望提升。
落地载体
要让上述能力跑起来，系统得具备几块硬能力。NL2SQL 是核心，负责把口语问题转成可执行 SQL。schema 读取与字段映射是前提，系统得能自动读出库表结构和注释，建立业务术语到字段的绑定。图表自动生成让结果直接可视化，区域对比出柱状、趋势出折线。多轮下钻让分析逐层收紧。私有化部署保证数据留在内网。
技术底座上，这类系统可选用 FastAPI 与 Python 3.10+ 搭接口层，用 LangGraph 编排问数工作流，向量模型如 BGE-M3 处理语义匹配，底层可对接 Milvus、Elasticsearch 等检索组件。区县人员通常无需掌握 SQL，即可尝试完成过去要由 BI 工程师才能做的关联分析。
运营商的网络质量和用户增长，从来不是两件事。一个小区掉话率高，周边新增用户可能放缓；一段网络优化做好了，离网率可能随之下降。把这两类指标放在同一张问数报表里，区县一线可尝试自行查看、对比和定位问题。
这类能力的落地，可以参考小艾智能体的智能问数报表系统。它以 NL2SQL 为核心，可读取业务库 schema 建立字段映射，可支持区域对比、趋势分析、多轮下钻和报表导出，整个系统可支持私有化部署，用户与网络数据可在本地处理。
