AskData 内部:トークン消費を 90% 以上削減した方法 | Pinecone
Pinecone チームは、社内 AI データエージェント AskData の進化を共有しています。初期のコーディングエージェントの試行から、知識レイヤーを備えた V1 システム、そして Pinecone Nexus への移行により、トークン消費を 92% 削減し、クエリターンを 78% 短縮しました。記事は、ビジネス言語と SQL の間の「ラストマイル」の知識ギャップを埋めるための取り組みを詳述しています。
Pinecone チームは、社内 AI データエージェント AskData の進化の道のりを共有し、トークン消費を 90% 以上削減し、クエリのターン数を 78% 削減した方法を詳述しています。この成果は、データウェアハウスの「ラストマイル」問題に対する深い理解と革新的なソリューションに基づいています。
ビジネス背景と課題
Pinecone がマルチプロダクト、マルチチャネル企業に成長するにつれて、静的ダッシュボードでは不十分になりました。アナリストがボトルネックとなり、アドホックな質問は未解決のまま、意思決定は古いデータや直感に頼っていました。データはウェアハウスに存在しますが、その意味は Slack のスレッド、通話録音、CRM 記録などの非構造化ソースに散在しています。従来のセマンティックレイヤーはビジネスの変化に追いつけず、セルフサービスのコストは高くつきました。
V0 の探求:コーディングエージェントの限界
当初、チームは BigQuery、dbt、内部ドキュメントを Claude や Cursor などのコーディングエージェントに直接接続することを試みました。エージェントは SQL を生成できましたが、根本的な問題に直面しました:同じ質問に異なる回答、共有学習メカニズムの欠如、フィードバックループの不在、そして毎回のセッションでビジネスコンテキストを「再学習」するための高いトークン消費です。セマンティック埋め込みだけでは、自然言語と SQL の間の語彙ギャップを埋めることができませんでした。
V1 の構築:知識レイヤーの力
V1 の核心は、Slack スレッド、Gong の通話トランスクリプト、dbt コメントなどの非構造化コンテキストを LLM で要約したマークダウンファイルの知識レイヤーを構築し、Pinecone ベクトルインデックスと組み合わせて検索することでした。最終的な知識ベースは 234 ファイル(約 18,000 行)で構成され、Pinecone Assistant が提供しました。さらに 5 つの検索サーフェスがありました。V1 は 3 か月で 3,690 の質問に回答し、49% の会話がフォローアップを示し、ユーザーがデータと自然に対話し始めたことを示しています。
V1 のボトルネックと Nexus の登場
しかし、V1 システムは肥大化しました:22 のツール、6 の検索サーフェス、1,300 行の Airflow コード、2,200 行のキュレーターエージェントコード、そして膨張するシステムプロンプト。統一された基盤がないため、クロスソース合成は毎回のクエリでエージェントがランタイムで実行し、トークンの多くが「オリエンテーション」フェーズで消費されました。例えば、複数部分からなるクエリは 9 ステップと約 240,000 トークンを要し、そのうち 7 ステップがテーブル、列、フィルターの特定に費やされました。
Pinecone Nexus はこのために設計されました。単一のキュレーションパイプライン、適応型知識表現、ヒューマンインザループフィードバックメカニズムを提供します。チームは V1 のプロダクショントレースから eval セットを構築し、Nexus のコンパイルループを最適化しました。移行後、トークン消費は 92% 削減され、クエリターンは 78% 減少し、より効率的で一貫性のあるデータクエリ体験を実現しました。
Pinecone は、この経験から、AI データエージェントの真のボトルネックはエージェントループ自体ではなく、その下にある知識レイヤーであると述べています。Nexus はこの問題に対するシステムレベルのソリューションです。