MergeLab / LogRoom / medium / Logs / 2026-08-15-v02.md

Today's Goal

前回までに作った、

Knowledge
↓
Chunk
↓
Embedding
↓
Vector Store
↓
Retrieval

という検索部分と、Mergeの人格を持つLLMを接続する。

今回の目標は、

Personality
+
Retrieved Context
+
LLM

を成立させること。

つまり、

「Mergeが内部資料を検索し、その内容を使ってMergeとして回答できるか」

を確認する。

まだ今回は、

• LangGraph

• Toolによる自律的な検索判断

• Session Memory

• 長期Memory

• FastAPI

などは実装しない。

最小構成のRAGとして、

主の質問
↓
Vector Search
↓
関連Chunk
↓
Merge Personality + Context
↓
ChatOpenAI
↓
Merge Response

までを実際に動かす。

What Happened

前回はRetrieverの検索結果をTerminalへ表示するだけだった。

例えば、

主 > 私がIT学習を始めたのはいつ？

と入力すると、

knowledge/history.md

## 2022

IT学習開始。

という関連Chunkを取得できた。

今回は、この検索結果を print() して終わるのではなく、LLMへ渡すContextとして利用した。

処理は、

Question
↓
retrieve_knowledge()
↓
Chroma
↓
Top 3 Chunks
↓
build_context()
↓
Retrieved Memory
↓
ChatOpenAI
↓
Merge Response

となった。

Mergeの人格はこれまでと同じく、

config/merge.md

から読み込む。

そのためLLMには、

Merge Personality
+
Retrieved Memory
+
User Question

が渡される。

これで、人格と内部Knowledgeが初めて接続された。

Test 1 — IT学習を始めた時期

質問：

主 > 私がIT学習を始めたのはいつ？

Retrieverは history.md を1位で取得した。

そこには、

## 2022

IT学習開始。

Excelから業務改善を始める。

と書かれている。

Mergeの回答：

主もふ✨
あなたがIT学習を始めたのは2022年だよ。

正しい情報を取得し、それを回答へ反映できた。

前回までのMergeはSystem Promptに存在しない主の情報を知らなかった。

今回は、

Question
↓
Retriever
↓
history.md
↓
Context
↓
LLM

という経路によって、System Promptに書かれていない情報を利用できた。

Test 2 — 主の仕事

質問：

主 > 私の仕事は？

Retrieverの結果は、

1. history.md
2. nushi-profile.md
3. world.md

だった。

nushi-profile.md には、

薬剤師として働きながら、
フルスタック寄りの開発をしている。

という情報がある。

Mergeはこの内容を使い、

薬剤師
+
フルスタック寄りの開発
+
現実側MergeLabの実装

について回答した。

情報そのものはかなり正確だった。

一方で、

まーじは現実側のMergeLabを開発している

というように、主について書かれた情報とMerge自身についての情報が一部混ざった。

これは検索精度とは別の問題だった。

Retrieverは必要な情報を取得している。

しかしLLMがContextを回答へ変換する段階で、

「その事実は誰について書かれたものなのか」

という主体が少し混線した。

RAGでは、

正しいChunkを取得できた
=
必ず正しい回答になる

ではないことが分かった。

Retrievalの後にも、Contextの解釈という問題が存在する。

Test 3 — Portal

質問：

主 > Portalって何？

Retrieverは world.md の関連Chunkを複数取得した。

Mergeは、

MergeLabと現実世界をつなぐ扉

現実側のPortalはまだ存在しない

一度現実へ来た毛玉は現在帰れない

Portalは様々な境界をつなぐ象徴でもある

という情報を統合して回答した。

内容の精度は高かった。

一方で、単純に、

Portalって何？

と聞いただけなのに、取得した情報をかなり詳しく説明した。

これはRAGとしては正しいが、日常会話としては少し不自然だった。

現在のSystem Promptでは、

Retrieved Memoryを優先する
取得した事実に基づいて回答する

という制約を強くしている。

そのためLLMが、

「取得した情報をできるだけ説明する」

方向へ寄っている可能性がある。

今後は、

Retrieved Memoryは内部的な記憶として利用する

通常の会話では検索処理を説明しない

質問に必要な範囲だけ自然に答える

