AskData 内部揭秘：我们如何将 Token 消耗削减超过 90% | Pinecone

Pinecone 团队近日分享了其内部 AI 数据代理 AskData 的演进故事，展示了如何将 Token 消耗削减超过 90%，同时大幅提升查询效率。这一成果源于对数据仓库“最后一公里”问题的深刻理解与创新解决方案。

业务背景与挑战

随着 Pinecone 发展成为多产品、多渠道的企业，静态仪表板已无法满足决策需求。分析师成为瓶颈，临时问题往往被搁置，决策基于过时数据或直觉。核心问题在于：数据存储在仓库中，而数据的含义分散在 Slack 讨论、通话记录、CRM 系统等非结构化来源中。传统语义层难以跟上业务变化，导致自服务成本高昂。

V0 探索：编码代理的局限性

起初，团队尝试将 BigQuery、dbt 和内部文档直接接入 Claude 或 Cursor 等编码代理。虽然代理能生成 SQL，但面临根本性问题：同一问题不同答案、无共享学习机制、无反馈循环，以及每轮会话都需要大量 Token 来“重新学习”业务上下文。仅语义嵌入无法弥合自然语言与 SQL 之间的词汇鸿沟。

V1 构建：知识层的力量

V1 版本的核心是构建知识层，将非结构化上下文（如 Slack 线程、Gong 通话转录、dbt 注释等）通过 LLM 总结为 Markdown 文件，并结合 Pinecone 向量索引进行检索。最终知识库包含 234 个文件（约 18,000 行），由 Pinecone Assistant 提供服务。此外还有 5 个额外的检索表面。V1 上线后，3 个月内回答了 3,690 个问题，49% 的对话具有跟进特性，表明用户开始与数据进行自然交互。

V1 的瓶颈与 Nexus 的诞生

然而，V1 系统变得庞大：22 个工具、6 个检索表面、1,300 行 Airflow 代码、2,200 行策展代理代码，以及不断膨胀的系统提示。由于缺乏统一底层，跨源合成在每次查询时由代理运行时完成，导致大量 Token 消耗在“定位”阶段。例如，一个多部分查询需要 9 步和约 240,000 Token，其中 7 步用于确定表、列和过滤器。

Pinecone Nexus 正是为此设计。它提供单一策展管道，自适应知识表示，并内建人工反馈机制。团队从 V1 生产轨迹构建 eval 集，优化 Nexus 的编译循环。迁移后，Token 消耗下降 92%，查询轮次减少 78%，实现了更高效、更一致的数据查询体验。

Pinecone 表示，这一经验表明，AI 数据代理的真正瓶颈不在于代理循环本身，而在于其下的知识层。Nexus 正是这一问题的系统级解决方案。