エージェンティックAIプランニングの盲点：なぜレイヤーが足りないのか
私たちの提案する「RECAP」は、意図の書き換えを導入します。これは、プランニングを開始する前に、マルチターンにわたる複雑な対話を、明確かつ構造化されたゴールへと変換するプロセスです。
なぜエージェント間の連携は失敗するのか？VERIMAPによる信頼性向上のメカニズム
大規模言語モデルが、ツールの使用、プランニング、マルチステップの推論を行うエージェンティックシステムへと進化するにつれて、失敗の原因は純粋な推論能力ではなく、エージェント間の連携に起因することが増えています。 多くのマルチエージェンティックLLMワークフローでは、各エージェントはそれぞれのローカルタスクを正しく実行しているにもかかわらず、システム全体としては失敗することがあります。その根本原因は、多くの場合、タスク分解、出力構造、エージェント間の受け渡しにおける微妙な不整合にあります。 私たちの研究論文 ”Verification-AwarePlanningforMulti-AgentSystems”（VERIMAP）は、この連携の課題に対して、プランニングプロセスそのものに検証を組み込むことで直接的に取り組んでいます。 エージェンティックAIの核心的問題：連携と検証のギャップをどう埋めるか 現代のLLMオーケストレーションパイプラインは、しばしば次の要素を含みます： プランナーエージェント 実行エージェント ツール呼び出しまたはコード実行 中間のの構造出力 他のエージェントによる後続消費 従来の検証手法は最終的な解答の正確性に焦点を当てています。しかし、マルチエージェントシステムでは、失敗はしばしばそれ以前の段階で発生します： 出力が期待される構造に従っていない エージェント間で暗黙的な前提が異なっている 中間変数が誤って解釈されている サブタスクが隠れた制約に違反している これらの問題は単なる推論の失敗ではありません。エージェント間の連携の失敗です。 VERIMAPとは？ VERIMAPは、検証を考慮したプランニングにより、マルチエージェントLLMの連携に対する構造化されたアプローチを導入します。 このフレームワークは以下を含みます： DAG分解による集中的なプランニング複雑なタスクを、有向非巡回グラフ（DAG）として表現されるサブタスクに分解します。サブタスク間の依存関係は明示的にモデル化するのが特徴です。 プランナーが生成する検証関数（VerificationFunctions,VF）各サブタスクに対して、プランナーはPythonまたは自然言語で検証関数を生成します。これらの関数は、出力の正しさに関する明示的な基準を定義します。 検証に基づく実行ループ実行エージェントがサブタスクを実行し、検証エージェントが生成された検証関数を用いて出力を評価します。検証に失敗した場合、システムは再試行または再プランニングを行うことができます。 これにより、検証は後付けではなく、ワークフローの中に組み込まれます。 なぜ検証を前提としたプランニング（Verification-Aware Planning）を重視すべきなのか 以下の領域に取り組む研究者や開発者にとって、 マルチエージェントLLMシステム ツール活用型LLMワークフロー エージェンティックプランニングアーキテクチャ 自律的な推論パイプライン 今回の知見が持つ意味は極めて重大です。 VERIMAPの検証結果は、以下の事実を浮き彫りにしています。 サブタスクの境界を明確化することで、システムの信頼性が向上する 出力制約を明示的に設けることで、エラーの連鎖を抑制できる 局所的な検証が、後続ステップにおける協調エラーを削減する 「プランニング」と「検証」は、密結合に同時設計されるべきである エージェンティックAIシステムにおいて、構造化された出力やAPIレスポンス、JSONスキーマ、そしてツール呼び出しは、単なる実装上の細かなディテールではありません。これらこそが、アーキテクチャの核となるコンポーネントなのです。 プランニングのプロセスそのものに検証を組み込むことが、システムの堅牢性と解釈性の双方を向上させる鍵となります。 QA、プログラミング、数学にわたる実験結果 VERIMAPは、次の領域にまたがる5つのベンチマークで評価されました： 質問応答 プログラムミングタスク 数学的推論 すべてのベンチマークにおいて、VERIMAPは以下を上回りました： 強力な単一エージェントのベースライン 検証を統合していない既存のマルチエージェント手法 特に、次のような難易度の高いタスクにおいて改善が顕著に見られました： BigCodeBench-Hard オリンピック形式の数学問題 これらの結果は、検証を考慮したプランニングが概念的に妥当であるだけでなく、実証的にも有効であることを示しています。 マルチエージェントLLM研究における要点 この研究は、エージェントの信頼性に対する考え方を再定義するものです。 単に「モデルは正しく推論できたか？」と問うのではなく、 「連携における制約は明確に定義され、検証されていたか？」という問いも重要です。 […]
視覚言語モデル（VLM）が矛盾する情報を受け取った時、どのシグナルを信頼するのか？
「混合シグナル（Mixed Signals）」は、視覚言語モデル（VLM）の隠れたバイアスを明らかにし、ヘルスケア、RAG システム、AI の安全性に対して重大な示唆を与えています。
Blue Streams: ワークフローのオーケストレーション
これまでの投稿では、エージェント型フレームワーク「Blue」を紹介し、「エンタープライズ向けエージェント型」の要件や、Blueのアーキテクチャ内にある様々なレジストリを通じてBlueがエンタープライズ統合をどのように支援するかを詳しく説明しました。 このブログでは、ワークフローによる複雑なタスクの実行を容易にするために、Blue のもう一つの重要な抽象化であるストリームについて説明します。私たちは、ストリームがオーケストレーションに不可欠な抽象化であることを説明し、なぜストリームが、企業のスケーラビリティ要件に対応するエージェント型ワークフローのデータと制御のオーケストレーションに適した抽象化であるかを論じます。 Blue v0.9を試す ストリームとは何か？ストリーム処理とは？ コンピュータサイエンスにおいて、ストリーム（stream）とは本質的に動的なデータ構造であり、逐次到着するデータ要素の連なりを表します。例えば、センサーからのデータは、一連の測定値のストリームとして表現できます。ストリーム処理（stream processing）は、ストリームを計算の第一級オブジェクトとして扱い、データの分配・消費・処理を行う演算子とともに扱うプログラミングパラダイムです。map、filter、split、reduceなどの演算子によって、複雑なワークフローを構成し、幅広い種類のデータ計算をサポートすることが可能です。実際、ストリーム処理はオペレーティングシステムや分散システムなどの基盤技術から、データ処理や分析といった応用的な分野に至るまで、コンピューティングの様々な領域で応用されています。 Blueにおけるストリーム Blueにおいて、ストリームはオーケストレーションの中核をなす抽象概念です。ストリームは、データと制御の分配を可能にする仕組みとして機能します。したがって、ストリームはBlueにおけるエージェントやその他のコンポーネント間の通信の基盤を形成しています。 なぜストリームなのか？ Blueにおけるストリームの具体的な説明に入る前に、なぜストリームがエージェントのワークフローに適した抽象概念なのかを考えてみましょう。 第一に、ストリームは複雑なワークフローを効率的かつ効果的に表現でき、データとタスクによって作業を自然に分解することができます。ストリームは動的な構造でもあり、データ内容とストリーム間の接続はいつでも作成・更新できるため、データの処理方法にスケーラビリティと柔軟性を持たせることができます。 第二に、ストリームは可観測性（observability）と制御性（controllability）の向上にも寄与します。データと制御のフローを永続的なデータ構造で明示的に表現することで、デバッグやパフォーマンス上の問題の調査が可能になります。可観測性は、プロダクトデザインの観点だけでなく、ソフトウェアの検証の観点からも非常に重要です。また、エンドユーザーにとっては、システムの出力に対する信頼性を高めるのに役立ちます。 さらに、実運用の観点から見ると、ストリームは”役割の分離”（separation of concerns）を実現する役割も果たし、結果としてシステムの信頼性を向上させます。ストリームは、エージェントやその他のコンポーネント間の通信バスとして機能し、これらのエージェントやコンポーネントを独立して構成・デプロイ・スケールできるようにします。これにより、パフォーマンスと信頼性の両面で利点が得られます。 最後に、ストリームはLLM／AIの世界においても馴染みのある概念です。実際、LLMにデータを入力し、出力を受け取る流れは、ストリームコンピューティングの仕組みと非常によく似ています。多くのLLM APIは、データが生成されると同時に処理できるようにストリーミング出力を提供しています。テキストのみを扱うLLMを超えて、より構造化されたデータを扱うようになると、ストリームはエージェントとの連携のための基盤として拡張可能な仕組みになります。このようにストリームはデータの内容（データセマンティクスの曖昧性を減らす）とデータの流れ（処理の曖昧性を減らす）の両方に構造を与えることで、システム全体の制御性を高めます。 ストリームはBlueでどのように機能するのか？ Blueにおいて、ストリームとは本質的に「メッセージ」と呼ばれるデータの列です。ストリームには一意のIDが付与され、タグによって内容の属性を記述できます。例えば、あるストリームにUSERタグが付けられている場合、そのストリームの内容があるユーザーから発信されたものであることを示します。 各ストリームは、ストリームの開始を表す特別なメッセージBOS（Beginning of Stream）で始まり、複数のメッセージを挟んで、ストリームの終了を示す特別なメッセージEOS（End of Stream）で終わります。BOSとEOSによって、ストリームを処理するエージェント（consumer）は、計算やリソースの初期化および終了処理を行うことができます。 ストリームメッセージ ストリーム内の各メッセージは、3つの要素からなるタプルで構成されます。 k はメッセージのキーまたはID、 v はデータ、 t はメッセージのタグを表します。 k はデータを一意に識別するために使われるほか、アグリゲーションのように計算のキーとして使用することも可能です。 vはメッセージ内のデータを表し、 float や str などの基本的なデータ型から、複合データを表すJSON形式まで、様々な構造化データを表現できるよう標準化されています。 t はデータの意味（セマンティクス）を示すタグであり、DATAやCONTROLといった基本タグから、よりアプリケーション固有のセマンティクスまで、複数の値を取ることができます。例えば、ストリームが複数の履歴書（レジュメ）からなる文書のシーケンスを含んでいる場合、それぞれのメッセージはレジュメとして扱われ、レジュメID、本文、DOCやRESUMEといったタグを持つことができます。 Blueのメッセージの大半はデータメッセージであり、エージェントが取得し処理するためのデータを提供します。しかし、Blueにはコントロール（制御）メッセージも存在します。これは本質的に、エージェントがストリームを処理させるための指示を表します。例えば、あるエージェントが他のエージェントに何かを計算させたい場合、メッセージを出力して依頼できます。これはツールの呼び出し（tool calling）に似ていますが、ツールだけでなく他のエージェントも対象とする点で拡張的です。これらのコントロールメッセージは、「実行時に動的に生成される指示（インタプリタ形式のコードのようなもの）」として表現され、エージェント同士を結びつける明確な役割を担います。さらに、これらの指示はデータと同様に明示的に表現され、コンピュータシステムにおける命令キュー（instruction queue）のような役割も果たします。コントロールメッセージは、どのエージェントでも使用でき、別のエージェントに処理を依頼したり、全体の実行フローを管理するプランナーエージェントが利用したりすることも可能です。これらのメッセージは、任意のストリームに含めることも、制御専用のストリームに分離して構成することもできます。 コントロールメッセージも、k（キー/ID）、v（コントロールメッセージの構造を記述するための特定の構造を持つ値）、t（そのメッセージがコントロールおよび指示メッセージであることを明示的に示すタグ）という、同じタプル形式のコンポーネントを持ちます。エージェントの実行命令を表す場合、実行対象のエージェント（A）と、任意のプロパティ（P）、処理対象のストリーム（S）が含まれます。これにより、コントロールメッセージがどのエージェントにどのような操作をさせるべきかを具体的に記述することができます。そしてtにより、このメッセージが制御および指示用であることが明確にタグ付けされます。 ストリームとエージェント Blueにおいて、エージェントはストリームデータの主要な”消費者”であり、”生産生成者”でもあります。エージェントは、ストリーム内のすべてのメッセージに対して実行される プロセッサ関数（processor function） を定義し、必要に応じて新しいストリームにデータを書き込むことも可能です。エージェントは複数の入力・出力パラメータを持つことができ、入力ストリームはプロセッサの特定の入力パラメータにマッピングされ、出力データは特定の出力パラメータに割り当てられるようになっています。例えば、インテント分類エージェント（intent classifier agent）は、 TEXTのような名前付き入力パラメータと、INTENTのような出力パラメータを持つことができます。さらに、エージェントはデータ処理をガイドするプロパティも持ちます。例えば、インテント分類エージェントは、インテント識別に使用するモデルを指定する […]
Blue: エンタープライズ向けエージェント型のデザイン
エージェントによるワークフローをサポートするために、企業システムはどのように進化できるでしょうか？本記事では、AIエージェントやデータ、サービスを、スケーラビリティと可観測性があり、制御可能なエンタープライズ・アプリケーションに統合するためにデザインされたフレームワークであるBlueの概念的基盤を探ります。
単一文書を超えて：LLMによる複数文書推論の進展
私たちは、自然言語処理における喫緊かつ未開拓のトピックである「複数文書推論」に取り組む3つの新しい論文を紹介します。これらの論文は、大規模言語モデル（LLM）が複数の情報源にまたがる複雑性をどのように扱うかについて、厳密なベンチマーク、新しい方法論、経験的洞察を提供します。
Blue v0.9: エンタープライズ向けエージェント型フレームワーク
私たちのBlue v0.9は、エンタープライズ環境でエージェント型ワークフローを構築・展開するためのオープンソースフレームワークです。従来のAIフレームワークとは異なり、Blueは、スケーラビリティ、可観測性、設定の柔軟性、既存のインフラとの統合性など、エンタープライズ規模の要件を念頭にデザインされています。
ランキングの再考: LLMを活用したマルチ条件ランキング（MCR）の提案
MCRankベンチマークとEXSIR手法を用いることで、構造化された推論によりLLMの性能がこれらの難解なタスクで大幅に向上することを示しました。
複合AIシステムの最適化
複合AIシステムの最適化フレームワークは、精度・コスト・遅延などの多目的最適化や複数プランの最適化、特に予算などの制約管理を含む幅広い目標を達成すべきであると述べています。これらの最適化目標は決して網羅的ではありませんが、エンタープライズ環境において重要な要素です。
GiNZA version 4.0: 多言語依存構造解析技術への文節APIの統合
Universal Dependenciesのもとで日本語文法に根ざした直感的な統語解析を可能にしたい。GiNZAが目指してきた自然言語処理のゴールにまた一歩近づきました。2020年8月16日にリリースした「GiNZA version 4.0」ですが、日本語の公式サポートが始まったspaCy version 2.3を土台とし、機能と性能を隅々までブラッシュアップしています。これまで以上に日本語の分析が容易になったGiNZA v4の文節APIについて詳しく解説します。 GiNZAで出来ること NLP（自然言語処理）技術は人が日常的に使う言葉を機械的に分析するための一連の解析処理に用いる技術の総称です。この「一連の解析処理」という部分が非常に重要で、例えば日本語の書き言葉の文であれば、最初に単語を区切ってからそれらを文節にまとめて係り受け関係を解釈する、という流れになります。英語の文の場合、単語はほぼスペースで区切られていますが、”New York”のような複合語をまとめたり、”don’t”を”do”と”not”に分けて解釈する必要があるため、最初にトークナイズ処理を行ってから名詞句・動詞句などの基本句の認識と句の間の依存関係の解釈を行う流れになります。また言語を問わず人名・地名などの固有名詞は複合語で表現されることが多いため、それらの単語をまとめ上げて分類を与える固有表現認識処理も必要となります。 GiNZAは多言語NLPフレームワークであるspaCyを利用して、日本語の解析に必要な一連の処理の流れ（パイプライン）を実装しています。spaCyは主に西洋言語を念頭に設計・開発されたフレームワークのため、日本語の形態素解析処理は標準では組み込まれていません。spaCyは日本語モデルをインストールする際に形態素解析器のSudachiPyを同時にインストールします。GiNZAもパイプラインの先頭でSudachiPyを利用してトークン化 ( 単語区切り ) と品詞付与を行っています。 パイプラインの次のステージではspaCy標準のCNN依存構造解析器でトークン間の依存関係を決定し、文の中心となるトークンをrootとして、主語 ( nsubj ) や目的語 ( obj・iobj ) のトークンとの関係を有向グラフとして出力します。この有向グラフをNLP用語で構文木と呼びます。さらにパイプラインの次のステージではCNN固有表現認定器が入力された構文木から固有表現区間を認定し分類を付与します。ここまでの流れはspaCyの公式日本語モデルとGiNZAでほぼ同じです。 GiNZAのパイプラインの末尾にはCompoundSplitterとBunsetuRecognizerの2つの独自コンポーネントが追加されています。CompoundSplitterでは設定によりトークンを2段階に細分化して出力することが可能です。パイプライン末尾のBunsetuRecognizerは、文節のヘッドとなるトークンをマーキングする特別な依存関係ラベルを検知して、構文木から文節およびその主辞の区間を高い精度で認定します。この文節認定処理結果を取得するAPIについて次の節で説明します。 GiNZAの文節API GiNZA v4でginzaパッケージに文節を処理単位とするAPIが多数追加されました( import ginza で利用可能)。文節APIの一覧はこちらで確認してください。ここではそのうち代表的なものを紹介します。 ginza.bunsetu_spans(doc_or_span) 引数で与えられたDocまたは文のSpanに含まれる文節区間をSpanのリストとして返します。： # Sample code import spacy import ginza nlp = spacy.load(“ja_ginza”) doc = nlp(“銀座でランチをご一緒しましょう。”) print(ginza.bunsetu_spans(doc))) >> [銀座で, ランチを, ご一緒しましょう。] ginza.bunsetu_phrase_spans(doc_or_span) 文節の主辞区間をSpanのリストを返します。： print(ginza.bunsetu_phrase_spans(doc)) >> […]
