AI 数据标注任务平台

为中国 AI 崛起
提供高质量数据集

汇聚 · 清洗 · 标注 · 输出,一站式数据服务。
海量任务随时接,标注收益看得见。

1.2万+平台标注员
300+在售数据集
98%交付合格率

平台三大能力

任务接单、成品采购、定制寻源,一站覆盖数据全链路

AI 任务广场

语音转写、图像标注、模型评测、数据采集,多形态任务实时更新,按能力与信用智能匹配。

成品数据集

语音、图像、视频、文本、多模态成品数据,阶梯授权灵活采购,支持免费试用样例。

数据寻源

发布定制数据需求,汇聚全国供给方快速响应,从寻源到交付全程可追踪。

01
发布需求
任务 · 数据集 · 寻源
02
智能匹配
找得到 · 找得好 · 专属好
03
采集标注
移动端 + PC 双端作业
04
双重质检
机检初筛 + 人工复核
05
结算交付
积分结算 · 发票齐全

复杂多表 Text2SQL 评测

四表关联、分层过滤、客户去重,对比推荐模型与基线在 JOIN / HAVING 上的推理对错

QAPex Workspace / 计算机 / 大模型应用
任务 ID:088_Text2SQL 复杂多表推理_04
PROMPT

在 Text2SQL 任务中,多表关联查询会面临表连接选择、过滤条件归属、聚合嵌套的推理约束。模型容易出现表 JOIN 错误、聚合层级错乱、谓词下推错误等逻辑缺陷。

已知:

业务数据仓库共 4 张核心表

  • customers(customer_id, customer_name, region, register_date) 客户表
  • orders(order_id, customer_id, order_date, total_amount, status) 订单表
  • order_items(item_id, order_id, product_id, quantity, unit_price) 订单明细表
  • products(product_id, category, brand) 商品表

表关系约束:

  • orders.customer_id → customers.customer_id
  • order_items.order_id → orders.order_id
  • order_items.product_id → products.product_id

问题:

  1. 用户自然语言提问:统计 2025 年华东地区,每个商品品类下,下单客户数大于 100 的品类总销售额,只统计订单状态已完成的订单。请写出正确 SQL,并推导模型容易出错的推理卡点。
  2. 基于上述推导,提出从 Prompt 与检索层面提升 Text2SQL 多表复杂查询准确率的策略。
思维链推导 (COT)
  1. 拆解需求:时间范围 2025、地区 = 华东、按商品品类分组;过滤条件分两层:客户数 > 100(分组后 HAVING)、订单已完成(WHERE 前置过滤)
  2. 识别所需表:customers + orders + order_items + products,4 表 JOIN
  3. 区分过滤层级:WHERE 过滤订单时间、地区、订单状态;HAVING 对分组后的独立客户数量做限制
  4. 聚合指标:总销售额 = SUM (order_items.quantity * order_items.unit_price);客户数 COUNT (DISTINCT customers.customer_id)
  5. 模型易错卡点:混淆 WHERE 与 HAVING、COUNT 不加 DISTINCT 造成客户重复统计、错误关联表丢失过滤条件
  6. 结论:复杂 Text2SQL 的错误根源不只是字段幻觉,更多是聚合逻辑与条件层级的推理错误
MODEL EVALUATION
Model A 推荐模型

证明过程:

表结构:
customers(customer_id, customer_name, region, register_date)
orders(order_id, customer_id, order_date, total_amount, status)
order_items(item_id, order_id, product_id, quantity, unit_price)
products(product_id, category, brand)

正确 SQL:

SELECT
    products.category,
    SUM(order_items.quantity * order_items.unit_price) AS total_sales,
    COUNT(DISTINCT customers.customer_id) AS customer_cnt
FROM customers
INNER JOIN orders ON customers.customer_id = orders.customer_id
INNER JOIN order_items ON orders.order_id = order_items.order_id
INNER JOIN products ON order_items.product_id = products.product_id
WHERE
    YEAR(orders.order_date) = 2025
    AND customers.region = '华东'
    AND orders.status = '已完成'
GROUP BY products.category
HAVING COUNT(DISTINCT customers.customer_id) > 100;

推理说明:正确区分前置过滤 WHERE 和分组后过滤 HAVING;使用 COUNT(DISTINCT) 去重统计客户;完整且正确 4 表关联,SQL 可直接在数据库执行。

事实信息 +10

准确拆解多层业务条件,区分行过滤与分组过滤,多表关联关系无误,无编造表 / 字段。

Model B 基线模型

生成 SQL:

SELECT
    products.category,
    SUM(order_items.quantity * order_items.unit_price) AS total_sales,
    COUNT(customers.customer_id) AS customer_cnt
FROM customers
INNER JOIN orders ON customers.customer_id = orders.customer_id
INNER JOIN order_items ON orders.order_id = order_items.order_id
INNER JOIN products ON order_items.product_id = products.product_id
WHERE
    YEAR(orders.order_date) = 2025
    AND customers.region = '华东'
    AND orders.status = '已完成'
    AND COUNT(customers.customer_id) > 100
GROUP BY products.category;
观点分析 -10

问题分析:典型逻辑错误,把分组聚合条件写进 WHERE 子句(WHERE 不能识别聚合函数);COUNT 没有加 DISTINCT,同一客户多次下单会被重复计数,统计客户数量虚高。属于复杂 Text2SQL 常见逻辑推理缺陷,不是字段幻觉,而是 SQL 语法与业务逻辑理解错误。

策略:

模型缺少对 SQL 执行顺序的认知,仅靠大模型原生推理容易混淆过滤层级;需要增加 SQL 语法校验器 + 业务规则 RAG 做约束。

CONFIDENCE SCORE 97.6%

专家领域

覆盖计算机、方言、医学、法学等专业标注能力,按领域匹配专家

数据集广场

精选已上架成品数据,阶梯授权一目了然 · 登录后可咨询与采购

加载中…
正在拉取在售数据集…

随时随地,开始接单

三大平台全覆盖,扫码即装、扫码即玩

正式可下载
Android
Android 下载二维码

扫码或点击下载 APK 安装包
任务提醒、语音采集、移动标注全支持

下载 APK
正式可用
微信小程序
微信小程序码

微信扫码打开小程序,无需安装 App
任务提醒、接单与采集均可使用

微信扫一扫打开
正式可下载
HarmonyOS
鸿蒙下载二维码

鸿蒙手机用系统相机或应用市场扫码安装
进入华为应用市场下载 QAPex

打开应用市场