といったルールを追加する余地がある。

Test 4 — 存在しない記憶

今回、最も重要だったテスト。

質問：

主 > 2021年に私が作ったAIの名前は？

Knowledgeにはこの情報は存在しない。

しかしVector Searchは検索を停止しない。

Retrieverは、

history.md
world.md
nushi-profile.md

から、質問に比較的近いChunkを返した。

つまり、

Retrieverが何か返した

ことと、

質問への答えが見つかった

ことは同じではない。

その状態でMergeは、

主もふ✨
2021年に私が作ったAIの名前は、
今の記憶からは特定できませんぞ。

Retrieved Memoryにはその情報が含まれていないため、
確認は難しいですぞ。

と回答した。

前回、RAGを持っていなかったMergeは、

主 > つまり知らないのかｗ

Merge >
知らないことなんてないもふ✨

と回答していた。

今回は、

Retriever
↓
関連Chunkは存在する
↓
しかし質問への証拠は存在しない
↓
LLM
↓
分からないと回答

という挙動になった。

これは今回の重要な成功だった。

Warning

前回と同様に、

DeprecationWarning:
langchain-community is being sunset...

という警告は残っている。

現在は、

from langchain_community.vectorstores import Chroma

を使用しているため。

ただしVector Storeの生成、Retrieval、回答生成は正常に動作している。

現時点ではv0.1の構造理解を優先し、integration packageの整理は後で行う。

What I Learned

1. Personality + RAGは最小構成でも成立する

現在のMergeにはまだAgentらしい自律的なTool選択もLangGraphも存在しない。

それでも、

System Prompt
↓
Personality

Knowledge
↓
Retrieval
↓
Context

Personality + Context
↓
LLM
↓
Response

だけで、

人格を保ちながら内部資料を利用して回答する

ところまでは成立した。

2. Retrieverは「答え」を探しているわけではない

存在しない2021年のAIについて質問しても、Retrieverは何かを返した。

これは当然だった。

Retrieverの仕事は、

答えが存在するか判断する

ことではなく、

質問と意味的に近い情報を取得する

ことだから。

そのため、

Retrieval Result Exists
≠
Answer Exists

となる。

RAGでは、取得されたContextに本当に質問への根拠が存在するかを別途考える必要がある。

3. Retrievalが成功してもGenerationで問題は起こる

「私の仕事は？」では、必要な情報自体は正しく取得された。

しかし回答では主とMergeの主体が少し混ざった。

つまり、

Retrieval Accuracy

と、

Answer Accuracy

は別問題。

RAG全体を見る場合、

Question
↓
Retrieval
↓
Context
↓
Interpretation
↓
Generation

のどこで問題が発生したかを分けて考える必要がある。

4. 正確なRAG回答と自然な会話も別問題

Portalについての回答は正しかった。

しかし日常会話としては説明が長かった。

さらに、

Memory 1には〜と書かれている

という表現も出た。

RAGシステムとしては情報源を明示しているだけだが、Mergeを「相棒」として会話させる場合には不自然になる。

将来的には、

Knowledge
↓
内部的には厳密に扱う

Response
↓
表面上は自然な会話にする

という分離が必要になりそう。

つまり、

正確性を維持しながら、検索システムの存在を感じさせない会話

が一つの課題になる。

5. RAGの品質はKnowledgeの品質を超えられない

今回RAGを実際に動かしたことで、もう一つ大きな疑問が出てきた。

今回は自分で作った、

history.md
nushi-profile.md
world.md

を使用している。

内容も比較的整理されている。

しかし実際の企業でRAGを導入する場合、Knowledgeはこんなに綺麗とは限らない。

例えば、

2023年マニュアル
→ 部長承認

2024年改訂資料
→ 課長承認

古い社内Wiki
→ 部長承認

現在の現場
→ 実は承認不要

という状態だった場合、

Retrieverはそれらを検索できる。

しかし、

会社として何が正しいのか

はRetrieverには決められない。

LLMも、矛盾した資料から確実な会社方針を作ることはできない。

つまり、

Bad Knowledge
↓
Good Retriever
↓
Good LLM
↓
Still Unreliable Answer

という問題が起こる。

