ノイズなしでセールスコールを記憶させるよう Hindsight に教え込んだ
文字起こしデータは、そのままでは記憶として使うにはノイズが多すぎる。
セールスコールのすべての言葉をAIに流し込んでも、得られるのは「ガラクタ入れ」であって、インテリジェンスではない。ほとんどのシステムが失敗するのは、すべてを記憶しようとするからだ。
これを解決するために、私は Deal Intelligence Agent を構築した。これは単に文字起こしをするのではない。「記憶」するのだ。
Next.js, FastAPI, Supabase, Hindsight, そして Groq を使用した。役割分担は以下の通りだ：
- Supabase は事実を保存する。案件、会議、具体的なアクションアイテムを保持する。正確なクエリにはこれを使用する。
- Hindsight は記憶を保存する。パターンや戦略を保持する。意味的な想起（semantic recall）にはこれを使用する。
エージェントの有用性を保つため、記憶を3つのタイプに整理した：
• エピソード記憶：特定の会議で何が起きたか。 • 意味記憶：複数の会議を通じて現れるパターン。 • 手続き記憶：特定の案件に対して実際に効果のある戦略。
また、タイミングに関するルールも追加した。エージェントは「謙虚」である必要がある。
会議が1回の場合は、エージェントは起きたことだけを記録する。2回目以降はパターンを探し始める。3回目になって初めて戦略を提案する。これにより、AIが早すぎる段階で誤った推測を行うのを防いでいる。
その結果、会議前のブリーフィングに劇的な違いが生まれた。
一般的なAIはこう言う：「価格に関する反論に備えてください。」
私のエージェントはこう言う：「CFOの Sarah Chen は、2回目の会議でエンタープライズ価格を拒否しました。しかし、4回目の会議で段階的な価格設定を提案した後は態度が軟化しました。今日は段階的な構成を軸に進めてください。」
これが、アシスタントとパートナーの違いだ。
私の主な教訓：
- 文字起こしをそのまま記憶として使わない。まず事実を抽出すること。
- 記憶のタイプにゲート（制限）を設けること。1回のコールでパターンを推測させてはいけない。
- 2つのデータベースを使用すること。事実はリレーショナル・ストアに、コンテキストはベクトル・ストアに保存する。
- 名前は重要だ。「顧客」の反論を知るよりも、特定の個人の反論を知る方が価値が高い。