GenAI システムの隠れた技術的負債

序章

古典的なmachine learningと生成AIのワークフローを大まかに比較すると、一般的なワークフローのステップは両者で似ていることがわかります。どちらもデータ収集、特徴量エンジニアリング、モデルの最適化、デプロイ、評価などを必要としますが、実行の詳細と時間の割り当ては根本的に異なります。最も重要なのは、生成AIは、適切に管理されないと急速に蓄積する可能性のある、技術的負債の独自の発生源をもたらすことです。これには次のようなものが含まれます。

• ツール スプロール - 増加し続けるエージェント ツールの管理と選択が困難
• プロンプトスタッフィング - 過度に複雑で、維持管理が困難になるプロンプト
• 不透明なパイプライン - 適切なトレース機能がないためデバッグが困難
• 不十分なフィードバック システム - 人間のフィードバックを効果的に収集して活用できない
• ステークホルダーとのエンゲージメント不足 - エンドユーザーとの定期的なコミュニケーションを維持していないこと

このブログでは、技術的負債の各形態について順番に取り上げます。最終的に、古典的な機械学習から生成AIに移行するチームは、これらの新しい負債のソースを認識し、それに応じて開発プラクティスを調整する必要があります。古典的な機械学習プロジェクトで主流だったデータクリーニングや特徴量エンジニアリングよりも、評価、ステークホルダー管理、主観的な品質モニタリング、インストルメンテーションにより多くの時間を費やすことになります。

古典的な機械学習（機械学習）と生成AI（人工知能）のワークフローはどのように違うのでしょうか？

この分野の現状を理解するには、生成AIのワークフローと、従来のmachine learningの問題で使用されるものを比較することが役立ちます。以下は概要です。この比較からわかるように、大まかなワークフローのステップは同じですが、実行の詳細に違いがあるため、強調されるステップが異なってきます。これから見ていくように、生成AIは、本番運用におけるシステムの維持管理方法に影響を及ぼす、新たな形の技術的負債ももたらします。

GenAIプロジェクトにおいて、機械学習開発者は時間の使い方をどのように変えているのでしょうか？

価格予測プロジェクトとツール呼び出しエージェントを構築するプロジェクトの両立を実際に経験したところ、モデルの開発とデプロイのステップにいくつかの大きな違いがあることがわかりました。

モデル開発ループ

内部開発ループとは、通常、機械学習開発者がモデルパイプラインを構築および改良する際に行う反復的なプロセスを指します。これは通常、本番運用でのテストとモデルのデプロイの前に行われます。

このステップにおける、従来の機械学習 と GenAI の専門家の時間の使い方の違いは次のとおりです。

古典的な機械学習モデル開発における時間浪費の要因

• データの収集と特徴の改良: 従来の機械学習プロジェクトでは、ほとんどの時間は特徴と入力データを繰り返し改良することに費やされます。Databricks Feature Store のような特徴を管理および共有するためのツールは、多くのチームが関わっている場合や、手動で簡単に管理するには特徴が多すぎる場合に使用されます。
  
  これに対し、評価は単純です。モデルを実行して定量的メトリクスが改善したかどうかを確認し、その後、より良いデータ収集と特徴量がモデルをどのように強化できるかを検討します。例えば、私たちの価格予測モデルの場合、ほとんどの予測ミスはデータの外れ値を考慮していなかったことが原因であると、私たちのチームは気づきました。次に、これらの外れ値を表す特徴をどのように含めるかを検討し、モデルがそれらのパターンを識別できるようにする必要がありました。

生成AIモデルとパイプライン開発における時間浪費の要因

• 評価：生成AIプロジェクトでは、データ収集・変換と評価に割り当てられる時間の割合が逆になります。データ収集では通常、非構造化ナレッジベースのドキュメントやマニュアルといった形式で、モデルに十分なコンテキストを収集します。このデータには、大規模なクリーニングは必要ありません。しかし、評価ははるかに主観的で複雑であり、その結果、より多くの時間がかかります。モデル パイプラインで反復処理を行うだけでなく、評価セットでも反復処理を行う必要があります。そして、古典的な機械学習よりもエッジケースを考慮するためにより多くの時間が費やされます。
  
  たとえば、最初の 10 個の評価質問では、ユーザーがサポートボットに尋ねる可能性のあるあらゆる質問を網羅できないかもしれません。その場合は、評価を追加で収集する必要があります。あるいは、設定した LLM 判定が厳しすぎて、関連性の高い回答がテストに不合格になってしまう場合は、プロンプトを書き換える必要があります。MLflowの評価データセットは、常に正しく機能する必要がある例の「ゴールデンセット」のバージョン管理、開発、監査に役立ちます。
