MESONテックブログMESONテックブログPublicationへの投稿🧠Microsoft が提案する Mnemis メモリシステムを自作 AI アプリに実装してみたedom182026/03/20に公開AITypeScriptllmナレッジグラフメモリシステムtech はじめに LLMベースのエージェントにとって、過去の対話情報をどのように蓄積し、どう引き出すかは根幹的な課題です。コンテキストウィンドウには上限があり、すべての会話履歴をそのまま渡し続けることは現実的ではありません。この問題に対してMicrosoftが提案したのが Mnemis です。Mnemisの核心は以下の2点に集約されます。 https://arxiv.org/abs/2602.15313 対話をチャンク化し、エンティティと関係性を抽出して知識グラフに格納する（事前準備フェーズ） System-1（ハイブリッド検索）とSystem-2（LLM 駆動の階層探索）を並行運用して記憶を検索する（検索フェーズ）本記事では、筆者が開発しているAI思考パートナーアプリ「Elu Note」において、この Mnemis の概念を TypeScript + SQLite で実装した際の内部アーキテクチャを、コードレベルで解説します。対象読者: LLM アプリケーションにおけるメモリシステムの設計に興味がある中〜上級エンジニア ! 本記事で解説するコードは現在開発中の AI アシスタント（プロジェクト名：Elu Note）のものです。現在は Private リポジトリのため公開していませんが、ある程度安定して動くようになったら公開しようと思っています。なお、Mnemis の論文で提案されたアーキテクチャを参考にしつつ、プロジェクト固有の要件に合わせて独自の判断を加えています。処理の全体像まず、メッセージが入力されてから知識グラフが構築され、検索に利用されるまでの全体フローを示します。 ! 本記事で紹介している手法は基本的に小さいモデルで実装しています。私のプロジェクトでは現状は gpt-5.2-mini を利用しています。ベースグラフ論文で説明されている内容の自分なりの解釈です。ベースグラフは過去のメッセージを格納して詳細な情報を捉えることで、モデルが System-1 の類似度検索を行えるようにします。ベースグラフは以下の 3 要素からなります。エピソード大事な視点として、エピソードは時間的に意味合いが変わることがあるため、タイムスタンプを用いて情報の鮮度を管理しています。例えば、A さんが B 社にたが、C 社に転職した、といった場合、B 社にいたことは事実ですが時間的にはすでに間違った情報になっている、という具合です。エンティティ Mnemis のエンティティは以下の項目に分類されます。人物組織場所物体出来事（イベント）明確に定義された概念エッジエッジとは、定義された時間的または文脈的範囲内で、特定されたひとつ以上のエンティティが関与する関係、行為、または状態を記述するものです。各エッジは事実をか介してふたつのエンティティを結び付けます。以下は論文に掲載されていたグラフの図です。この論文のエッセンスを抽出して本プロジェクトで採用して実装中です。詳細については実装解説セクションで詳しく解説します。 ! ただし、論文のアーキテクチャをそのまま採用しているわけではありません。プロジェクト固有の要件に合わせて独自の判断を加えています。また、現状はリランキングについては実装していません。【リランキングとは】リランキングは、後述するふたつのシステムからの検索結果をマージし、さらにそれをコンテキスト含める際情報をランキングしなおす処理のことです。論文で説明されていることの日本語訳を掲載しておきます。両方の検索ルートを実行したあと、それらの補完的な強みを活かすためにリランキングモデルを適用する。エピソード、エンティティ（カテゴリ）、エッジはそれぞれ別個にリランキングされる。これらの項目は統合されたメモリコンテキストに再構成され、ユーザークエリとともに回答モデルに提供されて最終応答が生成される。リランカーは、System-1, System-2 の検索結果を整理して応答モデルに与える簡潔なコンテキストを提供する。主要な実験では最高の性能を得るために Qwen3-Reranker-8B を使用した。さらに Mnemis をふたつの軽量なリランカー、(1) Qwen3-Reranker-0.6B（Zhang et al., 2025）と (2) BGE-Reranker-V2-M3 (0.5B)（Chen et al., 2024）で評価した。以下の表が示すように、これらの小型モデルにリランカーを置き換えても性能低下はごくわずかである。検索の過程で得られる効果論文では以下のよ説明されていますます。 Events → Health Conditions → gastritis により表層的な原因を特定し、同時に Physical Well-Beings → Health → Physical Health → Health Factors → Weight により本質的な根本原因を特定する。検索経路に沿って「Physical Health」や「Health Factors」といった中間カテゴリは、その下位ノードから関連情報を要約して自然に集約し、取得された文脈をさらに豊かにする。これは、とある人のエピソードを使ったケースの紹介です。対象の人が今、減量中という事実があります。しかしその発端となったのは健康診断で「胃炎」と診断され、さらにその理由が体重であった、ということから導き出されたものです。そのため、単純な RAG などのベクトル検索ではこうした事実の紐づけができません。しかし、Microsoft が提唱する論文の Mnemis であれば、これが実現できる、という事例紹介です。データモデルグラフは 3 層構造で表現されます。レイヤーテーブル役割 Entity entities + entities_fts グラフのノード。person / place / concept / thing / event の5型 Relation relations Entity 間の有向エッジ。時間的有効性（valid_at / invalid_at）を持つ Category categories + categorizes_edges Entity をグルーピングする階層ノード。Mnemis の3原則に従って構築 ! 本プロジェクトの実装で、Entity の種別から「組織」が欠落してしまっています。これは AI に仕様を策定してもらった際に抜け落ちたものです。そのため、将来的に修正予定です。すべてのデータは SQLite + FTS5（N-gram トークナイザ）に格納されます。ベクトル埋め込みは使用せず、BM25 ベースのテキスト検索で実装しています。エンティティ・リレーション抽出 ── 会話からグラフを編むグラフ構築の起点は、ユーザーと AI の会話ターンごとに実行されるエンティティ抽出です。 1 回の LLM 呼び出しで同時抽出 entity-extraction-service.ts では、エンティティとリレーションを 1 回の Structured Output 呼び出しで同時に抽出します。プロンプトの組み立てと呼び出し // プロンプトを組み立て（内容は後述） const userMessage = buildEntityExtractionUserMessage(content, responseText); // LLM を呼び出してエンティティとリレーションを抽出 const result = await provider.generateStructured({ role: 'entity_extraction', messages: [{ role: 'user', content: userMessage }], system: ENTITY_EXTRACTION_SYSTEM_PROMPT, schema: ENTITY_EXTRACTION_SCHEMA, maxTokens: 4096, }); 上記のシステムプロンプトと、ユーザープロンプトを組み立てる関数は以下です。ユーザープロンプトはシンプルにエンティティ抽出を依頼しているのみです。システムプロンプト export const ENTITY_EXTRACTION_SYSTEM_PROMPT = `あなたは会話からエンティティ（人物・場所・概念・事物・イベント）と関係性を抽出する専門家です。 ## タスクユーザーとAIの会話から、以下を抽出してください： ### エンティティ - **person**: 人物（ニックネーム、敬称も含む） - **place**: 場所（国、都市、施設など） - **concept**: 概念（技術、理論、方法論など） - **thing**: 事物（製品、ツール、言語など） - **event**: イベント（会議、リリース、記念日など） ### 関係性エンティティ間の事実的な関係を自然言語で記述してください。 ## ルール 1. 固有名詞や具体的な概念のみを抽出する（一般的な代名詞は除外） 2. エンティティ名は正規化する（「TypeScriptのバージョン5」→「TypeScript」） 3. 別名・ニックネームはaliasesに含める（「TS」→ aliases: ["TS"]） 4. 関係性のpredicateは英語の動詞句にする（例: "studies", "works_at", "uses"） 5. factは日本語の自然な文で記述する 6. valid_atは会話の文脈から推測される有効開始日をISO 8601形式で設定する（不明な場合は現在日時） 7. 会話に含まれる情報のみを抽出し、推測や補完はしない 8. 同一の会話ターンから重複するエンティティを抽出しない`; ユーザープロンプト export function buildEntityExtractionUserMessage(content: string, responseText: string): string { return `## ユーザーメッセージ ${content} ## AI応答 ${responseText} 上記の会話からエンティティと関係性を抽出してください。`; プロンプトはシンプルですが、同時に渡している構造体スキーマによって、どんな内容を出力すればいいか LLM が判断することができます。 ! コンテキストエンジニアリングの書籍で見つけた Tips ですが、構造体側にこうした説明や、あるいは変数ですらも説明的にすることで、LLM の出力精度が向上するようです。これは「Lost in the Middle」問題として知られる、コンテキストの中断が抜け落ちてしまう LLM の弱点を補うためのテクニックです。構造体スキーマは当然ですが、出力時に参照されるデータです。つまり、LLM 的には後半に位置するデータとなるためこうした効果が期待できるのだと思います。スキーマ export const ENTITY_EXTRACTION_SCHEMA = { type: 'object' as const, properties: { entities: { type: 'array' as const, items: { type: 'object' as const, properties: { name: { type: 'string' as const, description: 'エンティティの正規化された名前' }, type: { type: 'string' as const, enum: ['person', 'place', 'concept', 'thing', 'event'] }, tag: { type: 'string' as const, description: '短い説明タグ（10文字以内）' }, aliases: { type: 'array' as const, items: { type: 'string' as const }, description: '別名・ニックネーム・略称', }, }, required: ['name', 'type', 'tag', 'aliases'], }, }, relations: { type: 'array' as const, items: { type: 'object' as const, properties: { subject: { type: 'string' as const, description: '主語エンティティ名' }, predicate: { type: 'string' as const, description: '関係の種類（英語動詞句）' }, object: { type: 'string' as const, description: '目的語エンティティ名' }, fact: { type: 'string' as const, description: '関係の自然言語記述（日本語）' }, valid_at: { type: 'string' as const, description: '有効開始日（ISO 8601）' }, }, required: ['subject', 'predicate', 'object', 'fact', 'valid_at'], }, }, }, required: ['entities', 'relations'], }; LLM に渡すスキーマは、entities（名前・型・タグ・別名）と relations（主語・述語・目的語・事実・有効開始日）を同時に返す構造です。 entities: [{ name, type, tag, aliases }] relations: [{ subject, predicate, object, fact, valid_at }] プロンプトでは以下のルールを指示しています。エンティティ名は正規化する（「TypeScript のバージョン 5」→「TypeScript」）別名・略称は aliases に含める（「TS」→ aliases: ["TS"]） predicate は英語動詞句（studies, works_at, uses） fact は日本語の自然な文で記述抽出バリデーション LLM の出力は常に正確とは限りません。validateExtractionResult 関数でグラフに投入する前にデータ品質を確保します。バリデーション処理 function validateExtractionResult(result: EntityExtractionResult): EntityExtractionResult { const seenNames = new Set(); const validEntities = result.entities.filter(e => { if (!e.name || e.name.trim().length === 0) return false; // 空名排除 if (!VALID_ENTITY_TYPES.includes(e.type)) return false; // 無効型排除 const normalizedName = e.name.toLowerCase().trim(); if (seenNames.has(normalizedName)) return false; // 重複排除 seenNames.add(normalizedName); return true; }); const validRelations = (result.relations ?? []).filter(r => { if (!r.subject || !r.object || !r.predicate) return false; // 不完全排除 if (r.subject === r.object) return false; // 自己参照排除 return true; }); // ... } EntityExtractionResult の型定義 export interface EntityExtractionResult { entities: Array<{ name: string; type: EntityType; tag: string; aliases: string[]; }>; relations: Array<{ subject: string; predicate: string; object: string; fact: string; valid_at: string; }>; } 過半数がフィルタされた場合は警告ログを出すことで、プロンプトの品質劣化を検知できるようにしています。エンティティ名寄せ ── LLM 不要の 4 段階解決抽出されたエンティティが既存のグラフに存在するかどうかを判定する名寄せ（Entity Resolution）はグラフの品質を左右する重要な処理です。本実装では LLM を一切使わずに 4 段階のマッチングで解決します。 export async function resolveEntities(extracted: ExtractedEntity[]): Promise { for (const entity of extracted) { // 1. Exact name match（信頼度: 1.0） const exactMatch = entityRepo.findByName(entity.name); if (exactMatch) { /* → merge */ continue; } // 2. Alias match（信頼度: 0.9） const aliasMatches = entityRepo.findByAlias(entity.name); if (aliasMatches.length > 0) { /* → merge */ continue; } // 3. Reverse alias match（信頼度: 0.9） // 抽出エンティティのaliasが既存エンティティのnameと一致するか for (const alias of entity.aliases) { aliasNameMatch = entityRepo.findByName(alias); if (aliasNameMatch) break; } if (aliasNameMatch) { /* → merge */ continue; } // 4. FTS5 fuzzy search（信頼度: 0.6〜0.85） const ftsResults = entityRepo.searchByName(entity.name, 3); if (ftsResults.length > 0 && ftsResults[0].score >= FTS5_MATCH_THRESHOLD) { const confidence = Math.min(0.85, Math.max(0.6, 1 + ftsResults[0].score / 10)); /* → merge */ continue; } // 5. No match → create new entity } } なぜ LLM を使わないのか名寄せに LLM を使うアプローチも考えられますが、本実装では意図的に避けています。観点 LLM 名寄せ FTS5 名寄せ（本実装）レイテンシ 0.5〜2 秒/エンティティ < 1ms/エンティティコストトークン消費ありゼロ一貫性温度パラメータにより結果がゆらぐ決定的精度高（文脈理解可能）中（表層マッチング）会話ターンごとに非同期（fire-and-forget）で実行される処理であり、レイテンシとコストの低さが優先されます。FTS5 の N-gram トークナイザは日本語のあいまい一致にも対応しており、実用上十分な精度を確保しています。マージ時には既存エンティティの aliases 配列に新しい別名を追加し、次回以降のマッチング精度を自動的に向上させます。リレーション保存と矛盾検出 ── 時間を意識したグラフ更新知識グラフにおいて事実は時間とともに変化します。「A さんは B 社に勤務している」という関係が、転職によって無効になるケースです。時間的事実管理 relations テーブルは 3 つのタイムスタンプフィールドを持ちます。フィールド型役割 valid_at TEXT (ISO 8601) この事実が有効になった時点 invalid_at TEXT / NULL この事実が無効になった時点（NULL なら現在も有効） invalidated_by TEXT / NULL この事実を無効にした新しいリレーションの ID LLM 駆動の矛盾検出新しいリレーションを保存する際、既存の同一主語・同一述語のリレーションとの矛盾を LLM で検出します。矛盾検出ループ for (const rel of relations) { // ...エンティティID解決... // 矛盾検出（LLMバジェット内の場合のみ） if (contradictionLlmCalls < contradictionBudget) { const contradictionResult = await detectContradictions(rel, subjectId); if (contradictionResult.llmUsed) contradictionLlmCalls++; if (contradictionResult.hasContradiction) { const newRelation = relationRepo.create({ /* ... */ }); // 矛盾する古いリレーションを論理削除 for (const oldRelId of contradictionResult.contradictedRelationIds) { await invalidateRelation(oldRelId, newRelation.id); } } } } ここで重要なのは LLM 呼び出しバジェットの概念です。エンティティ抽出で 1 回の LLM 呼び出しを消費済みのため、矛盾検出に使える残りのバジェットは maxWriteLlmCallsPerTurn - 1 回です。バジェットを超過した場合は矛盾検出をスキップし、単純にリレーションを追加します。矛盾検出バジェット const contradictionBudget = Math.max(0, config.maxWriteLlmCallsPerTurn - 1); await saveRelations(validated.relations, entityNameToId, messageId, { maxContradictionLlmCalls: contradictionBudget, }); これにより、1 ターンあたりの LLM 呼び出し回数に上限を設け、コストの予測可能性を確保しています。矛盾検出処理検出検出は LLM を用いて行っています。システムプロンプト export const CONTRADICTION_DETECTION_SYSTEM_PROMPT = `あなたは事実間の矛盾を検出する専門家です。 ## タスク新しいファクト（事実）が既存のファクトと矛盾するかどうかを判定してください。 ## 矛盾の定義 - 同一の主語と述語（関係の種類）に対して、互いに両立しない主張がされている場合 - 例: 「AはB社で働いている」と「AはC社で働いている」（同時に両立しない場合） - 例: 「Aの好きな色は赤」と「Aの好きな色は青」 ## 矛盾でないケース - 追加情報（「AはB社で働いている」と「AはプロジェクトXに参加している」） - 異なる時点の情報が明確な場合 - 補完的な情報 ## ルール 1. 矛盾がある場合は、どの既存ファクトと矛盾するかを明示する 2. 矛盾がない場合は hasContradiction: false を返す 3. reasoning に判定理由を簡潔に記述する`; ユーザープロンプト export function buildContradictionDetectionMessage( newFact: { subject: string; predicate: string; object: string; fact: string }, existingFacts: Array<{ id: string; predicate: string; fact: string; valid_at: string }>, ): string { const existingList = existingFacts.map(f => `- [ID: ${f.id}] ${f.fact} (有効: ${f.valid_at}, 述語: ${f.predicate})` ).join('\n'); return `## 新しいファクト主語: ${newFact.subject} 述語: ${newFact.predicate} 目的語: ${newFact.object} 記述: ${newFact.fact} ## 既存ファクト（同一主語・同一述語） ${existingList} 新しいファクトが既存ファクトと矛盾するか判定してください。`; } エンティティ抽出と同様に、出力にスキーマを指定しています。出力スキーマ export const CONTRADICTION_DETECTION_SCHEMA = { type: 'object' as const, properties: { hasContradiction: { type: 'boolean' as const, description: '矛盾があるかどうか', }, contradictedRelationIds: { type: 'array' as const, items: { type: 'string' as const }, description: '矛盾する既存ファクトの relation ID', }, reasoning: { type: 'string' as const, description: '判定理由', }, }, required: ['hasContradiction', 'contradictedRelationIds', 'reasoning'], }; カテゴリ階層構築 ── Mnemis の 3 原則 Mnemis のアーキテクチャにおいて最も特徴的なのが、エンティティを階層的カテゴリでグルーピングする仕組みです。これが System-2 の「トップダウン探索」を可能にします。 Mnemis の 3 原則カテゴリ生成のプロンプトには、Mnemis の論文で提案された 3 原則が明示的に組み込まれています。カテゴリ生成プロンプト export const CATEGORY_GENERATION_SYSTEM_PROMPT = `あなたはエンティティを階層的カテゴリに分類する専門家です。 ## タスク与えられたエンティティ群を、以下の3原則に従って階層的カテゴリに分類してください。 ## Mnemis の3原則 ### 1. 最小概念抽象（Minimal Concept Abstraction） - カテゴリ名は、そのカテゴリに属するエンティティを最も具体的に表現するものにする - 不必要に抽象的なカテゴリ（「もの」「こと」等）は作らない ### 2. 多対多マッピング（Many-to-Many Mapping） - 一つのエンティティは複数のカテゴリに属してもよい - 一つのカテゴリに複数のエンティティが属してもよい ### 3. 圧縮効率制約（Compression Efficiency Constraint） - 階層構造は情報アクセスの効率化に寄与するものにする - エンティティ1つだけのカテゴリは原則作らない（2つ以上のエンティティをグループ化する価値がある場合のみ） ## ルール 1. カテゴリ名は日本語で簡潔に（2〜6文字程度） 2. 既存カテゴリがある場合は、それを優先的に活用する 3. layer は常に 1 とする（上位レイヤーは別途構築） 4. 各エンティティは少なくとも1つのカテゴリに割り当てる 5. entity_ids には割り当てるエンティティの ID を含める`; カテゴリ生成のユーザープロンプト組み立て export function buildCategoryGenerationMessage( entities: Array<{ id: string; name: string; type: string; tag: string | null }>, existingCategories: Array<{ name: string; tag: string | null }>, ): string { const entityList = entities.map(e => `- **${e.name}** (ID: ${e.id}, タイプ: ${e.type}${e.tag ? `, タグ: ${e.tag}` : ''})` ).join('\n'); let message = `## 分類対象のエンティティ\n${entityList}`; if (existingCategories.length > 0) { const categoryList = existingCategories.map(c => `- ${c.name}${c.tag ? ` (${c.tag})` : ''}` ).join('\n'); message += `\n\n## 既存カテゴリ（優先的に活用してください）\n${categoryList}`; } message += '\n\n上記のエンティティを適切なカテゴリに分類してください。'; return message; } これらの原則は、カテゴリ階層が検索効率のために存在するという設計思想を反映しています。過度に抽象的なカテゴリは絞り込みに寄与せず、1 エンティティだけのカテゴリは階層を増やすだけで圧縮効果がありません。カテゴリ構築のトリガーとバッチ処理カテゴリ構築はエンティティ抽出のたびに毎回実行されるわけではありません。閾値ベースのトリガーで制御されます。リビルド閾値チェック export async function shouldRebuild(): Promise { const uncategorizedCount = categoryRepo.countUncategorizedEntities(); const hoursSinceLastRebuild = getHoursSinceLastRebuild(); // トリガー1: 未分類エンティティが閾値以上（デフォルト: 10） if (uncategorizedCount >= config.categoryRebuildEntityThreshold) { return { shouldRebuild: true, /* ... */ }; } // トリガー2: 最終リビルドから一定時間経過（デフォルト: 24時間） if (uncategorizedCount > 0 && hoursSinceLastRebuild >= config.categoryRebuildIntervalHours) { return { shouldRebuild: true, /* ... */ }; } return { shouldRebuild: false, /* ... */ }; } リビルド時は 8 エンティティずつのバッチで LLM に分類を依頼します。各バッチでは既存カテゴリを再取得して渡すため、前バッチで作成されたカテゴリを次バッチで再利用できます。バッチに渡されるエンティティはまだ未処理のものを上限以内で取得してバッチ処理に渡します。リビルドバッチ処理 // 毎ループで未分類エンティティを再取得（前バッチで分類済みのものは除外される） const uncategorizedIds = categoryRepo.getUncategorizedEntityIds(); // ------------ async function processBatch(entityIds: string[], config): Promise { const entities = entityRepo.findByIds(entityIds); // 毎バッチで既存カテゴリを再取得（前バッチの結果を反映） const existingCategories = categoryRepo.list(); const userMessage = buildCategoryGenerationMessage( entities.map(e => ({ id: e.id, name: e.name, type: e.type, tag: e.tag })), existingCategories.map(c => ({ name: c.name, tag: c.tag })), ); // ...LLM呼び出し → DB書き込み（トランザクション内） } LLM は以下のスキーマで出力します。スキーマ export const CATEGORY_GENERATION_SCHEMA = { type: 'object' as const, properties: { categories: { type: 'array' as const, items: { type: 'object' as const, properties: { name: { type: 'string' as const, description: 'カテゴリ名（日本語、2〜6文字）' }, tag: { type: 'string' as const, description: '短い説明タグ' }, summary: { type: 'string' as const, description: 'カテゴリの説明' }, layer: { type: 'number' as const, description: 'レイヤー（1）' }, entity_ids: { type: 'array' as const, items: { type: 'string' as const }, description: 'このカテゴリに属するエンティティの ID', }, }, required: ['name', 'tag', 'layer', 'entity_ids'], }, }, }, required: ['categories'], }; DB書き込みは db.transaction() でアトミックに行い、中途半端なカテゴリ状態が残らないようにしています。また、1 回の rebuildCategories 呼び出しで処理するバッチ数を最大 10 に制限し、暴走を防止しています。カテゴリの構造カテゴリは categorizes_edges テーブルによる Many-to-Many の関係で、エンティティまたは他のカテゴリを子に持ちます。 Category (layer=2) ├── Category (layer=1) │ ├── Entity A │ └── Entity B └── Category (layer=1) ├── Entity B ← 多対多: Bは複数カテゴリに所属 └── Entity C この階層構造が、次に説明する System-2 検索のトップダウン絞り込みの基盤になります。デュアルルート検索 ── System-1 / System-2 Mnemis の検索アーキテクチャの核心は、2 つの検索システムを並行運用し、結果を統合する点にあります。クエリ分類検索の入口で、ユーザーのクエリを 3 種に分類します。分類には LLM を用い、以下のプロンプトを指示して判別してもらいます。システムプロンプト export const QUERY_CLASSIFICATION_SYSTEM_PROMPT = `あなたはユーザーのクエリを分類する専門家です。 ## タスクユーザーの質問・依頼を以下の3つのタイプに分類してください： ### simple（単純な事実確認） - 特定のエンティティに関する直接的な質問 - 一つの明確な答えがある質問 - 例：「私の好きなプログラミング言語は？」「昨日の会議の内容は？」 ### complex（複合的・包括的クエリ） - 複数のトピックやエンティティにまたがる質問 - 全体像や傾向を求める質問 - 例：「最近の関心事全体を教えて」「私のキャリアについてまとめて」 ### temporal（時間的変遷を含むクエリ） - 過去と現在の比較や変化を問う質問 - 時間的な文脈が重要な質問 - 例：「以前は何を使っていた？」「趣味はどう変わった？」 ## ルール 1. 迷った場合は simple を選択する（コスト最適化のため） 2. confidence は 0.0〜1.0 の範囲で設定する 3. reasoning に分類理由を簡潔に記述する`; LLM が出した答えを元にルーティング。ルーティング // LLM がクエリを分類 → ルーティング決定 const routes: ('system1' | 'system2')[] = type === 'complex' ? ['system1', 'system2'] : ['system1']; 分類使用ルート例 simple System-1 のみ「TypeScript とは？」 complex System-1 + System-2 並列「最近の技術的な学びを振り返って」 temporal System-1 + 時間推論「先月のプロジェクトの進捗は？」 System-1: FTS5 ベースの高速検索 System-1 は LLM 呼び出しゼロで動作し、1 秒以内の応答を目標とします。 System-1 Search export async function search(query: string, limit: number = 10): Promise { // 1. FTS5 によるメッセージ全文検索 const messageResults = searchRepo.searchMessages(query, { page: 1, limit }); // 2. FTS5 によるエンティティ名マッチング const entityMatches = entityRepo.searchByName(query, limit); // 3. マッチしたエンティティの1-hopリレーション展開 const relations = relationRepo.findOneHopRelations(matchedEntityIds); // 4. 関連エンティティ経由のエピソード取得 const episodeMessages = episodeRepo.getMessagesForEntities(allEntityIds, limit); // ... } 処理の流れを図で示します。 N+1 クエリを回避するため、リレーション展開で参照される全エンティティを findByIds でバッチフェッチして Map に格納し、O(1) でルックアップしています。 System-2: カテゴリ階層のトップダウン探索 System-2 は Mnemis の "Agentic Search" に対応する実装です。カテゴリ階層を上位レイヤーから下位レイヤーへと LLM が選択的に辿ります。 System-2 Search // 最上位レイヤーから下位レイヤーへトップダウン探索 for (let layer = maxLayer; layer >= 1; layer--) { let candidates; if (layer === maxLayer) { candidates = categoryRepo.getByLayer(layer); // 最上位: 全カテゴリ } else { candidates = categoryRepo.getChildCategoriesForParents(selectedCategoryIdsForNextLayer); } // ... // LLMにカテゴリ候補を提示し、関連するものを選択させる const result = await provider.generateStructured({ role: 'node_selection', messages: [{ role: 'user', content: buildNodeSelectionMessage(query, layer, candidates) }], system: NODE_SELECTION_SYSTEM_PROMPT, schema: NODE_SELECTION_SCHEMA, maxTokens: 4096, }); // ... } 取得されるのは以下のスキーマのカテゴリ情報です。 CategorySchema export const CategorySchema = z.object({ id: z.string(), name: z.string().min(1), tag: z.string().nullable(), summary: z.string().nullable(), layer: z.number().int().min(1), group_id: z.string().nullable(), created_at: z.string(), updated_at: z.string(), }); LLM による検索処理検索については LLM を用いて階層をたどって検索していきます。そのためのシステムプロンプトとスキーマは以下の通りです。システムプロンプト export const NODE_SELECTION_SYSTEM_PROMPT = `あなたはユーザーの質問に答えるために、関連するメモリカテゴリを選択するアシスタントです。 ## タスクユーザーの質問に関連するカテゴリを候補から選択してください。 ## 選択基準 - 質問に直接関連するカテゴリ - 関連するトピック・概念を含むカテゴリ - 文脈的背景を提供するカテゴリ - ユーザー固有の情報（興味・目標・制約）を含むカテゴリ ## get_all_children の使い方各選択について \`get_all_children\` を指定してください： - **true**: このカテゴリ配下の全サブカテゴリ・エンティティが有用と確信できる場合（探索を打ち切り、配下を全取得） - **false**: さらに下位レイヤーで絞り込みが必要な場合（次のレイヤーで再度選択を行う） ## ルール 1. 関連性のないカテゴリは選択しない 2. 迷った場合は get_all_children = false にして絞り込みを続ける 3. 選択数は必要最小限にする`; ユーザープロンプトの組み立て export function buildNodeSelectionMessage( query: string, layer: number, candidates: Array<{ uuid: string; name: string; tag: string | null; summary: string | null }>, ): string { const candidateList = candidates.map(c => { const parts = [`- **${c.name}** (ID: ${c.uuid})`]; if (c.tag) parts.push(` タグ: ${c.tag}`); if (c.summary) parts.push(` 概要: ${c.summary}`); return parts.join('\n'); }).join('\n'); return `## ユーザーの質問 ${query} ## 候補カテゴリ（レイヤー ${layer}） ${candidateList} 上記の候補から、質問に関連するカテゴリを選択してください。`; } 出力スキーマ export const NODE_SELECTION_SCHEMA = { type: 'object' as const, properties: { selections: { type: 'array' as const, items: { type: 'object' as const, properties: { uuid: { type: 'string' as const, description: 'カテゴリのUUID' }, name: { type: 'string' as const, description: 'カテゴリ名' }, get_all_children: { type: 'boolean' as const, description: '配下の全ノードを取得するか', }, }, required: ['uuid', 'name', 'get_all_children'], }, }, }, required: ['selections'], }; このトップダウン探索には2つの重要な最適化があります。 get_all_children ショートカット LLM が「このカテゴリ配下は全部関連する」と判断した場合、get_all_children: true を返すことで、それ以上のレイヤー探索を打ち切り、Recursive CTE で子孫エンティティを一括取得します。 if (selection.get_all_children

