属人的な知識から即座の回答へ: Databricks 上での Reffy の構築

適切なタイミングで適切な顧客事例を見つけることは、驚くほど困難な作業です。従業員の生産性を向上させるため、私たちは Reffy を構築しました。これは、ユーザーが 2,400 を超える Databricks の顧客リファレンスを検索・分析し、パーソナライズされた回答、事例横断的な分析、引用などを提供できるアプリです。最初の 2 か月で、Databricks の営業およびマーケティング部門の 1,800 人以上が Reffy で 7,500 以上のクエリーを実行しました。これにより、より関連性が高く一貫したストーリーテリング、迅速なキャンペーンの実行、そして顧客による証明が大規模に活用されているという自信につながります。これらの事例を検索しやすく理解しやすいものにすることで、私たちは顧客リファレンスにまつわる属人化した知識の問題を解決し、長年にわたってそれらを収集してきた多くの人々の貴重な仕事の価値を解き放ちました。

この記事では、Reffy 開発の動機、完全な Databricks ソリューション、組織への影響、そして社内でさらにスケールさせるための計画について詳しく説明します。

属人的な知識を民主化するという課題

「他に誰がこれをやったことがありますか？」は、すべての営業担当者が耳にする質問です。見込み顧客はあなたのピッチに興味をそそられますが、次に進む前に、彼らと同じような道をすでに歩んだ顧客という証拠を求めます。それに答えるのは簡単なはずです。

当社のマーケティングチームにとって、顧客事例はキャンペーン、製品ローンチ、広告、PR、アナリストブリーフィング、経営層向け広報といった、ほぼすべての活動における中核的なインプットです。そうした事例を簡単に見つけたり評価したりできない場合、価値の高い参照が過度に使用され、新しいユースケースや業界が見過ごされ、マーケティングの有効性が暗黙知によって制限されるなど、現実的な問題が深刻化します。

Databricksには、YouTubeでの何千もの講演、databricks.com上の導入事例、社内スライド、LinkedInの記事、Mediumの投稿などがあります。その中には、カナダでリアルタイムの不正検知を行っている金融サービス会社、レガシーなデータウェアハウスを置き換えた小売業者、GenAIをスケーリングしている製造業者など、完璧な参照があるのです。しかし、それを見つけるのは？そこで頓挫するのです。事例は十数個のプラットフォームに散在しており、統一された検索機能はありません。何かを見つけても、信頼できるビジネス成果があるのか、それとも単なる曖昧な主張なのか、それが強力なものかどうかをすぐには判断できません。

そこで人々は、Slackでマーケティングチームにメッセージを送ったり、うろ覚えのフォルダを探し回ったり、誰かが使えるものを見つけてくれるまで周りに聞いて回ったりします。時にはゴールドが見つかることもあります。しかし、ほとんどの場合は「まあまあ」で妥協するか、完全に諦めてしまいます。完璧なストーリーがずっとそこにあったかもしれないとは知らずに。

営業チームとマーケティングチームが、最も関連性の高い顧客事例を見つけ出すためのより良い方法が明らかに必要でした。

Reffy: Databricks 上のフルスタックソリューション

この問題を解決するために、私たちはすべてのストーリーを1つのテーブルに統合して分類し、RAGベースのエージェントを使用して検索を強化します。これらすべてが、vibe-codedなDatabricksアプリを通じて提供されます。このアーキテクチャは、Databricksプラットフォーム全体に及びます。Lakeflow JobsがETLパイプラインをオーケストレーションし、Unity Catalogがデータをガバナンスし、ベクトル検索が検索を強化し、Model Servingがエージェントをホストし、Lakebaseがリアルタイムの読み取りと書き込みを処理し、Databricks Appsがフロントエンドを提供します。詳細を見ていきましょう。

データソースと ETL

