小規模なAIアプリケーションの構築から7つのレッスン

2025年1月22日

ChatGptは、ソフトウェアの地震の変化を告げました。それで、過去1年間、私は教育的演習として私の過去のCEO自己のためのAIアシスタントを構築してきました。質問に答え、ステータスレポートを取得し、何が起こっているのかを要約します。私が今知っていることを振り返ると、ここで過去1年間の私の持ち帰りです。

私の最大の認識は、「スケールアップ」の問題として伝統的に特徴付けられていた問題が、私が推測していたよりもはるかに早く発生したということでした。しかし同時に、copilotなどのAIツールを使用して、 また書いた、生産性の違いも生じます。それは遅くはありません、それはより速く、それはただ違いがあります。

AIプログラミングは確率的です

従来のプログラミングとは異なり、AIを必要な方法で動作させることは確率的プロセスです。一般的に言えば、AIを「プログラミング」するプロセスには、多くの実験が含まれます。各実験では、さまざまな入力とパラメーターを調整し、以前にしたことを改善できるかどうかを確認します。

一般的に、調整は4つの主要なカテゴリに分類されます。

1. あなたのプロンプト。ほとんどの場合、プロンプトを調整することから始めます。しかし、少数のショットのプロンプトから検索された生成の拡張された世代までのプロンプトに至るまで、採用すべき顕著な量のテクニックがあります。これらはすべてパフォーマンスを大幅に改善できます。
2. LORAまたはその子孫を使用したタスク/ドメインの微調整。ドメイン固有のデータがたくさんある場合、このデータセットでモデルを微調整することは間違いありません。
3. 優先チューニング。ヒトプロファーの出力を最適化することにより、モデルの動作を操縦して、特定の目標または価値をより密接に一致させることができます。
4. ハイパーパラメーターチューニング。プロンプトと微調整を超えて、ハイパーパラメーター（例えば、学習率、バッチサイズ、オプティマイザー設定など）の調整は、モデルのトレーニング効率とパフォーマンスを改善することができます。これは、迅速なエンジニアリングや微調整と比較して、多くの場合、インパクトの低いレバーですが、結果を最適化する上での重要なステップです。

プロセスを経て、特定の問題に対処するために必要な調整の種類について直観を開発し始めました。

データ品質は実際の作業です。

微調整と好みの調整のメカニズムは非常に簡単で、多くの異なるオープンソースライブラリに実装されています。難しい部分は、そもそもトレーニングに使用できる高品質のデータセットを作成することです。このデータセットの構築は、1つのプロセスではありません。構造化されていないデータを取得し、微調整と優先チューニングに適した形式に変換し、データの品質を評価するパイプラインを作成しました。このパイプラインの建物と反復は多くの時間がかかりました。

モデルは評価と同じくらい良いです

Mission Criticalソフトウェアでは、ソフトウェアはテストカバレッジと同じくらい優れています。同様に、AIモデルは評価戦略と同じくらい優れています。最も一般的な戦略は、入力データのサブセットを取り、検証に使用します。このアプローチの課題は、検証データがモデルが遭遇する現実世界のシナリオを代表することを前提としていることです。ただし、これはめったにそうではありません。実際のデータには、簡単な検証セットでキャプチャされないエッジケース、あいまいさ、および外れ値が含まれています。その結果、モデルは検証中にうまく機能する可能性がありますが、生産で望ましい結果を提供できません。

評価のための既製のソリューションは非常に未熟であることがわかりました。一般的な戦略を調査しました。 SimpleQa そして mmlu、および人間のレビュー。これらはすべて大きな制限があります。私は、人間のレビューとLLM-As-Judgeの組み合わせを使用して、オーダーメイドの評価システムの構築を終了しましたが、私のアプローチに特に満足することはありませんでした。

信頼/品質は＃1の問題です

返済日、Databricksの応用AIの責任者、 AIシステムの構築からのレッスンについて素晴らしい講演をしました。 1つの重要なポイント：「最も重要な長期的要因 [AI product] 成功は品質であり、パフォーマンスと信頼性が密接に続きます。」

💯

LLMで優れたデモを取得するのは一見簡単です（1週間でやった！）。実際の条件でうまく機能することはそうではありません。 2025年1月、Apple 無効なニュースの要約 現実の世界で複数の幻覚を発見した後。 Appleは品質について多くの仕事をしていると仮定していますが、彼らはまだ問題に遭遇しました。品質に対処するには、実験と評価の継続的なループが必要です。

トレーニングパイプラインはコアIPです

私は以前、AIモデルは「秘密のソース」だと思っていました。今、私はあなたが反復するにつれてAIモデルが毎週変化することに気付きます。トレーニングパイプラインがあなたの中心的な知的財産であると今私は信じています。

パイプラインをトレーニングすることで、AIモデルを作成するために必要なすべてのことを参照しています。データからデータを微調整するプロセスまでのデータから始めて評価します。 これ 秘密のソースです。

