大規模言語モデル（LLM）に基づくシステム工学は、生産的なワークフローにおいて、単純な連結コードに関連付けられた単なるテキストやランダムな指示から、「エージェンティック・ハーネス（Agentic Harnesses）」として知られる構造化された実行フレームワークへと、劇的な変化を遂げている。この進化は、確率的なモデルを、実際の業務環境における信頼性、確実性、および監視可能性を保証するために必要なソフトウェアサポートで囲むことを目的としている。
第1段階：チェーンと単純な線形プロセス
初期のシステムは、「チェーン（Chains）」として知られる、単純化された線形ワークフローに依存していた。このアプローチは、単純な要約のような限定的なタスクにおいて、実行速度が速く、計算コストが低いという特徴がある。その概念は、第1ステップの出力を第2ステップの入力として渡し、といったプロセスを繰り返すものであり、モデルはテキストを受け取り生成するブラックボックスとして使用される。
例えば、LinkedInは初期段階において、分類とルーティング、次に検索ツールを介したデータ取得による応答の具体化、そして最後に生成とフィルタリングを含む固定的なチェーンを使用していた。開発スピードは速かったものの、これらのシステムは構造的に脆弱であった。初期のステップでエラーが発生すると、自動的な応答や修正メカニズムが欠如しているため、ワークフロー全体が停止してしまうからである。
第2段階：構造と制御を強化するためのグラフ
ユースケースの複雑さが増すにつれ、開発者は条件分岐、並列処理、再試行、および状態管理（State Management）を導入するために、グラフ構造（Graphs）の使用へと移行した。これらの構造において、ノードはさまざまなタスクを表し、エッジは制御パスを制御する。
これらの構造により、タスクのフローと非同期通信を管理して順序と継続性を確保するメインコーディネーターを備えた、マルチエージェントシステム（Multi-Agent Systems）の設計が可能になった。これらのアーキテクチャは、採用担当者がルーチンワークを自動化できるようにするための「採用アシスタント（Hiring Assistant）」のリリースに使用された。しかし、これらのフレームワークは人間によって定義されたワークフローに制限されたままであり、例外的なケースの範囲が広がると、メンテナンスが複雑になる可能性がある。
第3段階：推論の基本ツールとしてのプログラミング
最新の進化は、推論の主要な手段として、視覚的な言語指示の代わりにコード（プログラム）に依存することである。これらの構造は、問題をテキストで解釈するにとどまらず、コードを生成し、隔離されテストされた環境でそれを実行する。
コードは、言語モデルの保証されない確率的な出力と比較して、検証可能な決定論的な性質を持っている。このアーキテクチャは、隔離された実行環境、ロギングおよびモニタリングツール、自動検証構造、そして要求される基準を満たすまでエラーを修正してコードを再実行する反復的なデバッグループに依存している。LinkedInは、プライバシーとガバナンスの枠組みに従って、構造化クエリ言語やPythonを通じて従業員がデータを照会できるようにするために、このアプローチを内部的に適用した。
エージェンティック・システム工学のベストプラクティス
- 出力を信頼できないデータとして扱う： モデルの出力を後続のプログラムロジックに渡す前に、その妥当性を検証する必要がある。
- 計画と実行の分離： モデルには計画の提案を許可し、厳格なプログラムフレームワークが実行プロセスを担当するようにする。
- モニタリングへの投資： 機密データを損なうことなく、エラーや状態ログを確認するために、実行状態を正確に追跡する。
- 継続的な開発： 時間の経過とともにシステムのパフォーマンスを向上させるために、分析的なフィードバックループを構築する。
適切なエンジニアリング抽象化の選択
すべての技術的問題が、グラフや高度なコードの運用上の複雑さを必要とするわけではない。単純な要約やコンテンツ処理のような直接的なタスクにおいては、単純なチェーンが時間と計算リソースの面で最も適切かつ低コストな選択肢であり続ける。一方で、分岐や状態制御が必要な場合にはグラフが不可欠となり、ソフトウェアエンジニアリングや複雑なデータ分析のような、厳格な精度と検証を必要とするクリティカルな領域ではプログラミングフレームワークが使用される。
ニュースの出典
InfoQ - Architecture Articles
原文を開く ↗