← 返回概念项目列表 架构设计产品设计工程实现产品设计
概念原型Agent企业提效独立设计
业务数据智能查询平台
非技术角色用自然语言查库存、查销售、查报表，schema-aware + 多轮澄清，安全可控
企业 AI 改造中，数据查询是最高频的提效场景。销售想查上周转化率、仓储想查库存周转、运营想查投放 ROI——这些需求堆积在数据团队，排期两周起。这个原型是企业 AI 提效矩阵的业务场景层——基于 Agent 编排平台，用自然语言直接查业务数据，让非技术角色自助获取数据洞察。
产品原型
NL2SQL 查询界面 · 交互原型预览
QueryLab
用户提问："上季度销量最好的几个产品"
检测到 3 处歧义 · 已澄清 2 处 · 1 处待确认
查看生成的 SQL →3
歧义点
2
已澄清
0
高危操作
澄清对话
?
"上季度"指 Q2 还是 Q3？当前是 10 月
待确认
✓
"销量最好"已澄清为按金额非数量
已答
✓
"几个"已澄清为 Top 5
已答
核心模块
我设计的四个关键模块
01
🧠Schema 理解器
不是把整个 schema 塞给 LLM，而是先做语义检索找到相关表，再只给相关字段。大库 200+ 表时，全量 schema 会让 LLM 彻底迷失。
02
❓歧义检测器
用户问得模糊不是用户的错。我设计了四类歧义检测：时间范围、聚合维度、排序方向、模糊量词。检测到就主动追问，不瞎猜。
03
🛡️SQL 安全网
生成的 SQL 必须过三道关：只读校验、行数限制、超时熔断。我反对把 LLM 生成的 SQL 直接执行——这是 NL2SQL 最危险的捷径。
04
✅结果校验器
SQL 跑出来不等于答对了。我加了一层结果合理性检查：数值是否在常识范围内、是否和上次同类问题一致、是否需要交叉验证。
技术方案
从提问到结果校验的完整链路
🧠
Schema Retrieval语义检索相关表→
❓
Ambiguity Probe四类歧义检测→
🛡️
SQL Guard只读 + 限流→
✅
Result Validator合理性校验设计权衡与开放问题
已决策
- schema 先语义检索相关表，不全量塞给 LLM
- 四类歧义主动追问，不瞎猜
- SQL 三道安全网：只读、行数限制、超时
- 结果合理性校验，不只看 SQL 是否执行成功
➜
开放问题
- 多表 JOIN 的正确率仍偏低，约 70%
- 用户对"追问"的耐心有限，几次会放弃？
- 复杂分析（环比、同比）如何引导用户问对？
- 结果校验的"常识范围"如何自动学习？