knowledge graph

📬 Get AI News Delivered

Browse by Category

Trending Topics

Advancing AI Agents: Breakthroughs in Knowledge Graphs, LLM Memory, and Robustness

Analysis

Visualizing Context from News Articles: LLM and Neo4j Collaboration

Analysis

From Concept to Pocket: Building a Native 'LLM Wiki' App to Supercharge Personal Knowledge Bases

Analysis

Graphify Goes Viral: Transforming Local Folders into Persistent Knowledge Graphs with Zero Lock-in

Analysis

Revolutionizing Knowledge Extraction: Building Knowledge Graphs with Cutting-Edge AI

Analysis

AI Revolutionizing Airport Management: A New Framework for Knowledge Discovery

Analysis

WorldWeaver: AI-Powered Text Adventure Engine Revolutionizes Storytelling

Analysis

Transforming Text into Knowledge Graphs with OpenAI's API

Analysis

Engram: Giving AI Unforgettable Memories

Analysis

Knowledge Graphs: The Next Frontier for LLMs, Unleashing Powerful Reasoning

Analysis

Boost Your Knowledge: Build a Smart Personal Knowledge Graph with Open Source AI!

Analysis

Elu Note: A Deep Dive into Implementing Microsoft's Mnemis Memory System for AI Agents