私たちのパイプラインは、Lakeflow Jobsでオーケストレーションされる一連のDatabricks Notebooksで定義されています。このパイプラインは、すべてのデータソースからストーリーのテキストを収集することから始まります。標準的なPythonのウェブスクレイピングライブラリを使用して、YouTubeのトランスクリプト、LinkedIn/Mediumの記事、そしてdatabricks.com上のすべての公開顧客事例を収集します。また、Google Appsスクリプトを使用して、数百もの社内Googleスライドやドキュメントのテキストを1つのGoogleスプレッドシートに統合します。これらのソースはすべて、基本的なメタデータとともに処理され、Unity Catalog (UC) の「Bronze」Delta Lakeテーブルに保存されます。

今ではすべての事例を一か所にまとめていますが、その質に関する知見はまだ得られていません。これを改善するため、私たちは AI Functions を介して、各ストーリーに（当社のバリューチームが開発した）厳格な 31 項目のスコアリングシステムを適用し、テキストを分類しています。私たちは Gemini 2.5 にプロンプトを出し、ビジネス上の課題、ソリューション、成果の信頼性、そしてなぜ Databricks が独自の価値を提供できたのかを特定することで、ストーリー全体の品質を判断させています。このようにストーリーを評価することで、品質の低いものを Reffy から除外することもできます。プロンプトはまた、国や業界、使用された製品、競合、引用などの主要なメタデータを抽出し、ストーリーが一般公開可能か社内限定かに基づいてタグ付けします。この強化されたデータセットは、UC の「シルバー」テーブルに保存されます。

ETLの最終ステップでは、スコアの低いストーリーを除外し、ストーリーの重要な要素を連結した新しい「summary」列を作成します。考え方はシンプルです。この「ゴールド」テーブルをDatabricks ベクトル検索インデックスに同期します。summary列には、LLMが顧客事例をクエリに一致させるために必要なすべての重要情報が含まれています。

エージェントAI

DSPy フレームワークを使用して、ハイブリッドキーワード検索とセマンティック検索で最も関連性の高い顧客リファレンスを検索できる、ツール呼び出しエージェントを定義します。私たちは DSPy が大好きです！ DSPy で構築されたエージェントは、毎回 Model Serving endpoint に再デプロイすることなく、Databricks ノートブックで簡単に反復テストができるため、開発サイクルが短縮されます。その構文は他の一般的なフレームワークと比較して非常に直感的であり、優れた プロンプト最適化コンポーネントが含まれています。まだ試していない方は、ぜひ DSPy をチェックしてみてください。

顧客事例エージェントは、ユーザーの入力に応じて、超高速のキーワード検索と、理由付けを伴う長文のLLM応答を使い分けるように構築されています。質問をすれば、ソース付きの熟考された回答が得られますが、いくつかのキーワードを入力するだけなら、Reffyは2秒未満で上位の結果を返します。また、Vector Search用のDatabricks re-rankerを使用して、RAGからの結果を改善しています。

バランスの取れたプロフェッショナルな応答を保証するため、次のシステムプロンプトを使用します。

エージェントは MLflow にログ記録され、当社の Agent Framework を使用して Databricks Model Serving にデプロイされます。ほとんどの処理はモデルプロバイダー側で行われるため、小規模な CPU インスタンスにデプロイするだけで済み、GPU と比較してインフラコストを節約できます。

Databricks アプリ

データのクレンジングとインデックス作成が完了し、エージェントが正常に動作するようになったので、これらをすべてまとめて、技術者以外のユーザーがアクセスできるアプリを構築します。フロントエンドには React、バックエンドには FastAPI Python を採用しました。Reactはブラウザで美しく軽快に動作し、Model Serving endpointからのストリーミング出力をサポートしています。FastAPI を使用すると、アプリで Databricks Python SDK のすべてのメリットを活用できます。具体的には次のとおりです:

• 統合認証 — 開発中にローカルで認証する場合と、Databricks Appsにデプロイする場合でコードの変更は不要です。アプリはローカル認証と同じ環境変数を持つため、コードはシームレスに機能します。
• 広範なAPIカバレッジ — Model Servingの呼び出し、SQLクエリーの実行など、Databricks Workspaceから必要となりうるあらゆる操作を、すべて単一のSDKを通じて行うことができます。

