看到 YOLO Data Agent 发布：自然语言查数，先把口径和数据库边界管住
内容提要
文章借YOLO Data Agent的发布，讨论自然语言查数的工程风险：SQL可执行不等于答案可信，退款、时间归属、地区定义等指标口径须预先审核，遇歧义应追问而非猜测。多轮追问需保存结构化查询状态，仅修改用户明确变更的部分，并保留可追踪标识以便排障。数据库应采用只读隔离库，限制数据范围，设置超时与资源预算，权限在服务端校验；缓存标识不能只含提问文本，以免越权复用。建议先选口径稳定、可与现有报表核对的小场景试用。
延伸解读
指标口径是自然语言查数的第一道门槛
文章指出，即使生成的 SQL 合法且数据库返回结果，数字仍可能不可信，因为退款是否计入、时间按创建还是支付归属、地区取收货地址还是门店地址等业务定义，数据库不会自动校验。与其反复调整提示词，不如预先审核常用指标口径，让查询走经过审核的定义；遇到歧义时追问用户，而不是替用户猜测。
多轮追问需要结构化状态与可追踪标识
用户继续追问其他地区时，上一轮确认的口径可能丢失。文章建议把已确认的时间范围、指标定义和筛选条件保存为结构化查询状态，下一轮只修改用户明确变更的部分，并在回答中带上最终采用的条件。同时，一次请求应有可关联的追踪标识，把查询状态与执行结果对应起来，便于排障；日志需脱敏，不应记录整份业务明细。
数据库边界与缓存不能只靠只读账号
只读账号挡不住扫描大表。文章建议接入隔离的分析库，限制可访问的数据范围，为查询设置超时和资源预算，权限必须在服务端校验，不能因对话中自称属于某部门就放开数据。缓存标识若只包含提问文本，在不同用户权限或不同指标口径下可能返回不该复用的结果，宁可少命中，也别拿命中率换数据边界。
小场景试用的检查清单
文章建议先选一个口径稳定、能与现有报表核对的查询场景试用。测试时故意换几种问法，再追问时间和地区，检查条件是否保留；同时观察慢查询，以及失败后能否退回原有报表入口。能否继续试用，取决于同一业务含义能否稳定得到可解释的结果，以及出现偏差时团队能否定位原因。
Q&A
自然语言查数工具生成的SQL能跑通，为什么答案还可能不可信？
因为SQL可执行不等于答案可信。指标口径如退款是否计入、时间按创建还是支付归属、地区取收货地址还是门店地址等业务定义，数据库不会因为语句缺少业务含义而报错，所以数字可能不适合直接使用。
多轮追问时如何避免丢失上一轮的口径？
建议把已确认的时间范围、指标定义和筛选条件保存成结构化查询状态。下一轮只修改用户明确更改的部分，并在回答中带上最终采用的条件，方便用户发现偏差。
自然语言查数系统如何做好排障和追踪？
让一次请求有可关联的追踪标识，把查询状态与执行结果对应起来。这样有人反馈数字不对时，维护者能追到当时采用的口径和实际执行的查询，而不只是看聊天记录。日志要脱敏，不应记录整份业务明细。
接入自然语言查数工具时，数据库权限和资源该如何控制？
先接隔离的分析库，使用只读账号，限制可访问的数据范围，并给查询设置超时和资源预算。权限必须在服务端校验，不能因为对话中自称属于某部门就放开对应数据。
为什么自然语言查数的缓存不能只按提问文本做标识？
因为同一句自然语言在不同用户权限或不同指标口径下，未必对应相同答案。缓存标识若只包含提问文本，就可能返回不该复用的结果，造成越权或口径错误。宁可少命中一些，也要保证数据边界。
小团队试用自然语言查数工具，应该从什么场景开始？
先选一个口径稳定、能和现有报表核对的查询场景。测试时故意换几种问法，再追问时间和地区，检查条件是否保留；同时观察慢查询以及失败后能否退回原有报表入口。
