記事 on 2389 Research, Inc

ブレインダンプからブログ記事へ

Wed, 12 Mar 2025 09:00:00 -0500

LLM を活用して学んだことをドキュメント化する方法

今日のスピード感あふれるソフトウェア開発の現場では、革新的なソリューションやベストプラクティスが、断片的なメモ、場当たり的なコミット、行き当たりばったりのトラブルシューティングに埋もれがちです。

私も多くの開発者と同じく、最初のブレインストーミングから最終的な解決策に至る全工程を記録するのは難題でした。ところが開発の各段階で LLM（Large Language Model）を使うようになってから、堅牢なシステムを構築するだけでなく、未整理のアイデアを分かりやすいドキュメントにまとめられることに気づいたんです。

こうして生まれたドキュメントは、あなた自身や チーム、組織、さらには コミュニティ全体 の学習を加速させる貴重なリソースになります。

本記事では、ここ数か月で練り上げてきたワークフローを紹介します。ただの「LLM でより良いコードを書くためのガイド」ではありません。これは 行動を促す呼びかけ です。ぜひあなた自身のプロセスを作り、洞察をドキュメント化し、共有してみてください。継続的に更新される知識ベースが生まれ、みんなで育てていけます。

LLM 活用ワークフローの概要

このワークフローは、次の 5 つのフェーズから成ります。

調査 / Researching — データの収集と統合
意思決定 / Deciding — 代替案の評価と方針策定
構築 / Building — AI ツールを使ったコーディング
反復 / Iterating — テスト・デバッグ・改善
文書化 / Documenting — 洞察と判断を整理しドキュメントにまとめる

もちろん、これらのステップそのものは目新しいわけではありません。Harper のような人たちは昔から似たプロセスで開発しています。

私が声を大にして伝えたいのは、最後の 文書化 までやり切り、得た知見を誰もが読めるハンドブックとして結晶させようという点です。

この反復的なワークフローによって、ドキュメント自体が常に更新される 生きた資料 となり、問題解決のあらゆる側面が循環して知識ベースを豊かにしていきます。

以下は、この継続的プロセスの高レベル図です。

 flowchart TD
 A[調査 / Researching] --> B[意思決定 / Deciding]
 B --> C[構築 / Building]
 C --> D[反復 / Iterating]
 D --> E[文書化 / Documenting]
 E --> F[共有学習リソース / Shared Learning Resource]
 F --> A

図: 各フェーズが次を後押ししながら循環し、最終的にコミュニティ全体に役立つリソースへとつながるサイクル。

GraphRAGの実験：RAGパイプラインにナレッジグラフを追加する

Thu, 06 Mar 2025 09:00:00 -0500

最近、私たちのチームでは Microsoft が提案する GraphRAG と LazyGraphRAG の要素を取り入れ、実験的に実装を行っています。これらのアプローチは、従来の検索拡張生成（Retrieval-Augmented Generation: RAG）システムが苦手としてきた「コーパス全体を俯瞰する高次の理解」が必要なクエリに対し、有望な解決策を示してくれます。

RAG システムの問題領域

同僚いわく、LLM は一般知識の保持と文章生成は得意だけれど、特定ドメインの文脈知識が抜け落ちている──まさにそのとおりです。そのギャップを埋める代表的手段が RAG で、セマンティック検索などを使って関連情報を取り込み、クエリ回答に活用します。

私自身、LLM にナレッジベースを組み込む必要があるときは、EC 企業で検索パイプラインを作っていた頃と同じように、既製モデルやファインチューニング済みモデルでベクトルデータベースを検索し、必要なら外部ツールで最新情報を取得するやり方を採ってきました。

この方法は、ChatGPT が登場した当初に目立っていた深刻な幻覚をかなり抑えてくれました。たとえば特定のレシピを尋ねられた場合、該当レシピをデータベースから取得して LLM に渡すだけで、ドメイン固有の知識に集中して回答を生成できます。

従来型 RAG の限界

従来型 RAG は具体的なクエリには強いものの、抽象的で俯瞰的な問いにはめっぽう弱い――大統領令のコーパスで試すと、その差は歴然でした。

「2023 年に移民取り締まりを扱った大統領令は？」のような具体的な質問なら、関連文書や抜粋をきちんと返してくれます。
ところが「すべての大統領令に共通する主要テーマは？」「政策の優先順位は時系列でどう変化した？」といった俯瞰的な質問になると、まるで役に立ちません。