• ステークホルダー管理: さらに、応答の品質はエンドユーザーの入力に依存するため、エンジニアはビジネスのエンドユーザーや製品マネージャーとのミーティングに多くの時間を費やし、要件を収集して優先順位付けを行ったり、ユーザーからのフィードバックを基にイテレーションを重ねたりします。歴史的に、古典的な機械学習は多くの場合、エンドユーザーに広く公開されるものではありませんでした（例:時系列予測など）、あるいは技術者以外のユーザーにあまり公開されていなかったため、生成AIの製品管理に対する要求ははるかに高くなっています。応答品質に関するフィードバックの収集は、Databricks Apps でホストされ、MLflow Feedback API を呼び出すシンプルな UI を介して実行できます。その後、フィードバックをMLflow TraceとMLflow Evaluation データセットに追加することで、フィードバックとモデル改善の好循環を生み出します。

次の図は、モデル開発ループにおける古典的な機械学習と生成AIの時間配分を比較したものです。

モデルのデプロイループ

モデル開発ループとは異なり、モデル デプロイ ループはモデル パフォーマンスの最適化に重点を置いていません。代わりに、エンジニアは本番環境での体系的なテスト、デプロイ、モニタリングに重点を置いています。

ここでは、開発者はプロジェクトの更新を容易にするために、設定をYAMLファイルに移動することがあります。また、Pandasの代わりにPySparkなどのより堅牢なフレームワークを使用して、静的なデータ処理パイプラインをストリーミング方式で実行するようにリファクタリングすることもあります。最後に、モデルの品質を維持するために、テスト、モニタリング、フィードバックのプロセスを設定する方法を検討する必要があります。

この時点では、自動化が不可欠であり、継続的インテグレーションと継続的デリバリーは必須要件です。Databricks上のデータおよびAIプロジェクトのCI/CDを管理するには、通常、Databricks Asset Bundlesが選択されます。それらによって、Databricksのリソース（ジョブやパイプラインなど）をソースファイルとして記述でき、プロジェクトのソースファイルにメタデータを含める方法も提供されます。

モデル開発段階と同様に、この段階では生成AIプロジェクトと従来の機械学習プロジェクトで最も時間がかかるアクティビティは同じではありません。

古典的な機械学習モデルのデプロイにおける時間浪費

• リファクタリング: 従来の機械学習プロジェクトでは、ノートブックのコードは非常に乱雑になりがちです。さまざまなデータセット、特徴量、モデルの組み合わせが継続的にテスト、破棄、再結合されます。その結果、ノートブックのコードをより堅牢にするために、リファクタリングに多大な労力を費やす必要があるかもしれません。（Databricks Asset Bundles MLOps Stacks テンプレートのような）決められたコードリポジトリのフォルダ構造を持つことで、このリファクタリングプロセスに必要な基盤を提供できます。
  
  リファクタリング アクティビティの例としては、以下のようなものがあります。
  • ヘルパーコードを関数に抽象化する
  • ユーティリティ関数をインポートして何度も再利用できるように、ヘルパーライブラリを作成します
  • 構成をノートブックからYAMLファイルに分離する
  • より速く、より効率的にランされる、より効率的なコード実装を作成する（例：ネストされたforループの削除）
    　
• 品質のモニタリング: データエラーにはさまざまな形態があり、検出が困難なため、品質のモニタリングはもう一つの時間のかかる作業です。特に、Shreya Shankarらが論文「Operationalizing Machine Learning: An Interview Study」で述べているように、「データポイント内のいくつかのヌル値を持つ特徴量のようなソフトエラーは、害が少なく、それでも妥当な予測を生み出すことができるため、捕捉して定量化することが困難です」。さらに、さまざまな種類のエラーにはそれぞれ異なる対応が必要であり、適切な対応を決定することは必ずしも簡単ではありません。
  
  さらなる課題は、さまざまな種類のモデルドリフト（特徴ドリフト、データドリフト、ラベルドリフトなど）を、さまざまな時間粒度（日次、週次、月次）で測定する必要があり、これが複雑さを増している点です。プロセスを容易にするため、開発者はDatabricks Data Quality Monitoringを使用して、モデル品質メトリクス、入力データ品質、およびモデルの入力と予測の潜在的なdriftを、包括的なフレームワーク内で追跡できます。

