Tooling ≠ Glue: AI ワークフローの変更が依然としてガムテープのように感じられる理由

現代のAI開発には奇妙な矛盾があります。私たちはこれまで以上に優れたツールを持っています。私たちは、よりクリーンな抽象化でよりスマートなシステムを構築しています。それでも、スタック内のコンポーネントを交換しようとするたびに、物事がバラバラになります。又。

これは単なる不便ではありません。それは当たり前になっています。

世の中にあるすべてのフレームワークとライブラリ (LangChain、Hugging Face、MLflow、Airflow) があれば、もうこの状況は過ぎていると思うかもしれません。これらのツールは、ワークフローをモジュール化し、コンポーザブルにすることになっていました。埋め込みモデルを交換しますか?大丈夫。新しいベクターストアを試してみませんか?易しい。OpenAI からオープンソースの LLM に切り替えますか?さあ、どうぞ。それが夢でした。

しかし、現実はこうだ:私たちはモノリスを、それぞれが独自の仮定、癖、そして「標準インターフェース」を持つマイクロツールの脆いパッチワークと交換した。そして、1 つの部分を置き換えるたびに、壊れた構成、不一致の入出力形式、存在を忘れていた YAML ファイルに埋もれた副作用を追いかけることになります。

工具は接着剤であるはずでした。しかし、ほとんどの日、それはまだガムテープのように感じます。

コンポーザビリティの神話

AI で登場したツールの多くは、確固たる意図を持っていました。UNIXの哲学に従ってください。1つのことをうまく行う小さなピースを構築します。明確なインターフェースを公開します。すべてを交換可能にします。

理論的には、これにより実験がより速くなり、統合がよりスムーズになるはずです。しかし実際には、ほとんどのツールは単独で構築されていました。埋め込みとは何か、プロンプトの書式設定方法、再試行ロジックのあり方、ドキュメントをチャンクする方法については、誰もが独自の見解を持っていました。

そのため、コンポーザビリティの代わりに断片化が生じました。プラグアンドプレイの代わりに、「接着剤と壊れないことを願う」というものがありました。

そして、この断片化は迷惑なだけではありません。それはすべてを遅くします。新しいRAG戦略を試してみませんか?データのインデックスを再作成し、チャンクサイズを調整し、スコアリング関数を微調整し、ベクトルDBスキーマを再トレーニングする必要がある場合があります。そのどれも必要ないはずです。しかし、それはそうです。

スタックは浅くて広い

今日の AI パイプラインは、さまざまなレイヤーにまたがっています。

• データ取り込み
  
• 特徴抽出または埋め込み
  
• ベクターの保存と検索
  
• LLM推論
  
• オーケストレーション (LangChain、LlamaIndex など)
  
• エージェント ロジックまたは RAG 戦略
  
• API / フロントエンドレイヤー
  

それぞれが図上のきれいなブロックのように見えます。しかし、内部的には、トークン化の癖、ステートフル性、再試行動作、レイテンシーの期待などに関する文書化されていない仮定によって密接に結合されていることがよくあります。

その結果は?柔軟なスタックであるべきものは、トランプの家のようなものです。1つのコンポーネントを変更すると、全体がぐらつく可能性があります。

なぜすべてが壊れ続けるのか

簡単に言うと、抽象化は大量にリークします。

すべての抽象化は何かを単純化します。そして、その単純化が根底にある複雑さと一致しないと、奇妙なことが起こり始めます。

LLM を例に考えてみましょう。OpenAI の API から始めても、すべてがうまくいきます。予測可能なレイテンシー、一貫したトークン制限、クリーンなエラー処理。次に、ローカルモデルに切り替えます。突然：

• 入力形式が異なります
  
• バッチ処理と GPU メモリを管理する必要があります
  
• トークンの制限は十分に文書化されていません
  
• レイテンシーが劇的に増加する
  
• これで、量子化とキャッシュを担当しました
  

かつては単純な llm.predict() 呼び出しだったものが、まったく新しいエンジニアリングの問題になります。抽象化がリークされ、再びグルーコードを書いています。

これは単なる一回限りの煩わしさではありません。それは構造的です。私たちは、変動が例外ではなくルールであるランドスケープを標準化しようとしています。

基準はどこにありますか?

現在の混乱の大きな理由の1つは、相互運用性に関する確固たる標準が欠如していることです。

他の分野では、これを理解しました。

• OCI、Docker→コンテナ
  
• OpenAPI → API
  
