许多企业团队都有一个共同的目标：为公司数据配备一个类似 ChatGPT 的分析师。
他们希望用自然语言提问，并从电子表格、数据库、仪表盘和内部报告中获取答案。他们渴望 AI 的速度，同时又不愿失去对敏感数据的控制。
这听起来很简单，直到你真正开始着手构建。
一个私有的 AI 数据分析系统不仅仅是一个连接到文件的聊天机器人。它需要受控的访问权限、可靠的计算能力、审计日志、模型服务，以及一套符合团队实际工作方式的用户体验。
企业所理解的私有 AI 数据分析
当一家公司要求进行私有 AI 分析时，通常意味着以下几点：
- 数据不应发送到未经批准的公开 AI 工具
- 用户只能看到他们被允许访问的数据
- 敏感文件应保留在经过批准的存储中
- 计算过程应该是可追溯的
- 提示词（Prompts）和输出结果应该是可审计的
- 模型应在经过批准的环境中运行
- 管理员应控制数据保留和日志记录
这就是为什么通用的 AI 演示往往令企业买家感到失望。演示只是回答了一个问题，而真正的系统必须在尊重身份验证、权限、数据血缘和合规性要求的前提下回答问题。
为什么仅有聊天机器人是不够的
聊天机器人可以总结文本、解释报告、起草回复。
但数据分析则完全不同。许多业务问题需要计算。
考虑这样一个问题：
为什么第三季度的毛利率下降了？哪个地区的“贡献”最大？
一个有用的答案需要多个步骤：
- 识别正确的收入和成本字段
- 应用毛利公式
- 筛选出第三季度的数据
- 与上一周期进行对比
- 按地区分组
- 计算各地区对变化的贡献度
- 结合证据解释结果
一个仅靠检索（Retrieval-only）的系统可能会找到一份提到毛利率的文档，但它无法可靠地计算出答案。
对于企业级分析，RAG（检索增强生成）很有帮助，但远远不够。
私有 AI 分析师的四个层级
一个实用的系统包含四个层级。
1. 界面层 (Interface layer)
这是用户提问和查看答案的地方。
它可以是：
- 电子表格界面
- 聊天侧边栏
- 仪表盘助手
- 内部 Web 应用
- 现有工具的 API
对于业务团队来说，电子表格界面通常是最自然的，因为这里本就是进行即时分析的地方。
2. 推理层 (Reasoning layer)
这是 LLM（大语言模型）或智能体（Agent）层。
它负责理解用户的问题、提出澄清性问题、选择工具、编写 SQL 或公式，并解释结果。
但不应将其视为计算的“事实来源”。
3. 执行层 (Execution layer)
这是实际进行数据处理的地方。
执行层可能使用：
- SQL 数据仓库
- DuckDB
- pandas 或 Polars
- 电子表格公式引擎
- BI 语义层
- 内部 API
这一层负责计算数值、连接表格、过滤行，并返回结构化的证据。
4. 治理层 (Governance layer)
这一层控制谁可以访问什么、记录什么、数据保留多久以及如何审核输出。
它包括：
- SSO（单点登录）和 RBAC（基于角色的访问控制）
- 行级和列级策略
- 审计日志
- 提示词和响应的保留控制
- 数据血缘
- 敏感数据脱敏
- 模型和工具权限
没有这一层，私有 AI 分析师就无法达到企业级标准。
RAG 与直接分析的对比
当问题涉及文本时，RAG 非常有用。
例如：
- 这项政策是怎么说的？
- 净收入是如何定义的？
- 哪份报告解释了流失率的计算方法？
当问题涉及数据时，则需要直接计算。
例如：
- 哪个地区导致了下滑？
- 按毛利排名的前五大客户是谁？
- 本月哪些支出异常？
- 这两次导出数据之间有什么变化？
最佳的企业架构会将两者结合。
使用 RAG 检索定义、业务背景和文档；使用 SQL、电子表格公式或 Python 计算结果；然后使用模型以通俗易懂的语言解释答案。
无法后期补救的治理需求
治理应该在早期就设计好。
一个私有 AI 数据分析系统应该能够回答：
- 谁提了问？
- 系统访问了哪些数据？
- 哪个模型给出的回答？
- 运行了哪些工具？
- 生成了什么查询或公式？
- 返回了什么结果？
- 是否对敏感数据进行了脱敏？
- 其他用户能否复现或审查该答案？
这些问题对于受监管的团队至关重要，对于正常的业务运营也同样重要。如果 AI 的回答影响了预测或高管报告，必须有人知道这个答案从何而来。
可观测性与评估
企业级 AI 分析需要的不仅仅是运行时间监控。
运营指标包括：
- 延迟
- Token 使用量
- 模型错误
- 工具调用失败
- 查询执行时间
- GPU 利用率
- 每个问题的成本
质量指标包括：
- 答案正确性
- 引用准确性
- SQL 合法性
- 公式合法性
- 幻觉事件
- 用户纠错率
- 澄清请求率
优秀的团队会建立一套包含真实问题和预期答案的测试集。在更改模型、提示词、工具或检索设置之前，他们会运行这些测试。
电子表格的特定需求
电子表格是一个特殊案例，因为它们灵活且往往格式混乱。
生产系统应能处理：
- 多个工作表
- 隐藏的工作表
- 公式
- 合并单元格
- 命名区域
- 批注
- 不一致的表头
- 导出的 CSV
- 类透视表汇总
- 本地日期和货币格式
这就是为什么电子表格 AI 不同于通用的文档问答。系统必须理解结构并执行计算，而不仅仅是总结文本。
自研还是采购
构建私有 AI 数据分析师可以获得最大的控制权，但需要大量的工程投入。许多团队在决定构建什么之前，会先规划他们所需的产品功能范围，从 AI 报表 到仪表盘交付：
- 模型服务
- 工作簿解析
- 提示词编排
- 数据连接器
- 沙箱化执行
- 访问控制
- 审计日志
- 评估
- 用户界面
采购或部署专门的工作流层可以缩短这一路径。
关键在于避免将整个战略锁定在单一模型上。模型更迭很快，而围绕公司数据构建的受控工作流才是持久的资产。
匡优数言 (RowSpeak) 的定位
匡优数言专为电子表格原生 AI 分析而设计，特别是当团队需要 AI 数据分析 却不想让用户直接面对原始模型端点时。
在私有架构中，匡优数言可以位于经过批准的模型端点和数据系统之上。模型提供推理能力，而匡优数言提供上传电子表格、提问、生成图表、产出摘要以及保持分析与底层数据关联的工作流。
这使得匡优数言不同于原始的模型服务器。它是将私有 AI 能力转化为业务团队可用的分析师体验的层级，类似于 AI 商业智能数据战略 中描述的工作流。
总结
私有 AI 分析师不是一个模型加一个提示词，而是一个受控的系统。
成功的模式是：
LLM 推理 + 确定性计算 + 权限感知的数据访问 + 可审计性 + 用户已经熟悉的工作流。
对于许多企业团队来说，这个工作流依然是从电子表格开始的。
来源与延伸阅读
- KServe: https://kserve.github.io/website/
- NVIDIA NIM: https://www.nvidia.com/en-us/ai-data-science/products/nim-microservices/
- dbt Semantic Layer: https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl
- Snowflake Cortex Analyst: https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst
- vLLM OpenAI-compatible server: https://docs.vllm.ai/en/latest/serving/openai_compatible_server/