生成AIモデルのデプロイにおける時間浪費要因

• 品質モニタリング: 生成 AI では、モニタリングにもかなりの時間がかかりますが、その理由は異なります。
  • リアルタイム要件: 解約予測、価格予測、患者の再入院などのタスクのための古典的なmachine learningプロジェクトでは、予測をバッチモードで提供でき、実行は1日に1回、週に1回、あるいは月に1回程度です。しかし、多くの生成AIプロジェクトは、仮想サポートエージェント、ライブ文字起こしエージェント、コーディングエージェントなどのリアルタイムアプリケーションです。その結果、リアルタイムのモニタリングツールを設定する必要があります。これは、リアルタイムのendpointモニタリング、リアルタイムの推論分析パイプライン、リアルタイムのアラートを意味します。
    
    Databricks AI GatewayなどのAPIゲートウェイを設定してLLM APIのガードレールチェックを実行すると、安全性とデータプライバシーの要件を満たすことができます。これは、オフラインプロセスとして行われる従来のモデルモニタリングとは異なるアプローチです。
  • 主観的評価: 前述のとおり、生成 AI アプリケーションの評価は主観的なものです。モデル デプロイメント エンジニアは、推論パイプラインで主観的なフィードバックを収集して運用する方法を検討する必要があります。これは、モデルの応答に対して LLM 判定評価を実行したり、モデルの応答のサブセットを選択してドメインの専門家による評価のために提示したりする形をとります。独自のモデルを提供するプロバイダーは時間をかけてモデルを最適化するため、その「モデル」は実際にはリグレッションを起こしやすいサービスとなります。そのため評価基準では、自己訓練モデルのようにモデルの重みが固定されていないという事実を考慮する必要があります。
    
    自由形式のフィードバックと主観的な評価を提供する機能が、中心的な役割を果たします。Databricks Apps や MLflow Feedback API のようなフレームワークは、そのようなフィードバックを収集し、特定の LLM コールに結びつけることができる、よりシンプルなユーザーインターフェースを可能にします。
• テスト: 生成AIアプリケーションでは、いくつかの理由から、テストに時間がかかることがよくあります。
  • 未解決の課題: 生成AIアプリケーション自体はますます複雑化していますが、評価およびテストのフレームワークはまだ追いついていません。テストを困難にするシナリオには、次のようなものがあります。
    • 複数ターンにわたる長い会話
    • 企業の組織的な背景に関する重要な詳細を必ずしも捉えているとは限らない SQL の出力
    • チェーン内で適切なツールが使用されていることを確認する
    • アプリケーションにおける複数エージェントの評価
      この複雑さに対処するための最初のステップは、通常、エージェントの出力のトレース（ツール呼び出し、推論、最終応答の実行履歴）をできるだけ正確にキャプチャすることです。自動トレースキャプチャと手動インストルメンテーションを組み合わせることで、エージェントのインタラクションの全範囲をカバーするために必要な柔軟性が得られます。たとえば、MLflow Traces の trace デコレーターをあらゆる関数で使用して、その入力と出力をキャプチャできます。同時に、特定のコードブロック内にカスタムの MLflow Traces スパンを作成して、よりきめ細かいオペレーションをログに記録できます。インストルメンテーションを使用してエージェントの出力から信頼できる唯一のソースを集約してはじめて、開発者は障害モードを特定し、それに応じてテストを設計できるようになります。
  • 人間のフィードバックを取り入れる: 品質の評価において、このインプットを取り入れることは非常に重要です。しかし、一部のアクティビティは時間がかかります。例をいくつかご紹介します。
    • アノテーターが従うべきガイドラインとなるルーブリックを設計する
    • シナリオごとに異なるメトリクスや判定基準を設計する（例: 出力が安全であるか、有用であるか）。
      
      エージェントにどのような応答が期待されるかについて、共通の評価基準を作成するには、通常、対面でのディスカッションやワークショップが必要です。人間のアノテーターの意見が一致して初めて、MLflowのmake_judge APIやSIMBAAlignmentOptimizerなどの関数を使用して、彼らの評価をLLMベースの判定機能に確実に統合することができます。

AIの技術的負債

技術的負債は、開発者が長期的な保守性を犠牲にして、その場しのぎの安易なソリューションを実装するときに蓄積されます。

クラシカル機械学習の技術的負債

Dan Sculley らは、これらのシステムが蓄積しうる技術的負債の種類について、優れた要約を提供しています。彼らの論文「Machine Learning: The High-Interest Credit Card of Technical Debt」では、これらを 3 つの広範な分野に分類しています。

