モデルは製品ではない。真の製品とは何か。
私は、AIをリリースしているエンジニアたちの構築作業や対話に時間を費やしています。デモと実際のプロダクションシステムの間には乖離があります。多くの人々はこの乖離について正直ではありません。
誰もが何でも「エージェント」と呼びます。ループを持つスクリプトはエージェントです。メモリを持つチャットボットもエージェントです。これがエンジニアリング上のミスを引き起こします。単純なタスクに対して過剰な設計を行い、複雑なタスクに対しては設計不足に陥ってしまうのです。
エージェントには目的が必要です。単に指示に従うだけではありません。エージェントは次に何をすべきかを決定します。失敗に対処し、いつ完了したかを知っています。
- 人間がシステムにすべてのステップを指示しているなら、それはチャットインターフェースです。
- システムが失敗したツール呼び出しから復旧できるなら、あなたはエージェントを構築しています。
- システムが目標をサブタスクに分解できるなら、それは真のエージェントです。
真のエージェントの導入は、用途が限定的です。ドキュメント抽出やコードレビューのように、一つのことをうまくこなします。成功しているチームは、新しいモデルを追いかけたりしません。彼らは以下の3つの領域に集中しています。
- ツール設計：インターフェースはどれほどクリーンか？
- 失敗への対処：ツールが何も返さなかったときに何が起きるか？
- オブザーバビリティ：エージェントがなぜその決定を下したのかを追跡できるか？
LangChainやCrewAIのようなフレームワークは、パターンほど重要ではありません。フレームワークは足場であり、アーキテクチャこそが建物なのです。
これらのパターンを活用してください：
- 計画してから実行する。計画のためのステップと、実行のための別個のステップを用意します。
- 検索（Retrieval）と推論（Reasoning）を分離する。コンテキストを取得することと、コンテキストを使用することは異なる作業です。
- 明示的なハンドオフ。あるエージェントが別のエージェントに作業を引き継ぐ際のハンドオフを構造化します。
RAGは標準的ですが、チャンキング（chunking）が間違っていることがよくあります。ドキュメントの分割が不適切だと、モデルはコンテキストを見失い、ハルシネーション（幻覚）を起こします。RAGの結果が役に立たない場合は、チャンキングとメタデータを修正してください。埋め込みモデル（embedding model）のせいにしてはいけません。
モデルは進化し、コンテキストウィンドウは広がり、コストは下がっていくでしょう。しかし、それによってエンジニアリングの課題が変わることはありません。監視していないときでも信頼できるシステムを構築しなければならないのです。
ガバナンス、オブザーバビリティ、そしてツールの使用に注力してください。重要となるエンジニアとは、単なるプロンプトエンジニアリングではなく、システムデザインを極めた人々です。
出典: https://dev.to/aibughunter/the-model-is-not-the-product-heres-what-actually-is-52b5