• OpenTelemetry →オブザーバビリティ
  
• データ形式→ Parquet、JSON スキーマ、Avro
  

AIでは?私たちはまだそこには到達していません。ほとんどのツールは独自のコントラクトを定義します。何が普遍的であるかについて同意する人はほとんどいません。その結果、再利用が難しく、スワッピングにはリスクが伴い、スケーリングは苦痛になります。

しかし、AI ツールではどうでしょうか?

• モデル I/O シグネチャの標準として広く採用されている標準はまだありません。
  
• プロンプト形式、コンテキストウィンドウ、トークナイザーの動作は、プロバイダーによって異なります。
  
• MCP(モデルコンテキストプロトコル)のような有望な取り組みが出現しており、これは良い兆候ですが、実際には、ほとんどのRAGパイプライン、エージェントツール、ベクトルストア統合には、一貫性のある強制的な契約がまだ欠けています。
  
• エラー処理?それはほとんど即興で、再試行、タイムアウト、フォールバック、サイレント エラーがあなたの責任になります。
  

はい、MCP のような標準が現れ始めており、それらは重要です。しかし、今日でも、ほとんどのチームは手作業で物事をつなぎ合わせています。これらのプロトコルが共通のツールスタックの一部となり、ベンダーによってサポートされ、ライブラリ全体で尊重されるまで、接着剤は漏れ続けるでしょう。

ローカルグルー≠グローバルコンポーザビリティ

「でも、ノートではうまくいった」と言いたくなります。

はい、それが問題です。

デモ、ローカルプロトタイプ、または概念実証で機能するグルーロジックは、本番環境で故障することがよくあります。なぜでしょうか。

• ノートブックは運用環境ではなく、再試行、監視、監視、または適切なエラー サーフェスがありません。
  
• Python 関数を使用してツールを連鎖させることは、リアルタイムのレイテンシの制約、同時実行性、およびスケールを念頭に置いてツールを構成することとは異なります。
  
• LangChainのようなツールを使用すると、競合状態、カスケードエラー、または状態管理の微妙なバグが発生するまで、コンポーネントを簡単に構成できることがよくあります。
  

今日のツールの多くは、本番環境での耐久性ではなく、実験中の開発者の人間工学のために最適化されています。その結果、クリーンでモジュール化されているように見えますが、舞台裏には仮定と暗黙的な結合の脆弱な網の目があるパイプラインをデモします。

このグルーロジックをスケーリングし、テスト可能、観察可能、堅牢性を高めるには、賢いラッパー以上のものが必要です。システム設計、標準、および実際のエンジニアリング規律が必要です。

核心的な問題: モジュール性の錯覚

これをさらに危険にしているのは、モジュール性の錯覚です。表面的には、API ブロック、チェーン テンプレート、ツールキットなど、すべてが構成可能に見えますが、実際の実装は緊密に結合されており、バージョン管理が不十分で、文書化されていないことがよくあります。

開発者が不注意だからといってAIスタックが壊れるわけではありません。基本的な抽象化がまだ未熟であり、エコシステムがコミュニケーションの方法、優雅に失敗する方法、または同期して進化する方法について調整されていないために壊れています。

これに対処するまでは、ツールがどんなに光沢があっても、 接着剤は壊れ続けます。

SDKの誇大宣伝ではなく、インターフェースコントラクト

多くの AI ツールは、ヘルパー関数と構文シュガーで満たされた SDK を提供しています。しかし、これにより実際のインターフェイスが隠され、コードと特定のツールの間に緊密な結合が生じることがよくあります。代わりに、コンポーザビリティとは、次のような正式なインターフェイス コントラクトを公開することを意味します。

• REST API 用の OpenAPI
• 効率的で構造化されたメッセージングのためのプロトコルバッファ
• データ構造を検証するための JSON スキーマ

これらの契約:

• インプット/アウトプットに対する明確な期待を許可します。
• 検証、コード生成、テストの自動化を可能にします。
• コードを書き直すことなく、モデル/ツールを簡単に交換できるようにします。
• SDK ロックインではなく、ツールに依存しないアーキテクチャを奨励します。

幸せな道だけでなく、失敗のために構築する

現在のほとんどの AI システムは、すべてがスムーズに機能することを前提としています (「ハッピーパス」)。でも実際は：

• モデルがタイムアウトする
• API が曖昧なエラーを返す
• 出力の形式が正しくないか、安全でない可能性があります

真にコンポーザブルなシステムには、次のことが必要です。