AIで問題が発見されると、好みの調整を追加するか、データなどを追加するかなど、それらを修正するための新しい戦略を見つけることができます。これらはトレーニングパイプラインに組み込まれています。迅速な反復をサポートするトレーニングパイプラインを構築することは、AIの成功にとって重要です。

分散システム、Redux

私のAIアプリケーションは、最初は3つの主要なコンポーネントで構成されていました。データベース（私の場合は、PostgreSQL + PGVector）、すべてのビジネスロジックを実行したFASTAPIアプリケーション、およびLLMです。過去10年間、Cloud-Native SoftwareとKubernetesで過ごしてきたので、分散システムを構築していることは明らかでした。 分散コンピューティングの8つの誤り。さらに、私が走っていたとしても vllm、高性能推論エンジンである現実は、LLMが高層サービスであるということです。さらに、入力サイズが成長するにつれて遅延が増加します。これは、検索された生成（RAG）を活用していたため、一般的なシナリオです。この遅さは、分散システムを設計する必要がある方法を根本的に変えます。

クラウドネイティブアプリケーションでは、分散システムはサービス間の多くのリモートプロシージャコール（RPC）に依存しています。回復力を確保するために、開発者は一般に、タイムアウト、サーキットブレーカー、再試行、バックオフ戦略などの手法を実装します。これらのパターンは、サービスが一時的な問題やダウンタイムを経験したときに、システムをカスケード障害から保護します。

しかし、私のアプリケーションは、単一の高層サービスであるLLMに大きく依存しているため、私のアプリケーションが異なっていることに気付きました。従来のRPCレジリエンスパターンは、一時的なネットワークの問題や軽微な遅延を軽減できますが、LLMSによって導入された固有のレイテンシ、変動、およびオーバーヘッドの処理に対処するには不十分でした。

LLMSの高度な性質を考えると、私は完全に非同期アーキテクチャを採用し、AIアプリケーションに適しています。信頼できるタスク管理システムとともに同期RPCに依存するのではなく。私の過去の人生では、タスクキューは、システムがはるかに大規模になるまで延期できる建築パラダイムでした。ただし、LLMへの要求をエンキューするためにタスクキューを展開することが重要であり、LLMの遅延が高いにもかかわらずアプリケーションが応答し続けることが重要であることがわかりました。タスクキューは、ワーカープールのレトリ、トラフィックスムージング、動的なスケーリングのための組み込みの回復力も提供しました。私のような仲間のマイクロサービス/Kubernetes難民であるPhil Calcadoは書いています 私の一部を反映した彼の経験についての素晴らしい記事。

AIライブラリの誇大広告を購入しないでください

AI開発をより速く簡単にすると主張する開発者ライブラリがたくさんあります。これらのライブラリは、生産性を向上させるために設計された新しい抽象化を紹介します。私はそれらの多くを試しましたが、抽象化は狭い道にとどまった場合にのみうまく機能することがわかりました（クイックスタートは一般的にうまくいきます！）。

私は2つの大きな問題を見つけました：

1. 欠落/不完全な実装。たとえば、使用しようとしました llamaindex、RAGアプリケーションを構築するための一般的なフレームワーク。 PostgreSQLからドキュメントを取得したかったのです Okapi BM25 Llamaindex BM25実装を使用しようとしました。残念ながら、llamaindex BM25の実装は、持続メカニズムがなく、生産アプリケーションでは役に立たないインデックス内のメモリを保存します。
2. 生態系の統合が悪い。使いたかった アウトライン 構造化されたテキスト生成用。アウトラインは、いくつかの一般的な推論ライブラリ（eg、vllm、llama.cpp）と統合されています。当時、私は使用していました 眠れない より良いパフォーマンスのためのカーネル – しかし、それらはアウトラインで動作しません。

私はこれがすべて時間の経過とともに改善すると確信していますが、私は一般的に、これらの高レベルの抽象化のいくつかを現在（特にクイックスタートエクスペリエンスに基づいて）採用することに注意する必要があると信じています。 Pytorchや🤗トランスなどの十分に確立された低レベルの抽象化の上に、機能を直接直接実装することがより簡単であることがわかりました。

最終的な考え

私たちはまだAI時代の初期のイニングにいますが、私たちの前に学ぶことはもっとたくさんあります。 KubernetesとCloud-Native Technologiesの初期の時代は動きの速い空間だと思いましたが、AIの進化はクラウドネイティブの進化の速さを恥ずかしくさせます。

最終メモ：好きなだけ読むことができます（ここまで読んでくれてありがとう）が、AIについてもっと知りたい場合は、何かを試してみてください！今日、ChatGptやClaudeなどのAIツールにより、プログラミングはこれまで以上にアクセスしやすくなっています。比較的少ない労力でどこまで到達できるかに驚くでしょう。