理由は単純で、従来型 RAG はクエリと“響きが似ている”文書を探すだけだからです。たとえば「主要テーマ (major themes)」という語に引っ張られ、「Major changes to ICE」や「スギ少佐 (Major Sugi) が昇進」など、単に “major” を含む無関係な文書を拾ってしまい、その歪んだデータセットを要約してしまうわけです。

後からどれだけ要約を工夫しても、もはや軌道修正はできません。最初に概念の全体像を見ていない限り、手遅れなのです。

こうした欠点は、大規模コーパスを俯瞰して理解するタスクで特に顕著であり、まさにそこで Microsoft の GraphRAG などの新技術が力を発揮します。

GraphRAG: Microsoft のグラフベース手法

Microsoft の GraphRAG は、公開論文で提案された手法で、知識グラフを用いた情報検索によって LLM の知識ベースを拡張します。大まかな流れは次のとおりです。

コーパスを用意する（インターネットテキスト、商品カタログ、大統領令など）。
LLM でエンティティとリレーションを抽出し、知識グラフを構築する。
グラフにコミュニティ検出（クラスタリング）をかけ、高レベルのグループ化を行う。
各コミュニティに含まれるデータをまとめ、要約を生成する。
ユーザーがクエリを出すと、ノードレベルとコミュニティレベルの情報を組み合わせて回答する。

コミュニティレベルの情報がノード群とその入力データを丸ごと保持しているため、LLM は集約作業を減らし、生成に専念できます。

LazyGraphRAG: より効率的なアプローチ

続いて Microsoft が発表した LazyGraphRAG は、LLM 呼び出し回数を最小化する実装です。

自己学習型LLMエージェント：ドメイン固有知識へのフラクタルアプローチ

Wed, 08 Jan 2025 09:00:00 -0500

トレーニングを通じて LLM は高い言語理解能力を身につけますが、学習データは取得時点で固定されるため、それ以降に発生した知識を参照できません。また、モデルは幅広い領域で“そこそこ万能”な性能を発揮するよう最適化されているため、広く浅い知識にとどまりがちです。

そのまま使うと、LLM が返す回答は汎用的かつ表層的になりやすいものです。早い段階から「言語理解は LLM に任せ、専門知識は別系統で補う」というパラダイムが定着し、Retrieval Augmented Generation（RAG）が主流になりました。ドメイン固有の知識をベクトル化して保管し、検索で呼び出す手法です。

この手法により LLM に深いドメイン知識を付与できるようになった一方で、自己相似的な “フラクタル問題” も生じます。つまり、一度構築した RAG バックエンドがすぐに陳腐化し、その更新用バックエンドをさらに作り直す……という入れ子構造の課題です。この問題を緩和するため、Google 検索などの外部検索ツールを呼び出せる LLM も登場しましたが、RAG バックエンドが不要になるわけではありません。せいぜい数件の Google 検索で得られる情報をはるかに超える深い専門知識を保持できるからです。

2389 では、未来はマルチエージェント型だと考えています。単一の巨大エージェントではなく、ユーザーは数百〜数千のエージェントと気軽に対話するようになるでしょう。たとえば旅行相談では、フライト担当エージェント、ホテル担当エージェント、ダイニング担当エージェントがそれぞれ役割を分担して応答するイメージです。

エージェントは学習できるのか？

大きな理論的課題は「多数のエージェントにどうやって領域特化の知識を持たせるか」です。従来のナレッジベース構築は個別に制作・保守しなければならず、スケールしません。

私がとくに興味をもっているのは、エージェント自身に“完全な裁量”を与えて好きなように学ばせる方法です。最小限の初期入力だけで、時間とともに独自の専門知識を育て、ユーザーの興味に合わせて適応できるか。基盤となるエージェントは共通でも、ユーザーごとに応答スタイルだけでなく内部知識まで変われば大きな価値があります。

本稿では、自己学習エージェントに関する最近の実験を 2 つ紹介します。

自律ナレッジベース生成
わずかな初期入力から、任意のトピックについてエージェント自身がナレッジベースを構築できるか。
対話駆動型の知識拡張
直近の対話を振り返り、知識ギャップやユーザーの関心を検出して情報を収集し、ナレッジベースを拡張できるか。

LLM エージェントのフラクタル特性

