Databricks上でRAG、MLflow、Vector ... ノート

Databricks上でRAG、MLflow、Vector Search、Model Servingを用いたエンタープライズLLMチャットボットのデプロイ

デモは常にうまくいく。誰かがノートブックで基盤モデルにベクトルインデックスを接続し、従業員ハンドブックについて3つの質問をすると、3つの的確な回答が得られ、部屋はうなずく。その後、「4,000人の従業員に出荷する」という要求になり、ノートブックは静かに死ぬ。エンドポイントがなく、認証がなく、バージョン履歴がなく、特定の回答がなぜ間違っていたのかを確認する方法がなく、法務部から「2019年のPTOポリシーを引用し始めたプロンプトをどのようにロールバックするのか」と尋ねられたときのストーリーがない。私はいくつかのチームがこの壁にぶつかるのを見てきた。RAGの部分 — チャンク化、埋め込み、取得、コンテキストの詰め込み、生成 — は彼らは熟知している。彼らが欠いているのは、退屈な半分だ。ノートブックのセルで実行されるチェーンを、チャットUIが呼び出すことができる、午前3時のアラートにも耐えられる、来月宇宙全体を再デプロイすることなくA/Bテストできる、管理され、バージョン管理され、監視されたRESTエンドポイントにどうやって変換するのか?この記事はその退屈な半分についてだ。RAGは概念的に理解していると仮定し、Databricksの完全なパスをたどる。チェーンを記述し、MLflowにログを記録し、Unity Catalogに登録し、Model Servingエンドポイントにデプロイし、すべての取得と生成をトレースし、ライブになったらそのものを運用する。