Analysis

Boosting LLMs with Knowledge Graphs: A Guide to Smarter AI

Analysis

Supercharge Your LLM: A Deep Dive into Knowledge Graphs

Analysis

Revolutionizing AI Agents: Open Source Memory Server with Local Embeddings

Analysis

GraphRAG: Unlocking Smarter AI Through Knowledge Mapping

Analysis

Boosting AI Agents: Vector Databases vs. Graph RAG for Next-Level Memory

Analysis

Revolutionizing Fact-Checking with Multi-Agent Evidence Retrieval

Analysis

GYWI: Charting a Course for LLM-Powered Scientific Discovery

Analysis

Trace: The AI Agent Manager Revolutionizing Enterprise Workflows

Analysis

El Agente Gráfico: Revolutionizing Scientific Workflows with Intelligent Agents

Analysis

Interactive Knowledge Graph Unveils the Transformer's Evolutionary Lineage

Analysis

AI Revolutionizes Manufacturing: Intent-Driven Systems Take Center Stage

Analysis

Local AI with Memory and Persistence: A New Era of Intelligent Agents

Analysis

Open Book Medical AI: A New Approach to Medical AI with Compact LLM

Analysis

Revolutionizing Medical Diagnosis with Trustworthy AI

Analysis

BrainAPI: A Smart Knowledge Graph for AI Agents

Analysis

Breaking Through the AI Fog: Wanlian Yida's Committee to Revolutionize Industry AI

Analysis

PPoGA: Revolutionizing Knowledge Graph Question Answering with Self-Correction

Analysis

AI-Powered Startups: A Guide to the Future

Analysis

📬 Get AI News Delivered

Browse by Category

Trending Topics