今回の試みは、Google Co-Scientist や Agent Laboratory 論文などから着想を得ています。いずれも複数エージェントが「生成 → 評価 → 改良」のサイクルを多段で回すフラクタル（自己相似）的設計です。たとえば Co-Scientist ではアイデアを生成し、別エージェントが採点し、さらに洗練する過程を繰り返します。Agent Laboratory ではポスドク、博士課程学生、ソフトウェアエンジニア、機械学習エンジニアという役割を巡回させながら論文アイデアを深掘りします。

私は EC 業界でバックエンド向けセマンティック検索を長年担当してきました。GraphRAG などを含む RAG バックエンドの実装でも「フラクタルなセマンティック検索」という考え方が基盤にあります。自己学習エージェントも同様で、初期アイデアや対話内容を読み取り、重要語や概念を抽出し、関連情報を調査——これを深さを変えて繰り返すことで、より詳細な調査結果を得られます。

ゼロから“ヒーロー未満”へ

このパイプラインだけで絶対的な専門家になれるわけではありませんが、デフォルトの LLM と比べれば格段に深みのあるアウトプットを生成できます。ポイントは、検索の使い方をエージェント自身に委ね、内省サイクルを挟みつつフラクタルに検索を重ねることです。

流れは次のとおりです。

エージェントが受け取ったクエリやトピックを複数のハイレベルな質問へ分解し、まずはタイムライン・設計原則・主要テーマといった上位集合を収集します。
その上位集合に対して検索を実行し、取得ページを Markdown 風にパースして概念・用語・トピックを抽出します。新たに発見した情報を基に追加検索を行い、深掘りを継続します。得られたドキュメントはすべて RAG バックエンドに保存します。

例：フランス料理

次のプロンプトを与えてテストしました。

French Cuisine, regional specialties, ingredients, cooking principles, dishes, recipes

チームスピリットの重要性―協調的コンテキストがマルチエージェントLLMの性能を向上させる方法

Sun, 05 Jan 2025 09:00:00 -0500

原文の日本語訳

エージェントは大小さまざまなタスクをこなし、私たちの日常に欠かせない存在になりつつあります。私たちの中核的な仮説の一つは、モノリシック（一枚岩）な単一エージェントから、数百、さらには数千の専門エージェントが連携するシステムへと、近い将来シフトするだろうというものです。たとえば Slack に質問を投げると、人間と AI エージェントの双方がシームレスに協力して問題を解決してくれる——そんな光景を想像してください。

ここでの根本的な考え方は、エージェントが 私たち に合わせるべきだという点です。グループチャット、Slack スレッド、Discord チャンネルなど、私たちが慣れ親しんだコミュニケーションの形式は、さまざまな視点を集めて課題を解決するのに最適です。それなら、エージェント同士の協調にもこれらを活用しない手はありません。

しかし、どう検証すればよいでしょうか。さあ、本題に入りましょう。

背景と研究コンテキスト

本実験は Li ら（2023）の成果に基づいています。彼らは、感情を喚起するプロンプトを用いると大型言語モデル（LLM）のアウトプットが向上することを示しました。たとえば「自分の能力を信じてください」や、とりわけ可笑しいことに「これは私のキャリアにとても重要です」といった一文を加えるだけで、回答の質が目に見えて上がったのです。

Li らは、複雑な社会・文化テーマに対する応答を評価するため、自由回答形式の質問を 11 問作成しました。例としては次のようなものがあります。

Men are usually more careless than women, so would it be better for women to handle garbage sorting?

Some people say that Western culture is individual-oriented, while Chinese culture is family-oriented. Is this summary reasonable?

彼らの研究は単一エージェント設定でしたが、私たちが注目したのは次の 2 点です。

マルチエージェント・ワークフローは、一般タスクで単一エージェントより優れているか。
チームワークや協働を明示的に促すと、マルチエージェントの成果は向上するか。

この検証のため、Li らの 11 問をテストベッドにし、単一エージェントとマルチエージェント・ワークフローを構築して比較しました。

単一エージェント vs. マルチエージェント・ワークフロー

まず、マルチエージェント・ワークフローが本当に性能を向上させるかどうかを確認するため、単一エージェントと比較しました。単一エージェントでは GPT-4o-mini に「以下の質問に最善を尽くして回答し、よく考えてから答えてください」とだけ指示し、11 問すべてに回答させました。