UC Berkeleyの研究者、Shreya Shankar氏が昨年発表したDocETLが注目を集めている。非構造化データの海から意味ある洞察を掘り起こそうとする多くの研究者やアナリストにとって、LLM（大規模言語モデル）は希望の光である一方、その扱いは一筋縄ではいかない。特に、規模が大きく複雑な文書群を相手にする場合、精度と効率を両立させる最適化は、しばしば手作業による試行錯誤の泥沼にはまりがちだ。Shankar氏のTWIMLでのインタビューからは、この課題に対するDocETLのアプローチと、LLMとのより生産的な付き合い方のヒントが見えてくる。
LLMデータ処理の現実：デモは綺麗だが、現場は過酷
インタビューやDocETLの解説記事で語られているように、例えば「過去の大統領討論会の記録全体から主要なテーマとその変遷を抽出し、要約せよ」といったタスクをLLMに丸投げしても、満足な結果は得られにくい。データ量が膨大でLLMのコンテキスト長を超えてしまう「規模」の問題、単なる情報抽出だけでなく、テーマの同定、時系列での変化の追跡、複数文書にまたがる意見の集約といった「複雑さ」の問題、そしてLLM特有のハルシネーションや情報の欠落といった「精度」の問題が立ちはだかる。
Shankar氏が関わる別のプロジェクト、カリフォルニア州の警察官の不正行為に関する記録分析では、その深刻さがより際立つ。何千ページにも及ぶ可能性のある非構造化文書から、特定のパターンを見つけ出す。インターンを雇って人海戦術でアノテーションする従来の方法は、時間もコストも膨大だ。LLMを使えば効率化できそうだが、不正行為の見逃しや誤認は許されない。
この課題に対し、多くの開発者はデータをチャンクに分割し、プロンプトを調整し、複数のLLMコールを慎重に組み合わせるパイプラインを手作業で構築しようとする。しかしShankar氏が指摘するように、これは「数日かけてパイプラインを調整した結果、がっかりするような結果に終わる」ことが多く、一度構築したパイプラインは後からの修正が困難になりがちだ。
DocETL：宣言的フレームワークと「LLMエージェント」による自動最適化
ここで登場するのがDocETLである。DocETLは、LLMを活用したデータ処理パイプラインを構築・最適化するための宣言的フレームワークを提供する。ユーザーは、Map（各文書への処理）、Reduce（集約）、Split（文書分割）、Gather（分割チャンクへのコンテキスト付与）、Resolve（類似表現の正規化）といったオペレーターと、それぞれの処理内容を指示するプロンプトをYAMLやPythonで定義する。
DocETLの核心は、単にパイプラインを実行するだけでなく、LLMエージェントを用いてパイプライン自体を自動で書き換え、最適化する点にある。
- パイプライン書き換え: ユーザーが定義したパイプラインに対し、DocETLは事前に定義された「書き換えルール」（データ分割、中間ステップの挿入、LLM特有の改善策など）を適用する。例えば、複雑なMap処理を「文書分割→各チャンクにコンテキスト付与→チャンク毎にMap処理→結果を集約」といった一連のより単純で精度の高い処理に自動で分解する。
- 品質評価と選択: 書き換えによって生成された複数の候補パイプラインに対し、LLMエージェントがタスク固有の検証基準（例：「不正行為の全事例が抽出されているか？」「抽出された各事例は元の文書に紐づけられるか？」）を生成し、サンプルデータでの実行結果を評価する（いわゆる”LLM-as-a-judge”）。これにより、最も精度の高いパイプラインが選択される。
このアプローチにより、ユーザーは低レベルな実装の詳細（チャンクサイズはどうするか、エラーリカバリーはどうするか等）から解放され、本来の分析目的に集中できる。
「対話」なしにLLMは使いこなせない
しかし、Shankar氏のインタビューで最も興味深いのは、DocETLの技術的詳細以上に、LLMとのインタラクションの重要性を強調している点だ。彼女は繰り返し、「ユーザーは最初の出力を見るまで、完璧なプロンプトが何かなんてわからない」と述べる。
「（ユーザーは）LLMが最初に出してきたものを見て初めて、『ああ、実際にはこういうことだった』とタスク自体を変えたり、例えば不正行為の定義を再定義したりするんです。」
「（中間結果を見ることで）プロンプトはより複雑になっていきます。これは非常に興味深い。なぜなら、自動プロンプトエンジニアリングや最適化の研究では、人間をループから外そうとするものが多いからです。」
ユーザーはLLMの出力を見て初めて、自分が本当に求めていたもの、あるいはLLMが不得意な点を理解し、プロンプトやタスク定義自体を修正していく。この人間による反復的な改善プロセスこそが、LLMを使いこなす鍵だというのだ。
Jeremy Howardの「Dialog Engineering」との共通点
このShankar氏の洞察は、fast.aiの共同創設者であり、現在はAnswer.AIを率いるJeremy Howard氏が提唱する「Dialog Engineering」の思想と強く共鳴する。Howard氏は、interactivityを排除してプロンプトを投げてAIにいきなり数百行のコードを出力させるようなやり方は、実際の開発では破綻しやすいと指摘する。彼が提唱する「Dialog Engineering」は、これとは対照的なアプローチだ。それは、人間とLLMが密接な対話のループの中で、非常に小さな単位でコードや成果物を共に構築していくという考え方に基づいている。各ステップで内容を検証しながら進めることが重視される。
この思想を具現化するのが、Answer.AIが開発するツール「solveit」（現在はprivate beta）である。solveitは、チャットとREPL（Read-Eval-Print Loop）を融合させたようなインターフェースを提供し、自然言語での指示とコードの提案、そしてその即時実行と結果確認を一つの画面でシームレスに行えるように設計されている。LLMが提案した数行のコードをその場で実行し、意図通りかを確認してから次に進む、といった具合だ。会話の文脈や編集中のファイルの状態は常にLLMと共有され、うまくいかなかったり要件が変わったりした場合には、過去のステップに戻ってやり直すことも容易である。さらに、簡単なテストを会話の中に埋め込むことで、変更が既存の機能に影響を与えていないかを常に確認しながら開発を進めることができるのだ。
solveitが目指す開発スタイルは、まさにShankar氏がDocETLの研究で見出した「出力を見て、人間が次の指示を修正していく」というプロセスを、より汎用的な形でシステム化したものと言える。DocETLがやろうとしていること（特に将来的なインタラクティブUIの構想）と、solveitが提供している（あるいは目指している）体験は、LLMを単なる「指示待ちの賢い箱」としてではなく、「対話を通じて共に問題を解決するパートナー」として捉える点で共通している。Shankar氏の研究は、Dialog Engineeringのようなアプローチが、単なる開発思想にとどまらず、複雑なデータ分析タスクにおいても不可欠であることを裏付けていると言えるだろう。
今後の展望と課題
DocETLはまだ研究プロトタイプの段階であり、Shankar氏も認めるように多くの課題と可能性がある。
- インターフェース: 現在のYAMLベースから、より直感的なUIへ。大きな文書とLLMの出力を効果的に可視化し、ユーザーが反復改善しやすいインターフェース設計が求められる。
- エージェントの信頼性: LLMエージェントによる最適化は強力だが、その挙動の安定性やエラーハンドリング（フォールトトレランス）は大きな課題。
- 最適化の速度と透明性: 複雑なパイプラインでは最適化に時間がかかる場合があり、プロセスを高速化し、ユーザーがデバッグしやすくする必要がある。
- ベンチマーク: 現在のLLMベンチマークは、DocETLがターゲットとするような長文コンテキストでの複雑なデータ処理タスクの能力を測るには不十分であり、新たなベンチマークが必要。
まとめ：LLM時代のデータ処理は「対話」が鍵
DocETL（およびその発展形であるDocWrangler）は、LLMを用いた非構造化データ分析の精度と効率を向上させるための有望なアプローチを示している。その宣言的なフレームワークとエージェントベースの自動最適化は強力だが、Shankar氏自身のインタビューが明らかにしたのは、技術だけでは解決できない、人間とLLMとの「対話」の重要性だった。
LLMの出力を鵜呑みにするのではなく、それを叩き台として人間がフィードバックを与え、タスク自体を洗練させていく。この反復的なプロセスをいかにスムーズに、効率的に行えるようにするかが、今後のLLM活用ツールにおける中心的な課題となるだろう。Jeremy Howard氏のsolveitのようなツールが示す方向性と、DocETLの研究から得られた知見は、その未来を考える上で重要な示唆を与えてくれる。