Reffy は主にチャットアプリであるため、Lakebase を使用して、高速な読み書き、品質保証、そしてユーザーが再訪したり新しい会話を開始したりした際のきめ細やかなフォローアップのために、すべての会話履歴、ログ、ユーザー ID を永続化しています。

継続的なモニタリングとメトリクス

Lakebaseからのログは、別のLakeflow Jobで処理され、デイリーアクティブユーザー数や平均応答時間などの主要なメトリクスがAI/BI Dashboardに表示されます。このダッシュボードには最近の入力と応答も表示され、さらに1ステップ進んで、別のAI Functionを適用し、入力と応答を最近のテーマやギャップ分析として要約します。どの顧客事例が人気で、どこにギャップがある可能性があるかを理解したいのですが、Reffyから収集するログがまさにその役に立っています。たとえば、ユーザーがDatabricksの最新製品であるAgent BricksとLakebaseに関するストーリーを特に探していることがわかりました。

ダッシュボードの下部には、業界やコンテンツタイプごとの事例の品質に関する静的分析を掲載しています。

開発セットアップに関する注意点

プロジェクト開発のほとんどはCursorで行われ、前述のとおり、Databricks CLIとSDK間の統合認証によってシンプルさが保たれています。CLI経由で一度サインインすれば、SDKを使用するReffyのすべてのローカルビルドが認証されます。Databricks Appsでテストしたいときは、CLIを使用して最新のコードをワークスペースに同期し、アプリをデプロイします。Databricks Appsは、ローカルで設定したものと同じ認証用の環境変数をチェックするため、SDKに依存するModel ServingやSQL Warehouseへの呼び出しがそのまま機能します。私たちの反復的な開発ループは次のようになります。

1. CLI でワークスペースにサインイン
2. Cursor でコードを作成
3. ローカルでテスト
4. コードをワークスペースに同期してアプリをデプロイ
5. Databricks アプリでテスト

最後に、適切なCI/CDと移植性を確保するために、Databricks Asset Bundlesを使用して、Reffyが使用するすべてのコードとリソースを単一のパッケージにまとめます。このバンドルは、GitHub Actionsを介してターゲットの本番ワークスペースにデプロイされます。

学んだこと

Databricks内の複数のチームは、この問題の一部をすでに個別に解決しており、自然と最もエキサイティングな作業であるAIレイヤーに引き寄せられていました。しかし、データエンジニアリングは依然として中核をなしており、ETLを正しく実行し、事例の品質をスコアリングし、効果的な検索のためにデータを構造化することは、エージェント自体と同じくらい重要であることが証明されました。

コラボレーションも同様に不可欠でした。顧客事例は、営業、マーケティング、フィールドエンジニアリング、PRなど、組織のほぼ隅々にまで及び、そのすべてが役割を果たしています。これらのグループと強力なパートナーシップを築くことで、製品とそれを支えるデータの両方が形成されました。

次のステップ

アプリケーションのフロントエンドはすぐに価値を提供しますが、本当の力は Reffy を Databricks 全体の他のソリューションと接続することで生まれます。私たちはその接続性を API と MCP サーバーを通じて提供する計画です。これにより、各チームは既存のワークフローやツール内から直接カスタマーインテリジェンスにアクセスできるようになります。

DatabricksとLakebaseを使用することで、何千人ものユーザーが長期にわたってReffyをどのように利用しているかを理解することもできます。これらの知見によって、ツールを継続的に改善し、この成長するエコシステムに追加されるストーリーを思慮深く形成することが可能になります。

現在、顧客参照の発見に苦労しているDatabricksのチームにとって、Reffyはこれらの機能が統合されたときに何が可能になるかについての具体的な例を提供します。Databricksで独自のエージェントアプリの構築を開始するには、Databricks Apps、当社のRAGガイド、Lakebase、Agent Bricksについてさらに詳しくご覧ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事