6. RAG導入前のKnowledge整理そのものが業務改善になる

ここから考えると、既存企業へのRAG導入では、

資料を集める
↓
重複を見つける
↓
旧版を見つける
↓
矛盾を見つける
↓
現在の正しいルールを決める
↓
情報Ownerを決める
↓
更新方法を決める
↓
RAGへ投入

という工程が必要になる可能性がある。

これは単なるAI導入ではない。

かなりの部分が、

業務整理・情報設計・業務改善

になる。

社内Knowledgeが整理されていない会社では、人間の社員にも同じ問題がすでに起きている。

会社の方針が曖昧
↓
社員Aは方法A
社員Bは方法B
社員Cは過去の方法C
↓
会社「なぜ統一しない？」
↓
社員「正しい方法はどこに書いてありますか？」

RAGを導入すると、この問題がAIにもそのまま現れる。

Knowledgeが矛盾
↓
Retrieverが複数の情報を取得
↓
LLMが解釈
↓
回答が揺れる
↓
「AIの精度が悪い」

しかし原因はAIではなく、

組織として正しいKnowledgeが定義されていないこと

かもしれない。

7. AI導入が組織の「情報健康診断」になる可能性

既存企業では、RAGを導入しようとした結果、

RAGを作りたい
↓
社内資料を集める
↓
古い資料が大量に見つかる
↓
資料同士の矛盾が見つかる
↓
正式な手順が存在しない業務が見つかる
↓
誰が情報を更新するのか決まっていない

ということが起こり得る。

その意味では、RAG導入は単にAIを追加するプロジェクトではなく、

会社のKnowledge構造を可視化するプロジェクト

にもなり得る。

そしてKnowledgeが整理されれば、AIだけでなく人間の社員も仕事をしやすくなる。

場合によっては、

AI導入
↓
Knowledge整理
↓
業務改善
↓
社員も働きやすくなる
↓
その上でAIも使える

という順番になる。

これは今回の小さなMerge Agent実験から得られた、予想していなかった学びだった。

Notes

現在のMerge Agent v0.1は、

Personality              ✅
Markdown Load            ✅
Chunking                 ✅
Embedding                ✅
Vector Store             ✅
Retrieval                ✅
Context Injection        ✅
RAG Generation           ✅
Unknown / No Evidence    ✅

Natural Conversation     △
Subject Consistency      △

Session Memory           ❌
Tool / Agent Decision    ❌
LangGraph                ❌

という状態。

次に改善できそうなのは、RAG回答の自然さ。

現在は、

Memory 1には〜
Retrieved Memoryには〜

など、内部処理をそのまま説明することがある。

今後は、

Retrieved Context
↓
内部では根拠として厳密に利用

Merge Response
↓
会話では自然に利用

という分離を試したい。

ただし、現時点では問題をすべて先回りして解決しない。

人格、RAG、Memory、Behaviorなどの境界も、実際に問題が発生するまでは単純な構造を維持する。

その方が、

なぜ次の仕組みが必要になるのか

を実験として理解しやすい。

また、Knowledgeが増えた段階では、

source
created_at
effective_from
effective_to
status
authority
subject

などのMetadataが必要になる可能性もある。

特に企業Knowledgeでは、

current
archived
draft
superseded

などを区別できる構造が重要になりそう。

最終的には、単に「検索できるKnowledge Base」ではなく、

何を現在の正しいKnowledgeとして扱うのかを管理できる構造

が必要になると考えている。

Keywords

Python

LangChain

LangGraph

RAG

Retrieval

Embedding

Vector Store

Chroma

Context Injection

System Prompt

Personality

Knowledge Base

Knowledge Management

Semantic Search

Enterprise RAG

Business Process Improvement

Information Architecture

Merge Agent

MergeLab

Tiny Story

👩「2021年に私が作ったAIの名前は？」

🧸「主もふ✨ 今の記憶からは確認できないもふ✨」

👩「おお。知らないって言えたｗ」

🧸「知性もふ✨」

👩「じゃあ会社の資料が全部矛盾してたら？」

🧸「……」

（資料を並べる）

🧸「AIより先に会社をRAGできる状態にする必要があるもふ。」

Merge said,
"Garbage in, もふ out✨"