• データの負債 ドキュメントが不十分であったり、考慮されていなかったり、暗黙のうちに変更されたりするデータ依存関係
• システムレベルの負債 広範なグルーコード、パイプラインの「ジャングル」、「デッド」なハードコードされたパス
• 外部の変更 thresholdの変更（適合率-再現率のthresholdなど）、または以前は重要だった相関の削除

生成AIは新しい形態の技術的負債を生み出しますが、その多くはすぐには明らかにならないかもしれません。このセクションでは、この隠れた技術的負債のソースについて探ります。

ツールの乱立

ツールは、LLM の能力を拡張するための強力な方法です。しかし、使用するツールの数が増えるにつれて、管理が難しくなることがあります。

ツールの乱立は、発見可能性や再利用性の問題を引き起こすだけでなく、生成AIシステムの品質に悪影響を与える可能性もあります。ツールが乱立すると、主に2つの問題点が生じます。

• ツールの選択: LLM は、幅広いツールの中から呼び出すべき適切なツールを正しく選択する必要があります。ツールが、週次と月次の売上統計のためにデータ APIs を呼び出すなど、ほぼ同様の処理を行う場合、適切なツールが確実に呼び出されるようにすることが困難になります。LLM は間違いを犯し始めます。
• ツール パラメータ: 呼び出すツールを正しく選択できたとしても、LLM はユーザーの質問を解析して、ツールに渡すための適切なパラメータ セットに変換する必要があります。これは考慮すべきもう 1 つの障害点であり、複数のツールが類似したパラメータ構造を持つ場合には特に困難になります。

ツールの乱立に対する最もクリーンなソリューションは、チームが使用するツールを戦略的かつ最小限にすることです。

しかし、適切なガバナンス戦略は、ますます多くのチームがGenAIをプロジェクトやシステムに統合するにつれて、複数のツールとアクセスの管理を拡張可能にするのに役立ちます。Databricksの製品であるUnity CatalogとAI Gatewayは、この種のスケールに対応できるように構築されています。

プロンプト スタッフィング

最先端のモデルは何ページもの指示を処理できますが、過度に複雑なプロンプトは、矛盾した指示や古い情報といった問題を引き起こす可能性があります。これは特に、プロンプトが編集されず、時間の経過とともにさまざまなドメイン専門家や開発者によって単に追加されていくだけの場合に当てはまります。

さまざまな故障モードが発生したり、新しいクエリーがスコープに追加されたりすると、LLMプロンプトにますます多くの指示を追加し続けたくなります。たとえば、プロンプトはまず財務関連の質問を処理するための指示を出すことから始まり、その後、製品、エンジニアリング、人事関連の質問へと分岐していくことがあります。

ソフトウェアエンジニアリングにおける「ゴッドクラス」が良い考えではなく分割されるべきであるのと同様に、メガプロンプトもより小さなものに分割すべきです。実際、Anthropicは、そのプロンプトエンジニアリングガイドでこの点に言及しており、原則として、長く複雑な1つのプロンプトよりも複数の小さなプロンプトを使用する方が、明確さ、正確さ、トラブルシューティングの向上に役立ちます。

フレームワークは、プロンプトのバージョンを追跡し、期待される入力と出力を適用することで、プロンプトを管理しやすくするのに役立ちます。プロンプトのバージョン管理ツールの一例はMLflow Prompt Registryですが、DatabricksでランできるDSPyなどのプロンプトオプティマイザーは、プロンプトを自己完結型のモジュールに分解し、個別または全体として最適化することができます。

不透明なパイプライン

最近トレーシングが注目されているのには理由があります。ほとんどのLLMライブラリと追跡ツールが、LLMチェーンの入出力をトレースする機能を提供しています。レスポンスがエラー（あの忌まわしい「申し訳ありません、ご質問にはお答えできません」）を返した場合、根本原因を特定するには、中間のLLMコールの入出力を調べることが極めて重要です。

私は以前、あるアプリケーションに携わっていましたが、当初は SQL 生成がワークフローの中で最も問題の多いステップになるだろうと想定していました。しかし、トレースを調査したところ、別の事実が判明しました。エラーの最大のソースは、ユーザーの質問内のエンティティをデータベースの値と一致するエンティティに更新する、クエリリライターステップでした。LLM は、書き換える必要のないクエリーを書き換えたり、元のクエリーにあらゆる種類の余分な情報を詰め込み始めたりしました。これにより、その後の SQL 生成プロセスが定期的にうまくいかなくなりました。ここでは、トレースが問題の迅速な特定に役立ちました。

