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 正是這一問題的系統級解決方案。