数据表字段名并没有标注 “单价（price per unit）”，仅仅命名为 price。 所以 price 既可能代表总价，也可能代表单价。 （模型）默认把它当成了总价。如果 price 确实是总价，那大模型给出的答案就是正确的。 但现实场景里，数据库的字段命名往往不会尽善尽美，本例就是模拟真实业务里的这种情况。

由此得出结论：大模型很容易出现推理错误。我们需要通过某种方式告知模型：price 字段指的是单价，而非总价。 我们可以使用少样本学习（few-shot learning）实现这一点。这块后面再操作，我先再多运行几条查询语句。 与此同时，我会保存正确的问答标准答案。 实现方式就是直接执行明确的查询语句，而我们也通过这种方式拿到了正确结果。

梳理一下你这段业务场景的核心逻辑，同时补充关键要点

场景问题复盘

1. 歧义根源：缺乏字段语义元数据 数据表字段仅命名 price，无注释、无数据字典说明；

• 语义存在二义性：单价 / 总价
• 大模型依赖通用先验常识做推断，默认将 price 识别为总价

一旦业务定义里 price 实际代表单价，模型自主推理就直接出错。

1. 本质痛点 大模型不会自动读懂你内部数据库的业务约定；仅靠自然语言提问 + 裸数据表结构，存在字段语义歧义风险，属于典型的 Text-to-SQL 常见推理漏洞。 通用常识 ≠ 企业私有业务规范。

当前你采用的临时解决方案

直接手写精准 SQL 查询，绕过模型自动生成； 优势：结果 100% 可控，产出标准答案样本集； 作用：

• 积累正确「自然语言问句 ↔ 标准 SQL」配对样本
• 作为后续 Few-Shot 少样本学习 的训练 / 提示样本库

后续 Few-Shot 方案思路（承接你的计划）

把整理好的标准答案样例放入 Prompt，格式示例：

【数据字典说明】
price：商品单价，不是总价
amount：商品数量

【示例问答】
问题：xxx
正确SQL：xxx

问题：xxx
正确SQL：xxx

用户问题：{输入问题}

作用：

1. 显式注入字段语义定义（解决 price 歧义问题）
2. 通过少量样例示范模型遵循业务规则生成 SQL
3. 不用微调大模型，仅靠提示工程即可快速生效

延伸思考（工程上可选优化方向）

1. 最优方案：挂载数据字典（元数据） 在 Prompt 固定携带数据表字段注释，从源头消除歧义，优先级高于少样本；
2. 少样本 + 元数据组合 先声明字段业务含义，再附加范例，稳定性最高；
3. 兜底校验层 模型输出 SQL 后，增加规则校验：识别 price 相关计算逻辑，判断是否混淆单价 / 总价，异常时拦截重试。

我们来尝试使用少样本学习，让大语言模型能够修正它目前出现的各类错误。

在少样本学习中，我们首先要准备问题与 SQL 查询配对样本，也就是那些让大模型容易产生混淆的案例。 拿到这些训练样例之后，第二步就是把样例转换成向量嵌入（embeddings），这块我们会用到 HuggingFace 工具库。 接下来打开 Notebook，开始整理这些少样本示例。我们先用一个简单的 Python 列表存放样本，列表里每一条示例都是字典。 字典内首先包含一项：用户提问（question）。 除了提问之外，我们还需要存入 SQL 语句、查询结果以及最终答案作为参数。