# 选型与试用 判断 AskTable 是否适合，核对价格、并发、准确率和上线前提。 使用指南 · 模块: product · 使用者 / 管理人员 · 部署形态：Cloud / 私有部署 · 已确认产品版本：资料未说明 · 来源：编辑整理 先给结论：AskTable 适合「有明确业务问题、数据可以开放、有人对口径负责」的团队；不适合被当成通用聊天机器人、RPA，或传统 BI 的替代品。 下面的数字用于选型会和 POC 立项，不是对所有客户、所有问题的无条件承诺。价格与活动以官网当期页面和合同为准。 ## 快速判断 | 更适合 | 暂时不适合 | | ---------------------------- | ----------------------- | | 有明确业务 owner 的业务团队，或大企业里的小 BU | 没有业务 owner，只有 IT 或采购在推动 | | 有 1～2 个明确数据源，能提供样例数据和口径 | 数据不能出库，也不能部署到内网 | | 每天或每周有高频问数，问题会追问、会换口径 | 只需要固定报表、大屏或订阅 | | 能指定 3 个核心指标、5 个高频问题 | 只想做通用聊天、文档问答、RPA | | 愿意用 2 周做 100 题验收 | 要求 100% 准确率，或不愿定义成功标准 | ## 和 BI 的边界 三句话： 1. 固定报表、大屏、订阅和强权限发布，继续用 BI。 2. 临时问题、追问、换口径、要解释，交给 AskTable。 3. 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。以 [官网套餐页](https://www.asktable.com/zh-CN/pricing) 为准。 ### 私有部署 - 价格由商务按部署环境、数据规模、交付范围和服务周期报价，没有公开统一价。 - 未激活企业许可证时按体验版运行：最多 3 个用户，不启用分析画卷。 - 企业许可证按用户容量签发，具体功能、容量和有效期以许可证为准。 - 最低部署配置：4 核 CPU、16G 内存、100G 磁盘；推荐配置见下一节。 ### 怎么开始试用 - Cloud：在 [cloud.asktable.com](https://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 个任务。 ### 持续吞吐怎么算 ```text 持续完成速率 ≈ 并发分析任务数 ÷ 平均单题耗时 ``` 举例：20 个并发任务、平均每题 30 秒，持续完成约 40 题/分钟。单题耗时受模型、SQL 复杂度、数据源响应和是否调用 Python 影响，不能用 10 QPS 直接推算。 ### 扩容公式 ```text 并发分析任务 = 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 相似度： ```text 样本通过率 = 人工确认正确的问题数 ÷ 已核对的问题数 ``` | 项目 | 结果 | | ------ | ------------------------------- | | 测试环境 | 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 官网](https://www.asktable.com/zh-CN) 的「联系我们」入口做一次 POC 范围沟通：带上 1～2 个数据源、3～10 张核心表和 20～30 个真实问题，一起确认要补哪些语义、题集怎么出、通过标准是多少，再决定是否投入完整的语义层建设。文档给的是通用清单，能不能达到 95% 要在你的数据上实测。 ## 达到高准确率的数据治理前提 | 前提 | 做到什么程度 | 在哪里做 | | -------- | ----------------------------- | ----------------------------------------------------- | | 范围收敛 | 先做 1 个主题、3～10 张核心表，不把整个数仓一次开放 | 数据源选表 | | 表与字段备注 | 写清业务含义、单位、枚举、编码和实际存储方式 | [表与字段备注](https://docs.asktable.com/data/semantics) | | 指标口径 | 收入、成本、毛利、逾期等指标有唯一计算公式和时间语义 | [业务文档](https://docs.asktable.com/agent/documents) | | 关联关系 | 主键、外键、事实表与维表的关系明确 | [表与字段备注](https://docs.asktable.com/data/semantics) | | 值映射 | 简称、别名、编码值能映射到数据库实际值 | [AI 索引](https://docs.asktable.com/data/ai-search) | | 已验证问答 | 准备 50～100 条「问题 + 正确 SQL」样本 | [管理数据源、文件与训练集](https://docs.asktable.com/data/manage) | | 权限边界 | 角色、行级过滤、隐藏字段先定义再开放 | [权限与数据范围](https://docs.asktable.com/permissions) | | 数据质量 | 主键唯一、快照一致、空值和重复值有处理规则 | 数据源侧治理 | | 业务 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。 | ## 下一步 - 评估准确率和 POC 范围：带着数据源和真实问题联系服务团队，约定治理项、题集和通过标准 - 第一次使用：走[完成第一次提问](https://docs.asktable.com/getting-started/quickstart) - 私有部署：看[私有部署（Docker）](https://docs.asktable.com/deploy/docker)和[运维与容量规划](https://docs.asktable.com/deploy/operations) - 补数据语义：看[表与字段备注](https://docs.asktable.com/data/semantics)和[业务文档](https://docs.asktable.com/agent/documents) - 配置模型：看[配置大模型](https://docs.asktable.com/admin/models) - 核对套餐和用量：看[套餐与用量](https://docs.asktable.com/organization/plans-and-usage)和[商业授权](https://docs.asktable.com/admin/license)