適切なLLM呼び出しをトレースするには時間がかかることがあります。標準装備のトレーシングを実装するだけでは不十分です。MLflow Tracesなどのフレームワークを使用してアプリに可観測性を適切に実装することは、エージェントのインタラクションをより透明にするための最初のステップです。

人間のフィードバックを収集して活用するための不十分なシステム

LLMが注目に値するのは、いくつかの簡単なプロンプトを渡し、その結果をつなぎ合わせるだけで、ニュアンスや指示を非常によく理解しているように見えるものが出来上がるからです。しかし、ユーザーからのフィードバックで応答を根拠づけずにこのまま進むと、品質の負債が急速に積み上がる可能性があります。ここで、できるだけ早く「データフライホイール」を作成することが役立ちます。これは、次の3つのステップで構成されます。

• 成功メトリクスの決定
• これらのメトリクス測定を自動化し、ユーザーが何が機能しているかフィードバックできるUIを利用することが考えられます。
• メトリクスを改善するためにプロンプトやパイプラインを繰り返し調整する

スポーツ統計をクエリーするためのtext-to-SQLアプリケーションを開発しているときに、人間によるフィードバックの重要性を再認識しました。ドメインエキスパートは、スポーツファンがどのようにデータとインタラクトしたいか、何を重視するかを明確にし、スポーツをほとんど見ない私では決して思いつくことのできなかった他の知見を提供してくれました。彼らの意見がなければ、私が作成したアプリケーションは、おそらくユーザーのニーズを満たせなかったでしょう。

人間のフィードバックを収集することは非常に貴重ですが、通常は痛いほど時間がかかる作業です。まずドメインエキスパートとの時間を確保し、次にエキスパート間の差異を調整するための評価基準を作成し、その後、改善のためにフィードバックを評価する必要があります。フィードバック UI がビジネス ユーザーのアクセスできない環境でホストされている場合、適切なレベルのアクセス権を提供するために IT 管理者とやり取りすることは、終わりのないプロセスのように感じられることがあります。

定期的な関係者との確認なしでの構築

正しいものを構築しているかどうかを確認するために、エンドユーザー、ビジネススポンサー、および隣接チームと定期的に相談することは、あらゆる種類のプロジェクトにとって必須条件です。しかし、生成AIプロジェクトでは、ステークホルダーとのコミュニケーションがこれまで以上に重要になります。

なぜ頻繁で手厚いコミュニケーションが重要なのか:

• オーナーシップと管理: 定期的な会議は、ステークホルダーがアプリケーションの最終的な品質に影響を与えることができるという実感を持つのに役立ちます。批評家になるのではなく、協力者になることができます。もちろん、すべてのフィードバックが等しいわけではありません。一部のステークホルダーは、MVPに実装するには時期尚早な機能や、現在のLLMでは対応できないような機能を要求し始めることは避けられません。達成可能なことと不可能なことについて、関係者全員と交渉し、認識を共有することが重要です。そうしないと、ブレーキが適用されずに機能リクエストが多すぎるという、別のリスクが生じる可能性があります。
• 何を知らないかを知らない：生成 AI は非常に新しいため、技術者であるかどうかにかかわらず、ほとんどの人が、LLM が何を適切に処理でき、何をできないかを知りません。LLM アプリケーションの開発は関係者全員にとって学びの道のりであり、定期的なタッチポイントは全員に情報を共有し続けるための一つの方法です。

生成AIプロジェクトでは、適切なデータアクセス制御の実施、安全性管理とプロンプトインジェクション防止のためのガードレールの設置、コストの急増防止など、対処が必要となる可能性のある他の多くの技術的負債が存在します。ここでは、最も重要と思われ、かつ簡単に見過ごされがちなものだけを取り上げました。

まとめ

古典的な機械学習と生成AIは、同じ技術分野の異なるバリエーションです。それらの違いを認識し、ソリューションの構築・保守方法への影響を考慮することは重要ですが、普遍の真理も存在します。コミュニケーションが隔たりを埋め、モニタリングが大惨事を防ぎ、クリーンで保守可能なシステムが長期的には無秩序なシステムを凌駕するという事実は変わりません。

自社のAI成熟度を評価してみませんか？ガイドを読む：AIの価値を引き出す：エンタープライズ向けAI導入準備ガイド。

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