• 明示的なエラータイプ(例: RateLimitError、 ModelTimeout、 ValidationFailed)
• 再試行とフォールバックのメカニズムをネイティブに公開する (手巻きではない)
• 組み込みの可観測性(メトリック、ログ、トレース)を提供
• 障害処理を宣言的でモジュール式にする (例: モデル A が失敗した場合は、モデル B を試す)

宣言型パイプラインへの移行

現在、ほとんどの AI ワークフローは手続き型コードで記述されています。

response = model.generate(prompt)
if response.score > 0.8:
    store(response)

しかし、このロジックは困難です。

• ツール間での再利用
  監視またはデバッグ
• 中間結果のキャッシュ

宣言型パイプラインは、方法ではなく、何を記述します。

pipeline:
  - step: generate
    model: gpt-4
    input: ${user_input}
  - step: filter
    condition: score > 0.8
  - step: store
    target: vector_database

宣言型パイプラインの利点:

• 最適化とキャッシュが容易
• ツールに依存しず、プロバイダー間で動作します
• より保守しやすく、推論しやすくなります
• 書き換えではなく動的な再構成をサポート

開発者にとって重要なポイント

1。契約のない「シームレス」なツールに懐疑的になる

シームレスなプラグアンドプレイを約束するが、強力なインターフェイス契約を欠いているツールには懐疑的です。

ツールが統合が簡単であると売り込んでいるが、以下を提供しない場合:

• 明確なインターフェイス コントラクト (OpenAPI、Protobuf、JSON スキーマ)
  
• バージョン管理された API
  
• 入力/出力の検証ルール
  
• 言語に依存しないインターフェイス
  

それなら、「プラグアンドプレイ」という主張は誤解を招くものです。これらのツールは、多くの場合、SDKに閉じ込められ、統合の真のコストを隠します。

2。防御的な設計

ワークフローを防御的に設計し、コンポーネントを分離し、フォーマットを標準化し、物事が壊れることを想定します。

優れたシステム設計は、物事が失敗することを前提としています。

• 責任を分離する: たとえば、プロンプト、検索、評価を 1 つのコード ブロックに混在させないでください。
  
• フォーマットの標準化: ツール間で共通のスキーマを使用します (例: JSON-LD、共有メタデータ、または LangChain スタイルのメッセージ オブジェクト)。
  
• エラーを処理する: 最初からフォールバック、タイムアウト、再試行、オブザーバビリティを使用して構築します。
  

ヒント: すべてのツールは、ローカルで実行されている場合でも、信頼性の低いネットワーク サービスのように扱ってください。

3。宣言型で相互運用可能なパイプラインを優先する

宣言型で相互運用可能なアプローチを採用し、コードを減らし、構造化を増やします。

宣言型ツール (YAML ワークフロー、JSON パイプラインなど) は以下を提供します。

• 明快さ: あなたは、どのように起こるべきかではなく、何が起こるべきかを説明します。
  
• モジュール性: すべてを書き換えることなくステップを置き換えることができます。
  
• ツール中立性: プロバイダーまたはフレームワーク間で機能します。
  

これが手作業で配線することと回路基板を使用することの違いです。宣言型システムは、予測可能なインターフェイスと再利用可能なコンポーネントを提供します。

 例:

• ランググラフ
  
• フローライズ
  
• PromptLayer + OpenAPI の仕様
  
• 明確なスキーマを持つ入出力としてJSONを使用するツール

結論

モジュール式パイプライン、再利用可能なコンポーネント、モデルを交換したりバックエンドを変更したりするたびに壊れない AI システムなど、何が可能かは誰もが見てきました。しかし、正直に言うと、まだそこには至っていません。そして、他の誰かがそれを修正するのを待つだけではそこに到達することはできません。AI ワークフローが真に構成可能な未来を望むなら、これらのシステムを構築および保守する人々である私たちにかかっています。

それはすべてを再発明するという意味ではありません。それは、私たちがすでに管理しているものから始めることを意味します:より明確な契約を書き、他の誰かが使用するように内部パイプラインを文書化し(誰かが使用するから)、相互運用性を取り入れたツールを選択し、物事が緊密に結合しすぎている場合は声を上げます。ツールの状況は一夜にして変わるものではありませんが、私たちが下すすべての決定、すべての PR のオープン、そして私たちが共有するすべてのストーリーで、私たちは単にダクトテープで貼り付けるのではなく、長持ちするように構築されたインフラストラクチャに一歩近づきます。