关于 AskTable
选型与试用
判断 AskTable 是否适合，核对价格、并发、准确率和上线前提。
使用指南 · 模块: product · 使用者 / 管理人员 · 部署形态：Cloud / 私有部署 · 已确认产品版本：资料未说明 · 来源：编辑整理
先给结论：AskTable 适合「有明确业务问题、数据可以开放、有人对口径负责」的团队；不适合被当成通用聊天机器人、RPA，或传统 BI 的替代品。
下面的数字用于选型会和 POC 立项，不是对所有客户、所有问题的无条件承诺。价格与活动以官网当期页面和合同为准。
快速判断
| 更适合 | 暂时不适合 |
|---|---|
| 有明确业务 owner 的业务团队，或大企业里的小 BU | 没有业务 owner，只有 IT 或采购在推动 |
| 有 1～2 个明确数据源，能提供样例数据和口径 | 数据不能出库，也不能部署到内网 |
| 每天或每周有高频问数，问题会追问、会换口径 | 只需要固定报表、大屏或订阅 |
| 能指定 3 个核心指标、5 个高频问题 | 只想做通用聊天、文档问答、RPA |
| 愿意用 2 周做 100 题验收 | 要求 100% 准确率，或不愿定义成功标准 |
和 BI 的边界
三句话：
- 固定报表、大屏、订阅和强权限发布，继续用 BI。
- 临时问题、追问、换口径、要解释，交给 AskTable。
- BI 的指标层和数据集是 AskTable 的上游；AskTable 不建数仓、不做 ETL、不写回 BI。
| 维度 | 传统 BI | AskTable |
|---|---|---|
| 主要问题 | 已知指标的稳定展示 | 未知问题的即时探索 |
| 使用方式 | 拖拽、固定报表、订阅 | 自然语言提问和连续追问 |
| 建设重点 | 数仓、指标模型、报表体系 | 数据语义、口径、权限和题集 |
| 结果形态 | 看板、报表、大屏 | 表格、图表、结论和可追溯 SQL |
| 不替代什么 | — | 不替代数仓、BI 平台和写回流程 |
价格与套餐边界
Cloud（SaaS）
| 套餐 | 月付 | 年付 | 人数上限 |
|---|---|---|---|
| 免费体验 | 0 元 | — | 体验额度 |
| 3 人组织（推荐） | 200 元/月 | 1680 元/年 | 3 人 |
| 10 人及以内 | 600 元/月 | 4680 元/年 | 10 人 |
| 20 人及以内 | 999 元/月 | 8680 元/年 | 20 人 |
- 管理员、成员、访客都计入人数。
- 促销期已付费组织在合理使用范围内不限 AI 问答次数；活动结束或调整时，以官网当期页面和合同为准。
- 如果组织页面显示 credits，按「周期额度优先、加购余额其次」消耗；周期额度不结转，具体额度以组织页面和合同为准。
- Cloud 按组织套餐授权，私有部署按企业许可证授权，两者的功能和容量都以实际授权为准。
价格核对日期：2026-10-22。以 官网套餐页 为准。
私有部署
- 价格由商务按部署环境、数据规模、交付范围和服务周期报价，没有公开统一价。
- 未激活企业许可证时按体验版运行：最多 3 个用户，不启用分析画卷。
- 企业许可证按用户容量签发，具体功能、容量和有效期以许可证为准。
- 最低部署配置：4 核 CPU、16G 内存、100G 磁盘；推荐配置见下一节。
怎么开始试用
- Cloud：在 cloud.asktable.com 注册，先用免费体验额度连接自己的数据并提问；需要邀请同事、组织协作和权限管理时升级付费套餐。
- 私有部署：先用体验版验证，最多 3 个用户、不启用分析画卷；通过 POC 后再按用户容量购买企业许可证。
- 试用时不要只看演示数据。选 3～10 张真实核心表，按下面的 100 题方法记录通过率，才能判断是否适合上线。
并发 benchmark：8C32G 能支持多少人
先分清三个数：
| 指标 | 含义 |
|---|---|
| 并发分析任务 | Worker 正在执行的 Agent 任务数，决定同时有多少个问题在算 |
| 并发用户 | 同时提问或等待回答的业务人员数，取决于每人提问频率和单题耗时 |
| 应用层 QPS | 服务端受理提问的速率，返回 202 后进入队列；不是完整回答速率 |
推荐配置与结果
8C32G 是推荐机器规格。产品默认是 1 个 Worker、每个 Worker 10 个任务；要覆盖 20 人同时提问，需要把 Worker 调到 2 个，形成 20 个并发分析任务。
| 项目 | 8C32G 规划建议（2 个 Worker） |
|---|---|
| CPU / 内存 | 8 核 / 32G |
| Web 进程 | 1 |
| 后台 Worker 进程 | 2 |
| 每个 Worker 并发任务 | 10 |
| 并发分析任务 | 20 |
| 任务队列 | 50，满后返回 503「系统繁忙」 |
| 模型侧并发 | 不低于 10；建议 20（按 1:1 预留） |
| PostgreSQL 连接 | 默认 100 够用（应用峰值 71，含运维余量 81） |
| 建议同时提问人数 | 20 人以内（每人同时最多 1 个问题在算） |
| 适用场景 | 20 人以内日常问数、短时集中提问 |
保留默认 1 个 Worker 时只有 10 个并发分析任务，建议按 10 人以内规划；20 人场景先把 AT_WORKER_NUM_PROCS 调到 2。
已验证环境与规划上限
| 环境 | 并发分析任务 | 同时提问人数 | 应用层受理能力 | 证据 |
|---|---|---|---|---|
| 8C32G 规划（2 个 Worker） | 20 | 20 人以内 | 未单独承诺 | 容量规划，未做同规模压测 |
| 16C64G 测试环境（4 个 Worker） | 40 | 20 人同时发起 | 10 提问/秒（短时受理） | 客户标准测试环境验证通过 |
8C32G 的 20 人是按任务数做的容量规划，不是同规模压测结果。真正验证过 20 人同时发起的是 16C64G 环境：应用层可受理 10 个提问/秒，20 名业务人员同时发起自然语言问数，通过排队机制平滑处理，验证结果达标。这里的 10 QPS 是受理能力，不是每秒完成 10 个完整回答。
某集团客户的采购平台遇到过模型并发瓶颈：初始模型 API Key 只有 5 个并发，高峰期不够用；把模型并发提高到 20 个以上后，后端按 16 核、4 个 Worker、每个 Worker 10 个任务配置，总计可同时执行 40 个任务。
持续吞吐怎么算
持续完成速率 ≈ 并发分析任务数 ÷ 平均单题耗时举例：20 个并发任务、平均每题 30 秒，持续完成约 40 题/分钟。单题耗时受模型、SQL 复杂度、数据源响应和是否调用 Python 影响，不能用 10 QPS 直接推算。
扩容公式
并发分析任务 = Worker 进程数 × AT_WORKER_MAX_JOBS
模型并发 ≥ 并发分析任务数 × 50%，建议按 1:1 预留
应用连接峰值 = 31 + 20 × Worker 进程数（启用 Workbook 时）连接公式按默认启用 Workbook 计算；模型并发比例按已验证案例（40 个任务配 20 个模型并发）整理，不是产品硬限制。
- 2 个 Worker：应用连接峰值 71，加 10 个运维连接为 81，默认
max_connections=100够用。 - 4 个 Worker：应用连接峰值 111，加 10 个运维连接为 121；还要给 PostgreSQL 的保留连接留出余量，建议把
max_connections设到 150 以上，否则可能出现DATABASE_BUSY。 - 加机器或加 Worker 之前，先确认模型 API 并发额度。模型侧只有 5 个并发时，后端加到 40 个任务也会堵在模型调用上，表现为 429、
LLM_RATE_LIMIT或超时。 - DeepSeek 官方 API 的 RPM、TPM 和并发额度随账号、模型和时段变化，以控制台账单为准；采购前至少申请到并发任务数一半、最好与任务数 1:1 的额度。
响应时间与单题成本
| 项目 | 参考值 | 说明 |
|---|---|---|
| 快速模式 | 10～30 秒 | 回答更快，分析更浅，适合结果明确的问题 |
| 普通对话 | 1～2 分钟 | 默认深度思考，工具调用和多步分析更完整 |
| 模型算力成本 | 平均约 0.05 元/题 | 以 deepseek-flash 官方 API 价格为例，只算模型调用 |
回答时间受模型、SQL 复杂度、数据源响应、是否调用 Python 和排队情况影响；题目越复杂、工具轮次越多，时间越长。模型成本按输入输出 token、工具轮次和实际单价计费，5 分钱是典型题目的平均值，不是报价；服务器、网络、交付和运维成本另计。
按 20 个并发分析任务估算，快速模式下持续完成约 40～120 题/分钟，普通对话约 10～20 题/分钟；这是按任务数估算的结果，实际受队列和数据源响应影响。
准确率 benchmark：实测 99 与门槛 95
准确率使用「样本通过率」，不是模型自评，也不是 SQL 相似度：
样本通过率 = 人工确认正确的问题数 ÷ 已核对的问题数| 项目 | 结果 |
|---|---|
| 测试环境 | 8C32G |
| 模型 | deepseek-flash（DeepSeek 官方 API） |
| 题集 | 300 题，数据治理后 |
| 样本通过率 | 99% |
| 建议上线门槛 | 不低于 95% |
这组结果说明：在题集、数据和语义版本固定的前提下，治理后的 300 题可以达到 99%。把 95% 作为验收下限、99% 作为治理充分后的可达值，比承诺一个固定数字更可靠。它不代表任意新问题、任意新表都能达到 99%，也不代表开放式分析的文字结论不需要人工复核。
建议低于 95% 时不上线，先补数据语义和题集再复测；95%～99% 之间先上线试点，但要把未通过的问题按「没理解、没说清、结果错」分类，逐类修复。
另一个制造业财务样例使用 3 张治理后的结果表、20 道固定题，20/20 通过。样本只有 20 题，只说明治理后的可达性，不作为通用准确率。同一批数据里的开放式经营洞察曾出现文字计数错误（把 5/8 写成 6/8），这类内容不计入固定题集，发布前要人工核对。
准确率、数据治理深度和本体/语义层建模没有脱离数据的通用答案。与其在文档里讨论方法论，不如通过 AskTable 官网 的「联系我们」入口做一次 POC 范围沟通：带上 1～2 个数据源、3～10 张核心表和 20～30 个真实问题，一起确认要补哪些语义、题集怎么出、通过标准是多少，再决定是否投入完整的语义层建设。文档给的是通用清单，能不能达到 95% 要在你的数据上实测。
达到高准确率的数据治理前提
| 前提 | 做到什么程度 | 在哪里做 |
|---|---|---|
| 范围收敛 | 先做 1 个主题、3～10 张核心表，不把整个数仓一次开放 | 数据源选表 |
| 表与字段备注 | 写清业务含义、单位、枚举、编码和实际存储方式 | 表与字段备注 |
| 指标口径 | 收入、成本、毛利、逾期等指标有唯一计算公式和时间语义 | 业务文档 |
| 关联关系 | 主键、外键、事实表与维表的关系明确 | 表与字段备注 |
| 值映射 | 简称、别名、编码值能映射到数据库实际值 | AI 索引 |
| 已验证问答 | 准备 50～100 条「问题 + 正确 SQL」样本 | 管理数据源、文件与训练集 |
| 权限边界 | 角色、行级过滤、隐藏字段先定义再开放 | 权限与数据范围 |
| 数据质量 | 主键唯一、快照一致、空值和重复值有处理规则 | 数据源侧治理 |
| 业务 owner | 有人能对「哪个答案算对」做最终判断 | 项目组织 |
治理不到位时，先不要用「换更大的模型」解决。多数错误来自字段含义不清、口径不唯一、枚举值对不上或关联关系错误。
变量取值怎么补
用户问的是「华东」，库里存的是 E01；问的是「Mate 40」，库里是「HUAWEI Mate 40 Pro 5G」。这类不一致会让模型生成正确的 SQL 结构，却过滤不到数据。
- 先列高频筛选值：把业务里最常用的 10～20 个区域、产品、状态、渠道值列出来，逐个用自然语言问一次。
- 字符串列：在字段上打开 AI 索引，让简称和实际值建立检索关系；字段说明里同时写清枚举含义。
- 数字、日期编码：AI 索引不处理数字和日期，改用字段备注、业务文档或映射表说明。
- 约束：单数据源默认 10 个索引字段，单字段去重值默认上限 50000；私有部署需要先部署 AI 搜索，企业版授权才开放该能力。
索引只是辅助，值映射是否生效，以同一问题的结果表为准。
100 题 POC 验收
题集怎么选
| 类型 | 建议占比 | 说明 |
|---|---|---|
| 单轮事实题 | 70% | 收入、毛利、订单、库存、回款等高频问题 |
| 多轮追问 | 20% | 换时间、换维度、下钻、对比 |
| 模糊问题 | 10% | 缺时间范围或口径，考察澄清能力 |
题目从真实工作里取，不要只用演示数据。标准答案来自业务系统、财务报表或人工核算；有争议的题由业务 owner 裁定。
通过标准
- 100 题全部核对，覆盖率 100%。
- 样本通过率不低于 95%。
- 无权限越界、无敏感字段泄漏、无 P0 数据错误。
- 同一题连续跑两次，口径和结果稳定。
- 99% 是治理充分后的实测结果，不作为任意题集的验收承诺。
两周节奏
| 时间 | 做什么 |
|---|---|
| 第 1～3 天 | 接 1～2 个数据源，选 3～10 张表，补字段备注和指标口径 |
| 第 4～7 天 | 用 50 题跑第一轮，按失败类型修语义、补训练样本 |
| 第 8～12 天 | 用 100 题复测，处理权限、口径和复杂关联问题 |
| 第 13～14 天 | 业务 owner 验收，输出通过率和上线建议 |
POC 的交付物不是一份技术报告，而是：100 题清单、标准答案、逐题通过/失败、失败原因、已修改的语义项，以及是否上线的结论。
上线前提与不承诺
需要提前确认：
- 模型满足工具调用、JSON mode、
tool_choice=auto，上下文窗口不小于 128K，参数规模不低于 35B；自建模型还要能稳定支撑并发分析任务，至少按任务数一半的并发、建议 1:1 准备。 - 私有部署服务器能访问模型服务；完全离线时先准备内网模型服务。
- 数据源账号只读，网络、白名单和查询超时已配置。
- 业务 owner、项目管理员和首批 5～10 名试用用户已确定。
- 已准备 100 题验收集和标准答案。
不承诺：
- 不承诺 100% 准确率，也不承诺任意新问题都达到 99%。
- 不承诺 10 个完整回答/秒；10 QPS 指应用层受理能力。
- 不承诺所有问题都在 10～30 秒或 1～2 分钟内完成；响应时间受复杂度、模型、数据源和排队影响。
- 不承诺无限并发；并发受 Worker 任务数、模型额度和数据源响应共同限制。
- 不承诺私有部署的固定价格；按部署环境、数据规模、交付范围和服务周期报价。
- 不承诺替代数仓、BI 平台、ETL 或写回流程。
- 不承诺所有数据源、所有查询都有相同响应速度。
选型常见问答
| 问题 | 可直接回复 |
|---|---|
| 8C32G 能支持多少人同时用？ | 把 Worker 调到 2 个、每个 10 个任务，共 20 个并发分析任务，建议 20 人以内同时提问；沿用默认 1 个 Worker 时按 10 人以内规划；超过 20 人按 16C64G、4 个 Worker、40 个任务扩容。 |
| 10 QPS 是每秒 10 个完整回答吗？ | 不是。10 QPS 是应用层受理提问的速率，提问进入队列后由 Worker 执行；完整回答速度取决于并发任务数和单题耗时。 |
| 回答要多久？ | 快速模式约 10～30 秒，普通对话约 1～2 分钟；复杂 SQL、多轮工具调用、数据源慢或排队时会更长。 |
| 每条问题要多少模型成本？ | 以 deepseek-flash 官方 API 价格为例，平均约 0.05 元/题；只算模型调用，不含服务器、网络、交付和运维，实际随题目复杂度和工具轮次变化。 |
| 准确率能保证 99% 吗？ | 不能对所有问题保证。治理后的 300 题实测样本通过率 99%，建议上线门槛是 95%；新问题、新表和数据质量问题都会影响结果。 |
| 怎么判断我们的数据能达到 95%？ | 只能实测。联系服务团队，用你的 1～2 个数据源和 100 题验收集确认治理项与通过标准；文档不替代这次 POC 实测。 |
| 需要先做本体或语义层建模吗？ | 不一定。先从 3～10 张核心表和 20～30 个真实问题开始；要不要建、建多深取决于数据现状。联系我们约定 POC 范围，用真实数据判断，比先讨论方法论更有效。 |
| 为什么我们试用时感觉不准？ | 先查字段备注、指标口径、枚举值、关联关系和数据质量；多数错误不是模型能力问题，而是语义没有补齐。 |
| Cloud 多少钱？ | 当前官网价：3 人 200 元/月或 1680 元/年，10 人 600 元/月或 4680 元/年，20 人 999 元/月或 8680 元/年；促销期合理使用范围内不限问答次数，以合同为准。 |
| 私有化多少钱？ | 没有公开统一价，按部署环境、数据规模、交付范围和服务周期报价；未激活许可证时最多 3 个用户，不启用分析画卷。 |
| 和 BI 有什么区别？ | BI 负责固定报表、大屏和订阅；AskTable 负责临时问题、追问和解释。它接在 BI 的指标层和数据集之上，不替代数仓或 BI 平台。 |
| 模型并发不够会怎样？ | 任务会堵在模型调用上，表现为排队、429、LLM_RATE_LIMIT 或超时；先把模型 API 并发提高到至少任务数的一半（建议 1:1），再加 Worker。 |
| 上线前要准备什么？ | 1～2 个数据源、3～10 张核心表、字段和指标口径、50～100 条已验证问答、100 题验收集，以及能裁定对错的业务 owner。 |