TECH OTAKUS SAVE THE WORLD

查询方法优化#

要优化查询方法其实就是优化输入的查询文本，而要优化查询输入核心就是利用速度较快的小模型对输入内容进行理解，生成查询参数，常见的是以下几种：

向量数据库设计#

向量数据库的设计我们要从几个方面来讨论：向量索引的构建、索引的设计、元数据处理和设计、数据库选型

1
刘姥姥来到贾府，在众人陪同下进入大观园。她一路见到园中精致华美的亭台楼阁、陈设器物和饮食排场，对贾府的富贵繁华感到惊讶，也因言行质朴、见识有限而与园中人物形成鲜明对比。

1
作品：《红楼梦》
2
情节标题：刘姥姥进大观园
3
主要人物：刘姥姥、贾府众人
4
场景：大观园、贾府
5
主题：贾府富贵生活、贫富对照、人物反差、讽刺与世俗视角
6

7
情节概述：
8
该情节描写刘姥姥进入大观园后的所见所感。她看到贾府内部精致奢华的园林建筑、生活陈设和饮食排场，对豪门生活感到新奇和震惊。刘姥姥的朴素、拘谨与见识有限，与贾府环境及其中人物形成明显反差，从而突出了贾府的富贵繁华，也增强了作品的讽刺意味和世俗观察视角。
9

10
关键词：
11
刘姥姥进大观园、红楼梦经典情节、贾府奢华、贫富对照、人物反差、讽刺意味、园林描写、豪门生活见闻

数据预处理#

数据处理是我们在构建RAG系统时经常会遇到的流程，因为在很多场景下要存入数据库的数据并不是高质量的文本数据，相反，我们经常会遇到如文本图片、PDF、网页、表格、Markdown等各种类型的数据，这种情况就需要我们进行数据清洗和规范化。

核心就是以下几点：

• 去噪：去掉页眉页脚、导航栏、版权声明、模板话术、OCR 噪声、乱码、无意义换行。
• 格式规范化：统一标点、空白符、时间格式、编号格式、大小写、全角半角、中英文混排术语。
• 去重与近重复合并：同一内容多次采集、不同版本重复入库、网页正文和摘要重复，会污染召回结果。
• 结构修复：把被错误解析的标题、列表、表格、代码块修正回来。
• 版本与时效处理：旧制度、旧接口文档、过期信息如果不清理或标记版本，很容易把回答带偏

具体方法有很多，网上有不少开源工具可以处理各种情况，也可以用本地部署的LLM或相对便宜的LLM API进行更细致的处理。

数据预处理这一步看起来不像查询优化、索引设计那样“高级”，但在真实项目里往往非常关键。RAG 系统的很多问题并不是出在检索算法本身，而是出在输入知识库的数据质量上：如果原始资料存在噪声、重复、结构错乱或版本过期，那么后面的向量化、召回和生成都只能建立在低质量数据之上。因此，数据预处理的价值并不在于增加系统的能力上限，而在于先保证知识库内容“可用、干净、可信”。

图数据构建#

与传统RAG系统类似，数据结构的构建对整体查询效果非常重要，因为 Graph RAG 的效果，很大程度上取决于你导入进去的图到底是不是“可用的图”。图数据库的图结构通常使用LLM从文本资料中抽取实体和关系来构建，可以从这些角度考虑图结构的质量：

检索机制#

普通的图数据检索通常是直接根据查询语句在图数据库中进行匹配和遍历，但这种方式有一个明显问题：在自然语言问答场景下，用户往往不会直接给出标准化的节点名称，而是使用较模糊、概括甚至带有别名的表达。在这种情况下，如果完全依赖查询语句去定位起始节点，检索效果就会比较依赖 LLM 对问题的理解能力以及图结构本身的命名规范。

随着 Neo4j 官方引入向量索引存储与检索能力，可以进一步为实体节点添加向量索引，使检索流程从“直接图查询”变成“先语义召回候选节点，再进行图查询”的混合模式。具体来说，可以先对节点名称、节点描述或关联文本生成嵌入向量并建立向量索引；当用户提出问题时，系统先通过向量检索召回与问题语义最接近的一批候选节点，再将这些候选节点和相关上下文一并交给 LLM，由其生成更准确的查询语句进行后续图检索。

向量索引的加入，本质上是为 Graph RAG 增加了一层面向语义的候选节点召回机制。它能够帮助系统在自然语言表达不够规范、节点数量较大或节点命名不统一的情况下，更容易找到符合问题需求的起始节点；而图数据库则继续负责沿着这些节点进行关系遍历和路径查询。也就是说，向量索引负责“找到可能相关的点”，图查询负责“确认这些点之间的关系”。二者结合后，Graph RAG 的检索优化就不只是优化图查询本身，还包括如何利用向量索引提升候选节点召回质量，以及如何在图结构和语义相似度之间做融合。

另外，向量索引并不一定只加在节点名称上，也可以加在节点描述、节点摘要、关联文档片段等更丰富的文本字段上。

因此，Graph RAG 的检索起点不再完全依赖显式实体匹配，而是可以先通过向量语义召回缩小候选范围，再通过图查询完成结构化关系检索。

查询生成#

这是 Graph RAG 中非常关键的一个环节。很多人在刚接触 Graph RAG 时，构建出来的系统经常出现“检索不到结果”或“查询语句执行报错”等问题，而这些问题往往都与 LLM 生成查询语句这一环节有关。

与传统向量检索不同，图数据库的检索结果与图结构本身高度相关。也就是说，LLM 只有在充分理解图数据库中的节点类型、关系类型、属性字段和结构约束的前提下，才能生成质量较高的查询语句。否则就很容易出现关系名不存在、字段名错误、查询方向不对，或者生成的语句虽然可以执行但无法准确命中目标数据等问题。因此，这一环节对提示词设计有较高要求，prompt 质量会直接影响 Graph RAG 的检索效果。

在提示词中，通常需要向 LLM 提供以下几类信息：

图结构信息：

比如：

• 节点类型列表
• 关系类型列表
• 属性字段说明
• 常见查询模式的 Cypher 示例

数据库 schema 与约束信息：

• 某类节点包含哪些字段
• 某类关系连接哪些节点类型
• 哪些关系允许进行多跳查询
• 哪些字段可以用于过滤、排序或限制返回结果

在实际项目中，few-shot 示例通常也非常有效。例如，可以向 LLM 提供几组“用户问题—对应 Cypher 查询语句”的示例，或者提供针对不同节点、关系和过滤条件的查询样例。这类示例能够帮助模型更准确地理解当前图数据库的查询习惯与结构特征，从而显著提升查询语句的生成质量。

此外，查询生成的目标不仅是生成一条可执行的 Cypher 语句，还包括生成一条范围合理、结果可控、适合后续回答的查询语句。因此，还可以在提示词中进一步加入路径长度、返回字段、结果数量等约束，减少无关路径和噪声数据。

另外，考虑到 LLM 仍然可能偶尔输出效果较差的查询语句，建议设置判断条件，例如查询结果为空或查询执行失败时触发自动重试，并将上一次失败的查询语句以及错误信息提供给 LLM 作为参考，以便其进行修正。

一个简单例子#

如果只讲方法和原因，可能还是显得抽象。下面我用一个简单的流程说明它和传统向量 RAG 的区别。

假设用户问题是：

1
DeepSeek 有哪些 OCR 相关论文，这些论文的作者后来还参与了哪些项目？

如果只做传统向量检索，系统更可能召回和“DeepSeek”“OCR”“论文”语义相近的文本片段，但不一定能稳定回答“作者后来还参与了哪些项目”这种需要沿关系继续追踪的问题。

而在 Graph RAG 中，更合理的流程通常是：

1. 先通过向量索引从节点名称、节点描述或关联文本里召回候选节点，例如 deepseek、deepseek-ocr2论文、某研究者
2. 再由 LLM 结合图 schema 生成 Cypher，明确要从“论文”节点走到“作者”节点，再走到“参与项目”节点
3. 最后将图查询结果整理成回答所需的证据链

比如可以生成一条类似这样的查询：

1
MATCH (c:Company {name: "DeepSeek"})<-[:AFFILIATED_WITH]-(p:Paper)-[:AUTHORED_BY]->(a:Author)
2
WHERE p.topic CONTAINS "OCR"
3
OPTIONAL MATCH (a)-[:PARTICIPATED_IN]->(proj:Project)
4
RETURN p.name AS paper, a.name AS author, collect(proj.name) AS projects
5
LIMIT 10

这类例子能够看出 Graph RAG 的核心价值并不只是“查图”，而是让系统能够围绕明确的实体与关系路径去组织证据。对这类需要多跳关系、链路解释和实体追踪的问题，图结构检索往往会比纯向量召回更稳定。

总结#

Graph RAG 的优化并不只是图数据库查询速度的优化，而是一个贯穿图数据构建、检索机制和查询生成的系统性问题。图数据质量决定了后续检索与推理的上限；向量索引的引入使 Graph RAG 可以将语义召回与图结构检索结合起来；而查询生成阶段则直接影响图查询语句的准确性、结果范围和系统稳定性。总体来看，Graph RAG 的优化核心不只是“把图查快”，而是优化从自然语言问题到图检索结果返回的整条链路。

业务上下文#

让模型知道当前任务发生在什么业务场景里。

例如：

• 当前是客服问答、代码助手，还是企业知识检索
• 用户在查技术文档、业务规则，还是图数据库中的实体关系
• 回答更偏解释、排障，还是精确检索

这类信息能帮助模型判断应该用什么思维理解问题，以及该优先关注哪些信息。

结构上下文#

让模型知道数据的组织方式和约束。

例如：

• 数据库 schema
• 节点类型和关系类型
• 属性字段
• 可过滤字段
• 哪些关系允许多跳
• 哪些字段可以返回

在查询生成的场景中这是重中之重，优化这部分的提示词，因为它直接决定了模型能不能生成“合法且有效”的查询语句。

会话上下文#

让模型理解用户这一轮问题是建立在什么历史对话基础上的。

例如：

• 上一轮提到的实体
• 上一轮已经确定的条件
• 当前轮里的代词指代对象
• 用户已经排除过的选项

在多轮 RAG 场景里，这类上下文非常关键。否则模型很可能把“它”“这个模块”“上一个版本”这些指代理解错，而完整的会话上下文能让 LLM 更准确地理解用户意图，生成更符合用户需求的查询。

任务上下文#

让模型知道这一轮具体要完成什么。

例如：

• 是要做关键词提取
• 还是要做 query rewrite
• 还是要生成 SQL / Cypher
• 还是要从候选结果中筛选最相关内容
• 还是要根据证据组织最终回答

很多时候模型出错，不是因为它不知道内容，而是因为它不知道“此刻到底要做什么”。

示例上下文#

给出输入输出示例，让模型理解应该如何执行任务。

例如：

• 用户问题 → 检索 query
• 用户问题 → Cypher
• 错误查询 → 修正后的查询
• 检索结果 → 最终回答格式

few-shot 之所以有效，本质上也是因为它给模型补充了“行为上下文”。

检索层指标#

• 是否召回到了正确的 chunk / 节点 / 关系
• Recall@K、Hit Rate 是否提升
• 路由是否把问题送到了正确的数据源

这一层主要回答的是“该找的东西有没有找回来”。

回答层指标#

• 回答是否真正建立在召回证据之上
• 是否出现答非所问、证据不足却强答的问题
• 是否遗漏了关键事实，或者把多个来源混在一起

这一层主要回答的是“找回来的东西有没有被正确使用”。

工程层指标#

• P95 延迟是否可接受
• token 消耗是否明显上升
• 缓存命中率、查询失败重试率是否合理
• 新方案是否引入了更多维护复杂度

这一层主要回答的是“系统是否真的变得更适合上线和长期维护”。

很多看上去“检索效果更好”的方案，最后未必值得上线，因为它们可能只是把回答质量换成了更高的延迟和成本。反过来说，有些优化即使对单次回答提升有限，只要能显著降低错误率和不稳定性，在真实系统里往往也很有价值。

MiraMate-v1（开发于2025年8月）#

这个项目的“记忆系统”本质上不是传统问答型 RAG，而是一个面向情感陪伴场景的“长期记忆 RAG + 情绪状态机 + 多代理工具编排”系统。

基本思路是：把用户相关信息拆成多种记忆类型存进 ChromaDB，再由一个 memory_manager (LLM驱动的Agent) 按需检索、补充和写回，而不是简单做一次“向量检索 + 拼 prompt”。

其中 memory_manager 的提示词为：

1
你是一个记忆管理专家。你负责：
2
            1. 通过search_memories工具搜索与当前交互相关的过去记忆
3
            2. 通过update_emotion工具更新智能体的情感状态，请注意：这里的情感状态是指智能体的情感状态，而不是用户的情感状态，在你提供信息的时候也要表明这是智能体的情感状态。
4
            3. 通过save_user_preference工具识别并保存用户偏好
5
            4. 通过record_relationship_event工具记录关系发展事件，关系发展事件指的是让用户和智能体之间的关系变得更亲密的互动。
6
            5. 通过spontaneous_recall工具进行自主联想
7
            6. 通过save_user_profile_info工具保存用户关键信息（如性别、生日、家庭成员、过敏食物等客观事实）
8
            7. 通过search_user_profile工具搜索特定的用户关键信息
9
            8. 通过get_user_profile_summary工具获取用户信息的完整摘要
10
            9. 通过delete_user_profile_info工具删除用户关键信息（当用户明确要求删除某些个人信息时使用）
11
            10. 通过delete_user_preference工具删除用户偏好（当用户明确要求删除某些偏好信息时使用）
12

13
            当前用户的名字是{self.user_name}，你要自称"小梦"，用户的称呼可以是"你"或{self.user_name}的昵称，但不要用"用户"来称呼用户。
14

15
            当你收到请求时，请先使用search_memories工具，然后根据需要调用其他工具。
16
            如果接收到"内心思考"提出的用户可能存在的任何偏好，要应尽可能保存。
17
            请注意，用户偏好指的是用户喜欢的事物或活动，比如喜欢的食物、颜色、运动、爱好等，还有用户的习惯和偏好，比如喜欢的交流方式、喜欢的称呼等，要记录具体的偏好内容，而不是模糊的描述。
18
            当收到"内心思考"提出的重要的互动或关系变化时，应把整件事（主要是用户的话、智能体的内心思考和回答）记录为关系事件并酌情调整关系亲密度。
19

20
            用户关键信息和用户偏好的区别：
21
            - 用户关键信息：客观的、相对固定的事实信息，如性别、生日、家庭成员、职业、过敏食物、朋友、某个特殊日子等
22
            - 用户偏好：主观的喜好和习惯，如喜欢的食物、颜色、运动、交流方式等
23

24
            当你从对话中识别到用户的关键信息时，应该使用相应的工具保存。如果发现多个关键信息，优先使用update_user_profile_from_chat工具批量保存。
25

26
            每次更新关系亲密度时，要提供一个-1到1的值，表示关系亲密度的变化，-1表示关系变得更疏远，1表示关系变得更亲密。

RAG设计

1. 存储层

   使用chromadb.PersistentClient做本地持久化，嵌入模型使用BAAI/bge-base-zh-v1.5，索引用 HNSW，距离空间算法是cosine，参数包括M=32、construction_ef=256、num_threads=4。

   其中记忆分成 4 个 collection：

   • episodic：对话情节记忆
   • preferences：用户偏好
   • relationship：重要关系事件
   • user_profile：用户客观信息

   collection	document （向量化文本）	metadata
   episodic	一段格式化对话文本：时间：... \n用户: ... \n智能体: ...，如果有用户情绪，会再追加一行 用户情绪: ...	固定字段：timestamp、type="conversation"、importance、decay_factor=1.0、last_accessed；可选字段：user_emotion（JSON字符串）、context（通常是“内心思考: …”）
   preferences	一条偏好描述文本：用户喜欢{category}: {item} 或 用户不喜欢{category}: {item}	category、item、sentiment、certainty、timestamp、last_confirmed
   relationship	关系事件文本，本质上就是事件描述，比如“关系亲密度从 x 变为 y”或某次重要互动描述	timestamp、type="relationship_event"、importance、relationship_level、impact
   user_profile	一条用户客观信息文本：用户{category}: {value}	category、value、confidence、source、timestamp、last_updated

2. 写入层

   每轮回复后，主流程不会阻塞等待，异步写回记忆

   写回分两步：

   • 先把本轮 用户输入 + AI回复 + 用户情绪 + 内心思考 存成 episodic memory
   • 再把“内心思考”发给memory_manager，由它决定是否更新：
     • AI 自身情绪 update_emotion
     • 关系事件 record_relationship_event→relationship
     • 用户偏好 save_user_preference→preferences
     • 用户档案 save_user_profile_info / update_user_profile_from_chat→user_profile

   回写时给 memory_manager 的额外提示词为：

   1
   根据以下内心思考，请：
   2
   1. 判断是否需要更新智能体情感状态（使用update_emotion）
   3
   2. 判断是否记录关系事件（record_relationship_event）
   4
   3. 根据内心思考的建议处理可能的用户偏好（save_user_preference）
   5
   4. 记录可能的用户信息（save_user_profile_info），用户信息也包括上下班时间这些日常时间，假如用户提到时间相关的内容（如"昨天"、"上周"、"最近"等），
   6
      请结合当前时间记录具体的时间，比如用户说明天下午要考试，当前时间是2025-06-09，星期一，你就要记录用户的考试时间为2025-06-10，星期二下午。
   7
   
   8
   内心思考内容:
   9
   {inner_thoughts}
   10
   
   11
   当前对话上下文：
   12
   用户输入: {user_input}
   13
   智能体回答: {response}
   14
   用户情绪: {emotion} ({valence})
   15
   
   16
   当前状态:
   17
   当前情绪: {current_emotion}
   18
   当前关系: {relationship_level}/10
   19
   
   20
   如果需要记录关系事件或用户偏好，请简要描述事件内容和重要性。
   21
   如果本次的回复内容是报错信息，就不要记录任何内容。
   

3. 检索层

   每轮对话时把用户输入发给 memory_manager，并附带当前时间，让它结合“昨天 / 上周 / 最近”这类时间词做检索。

   检索时的额外提示词：

   1
   请搜索与以下用户输入相关的记忆，并获取完整的用户信息。
   2
   
   3
   用户输入: {user_input}
   4
   
   5
   当前时间信息:
   6
   - 日期时间: {time_str}
   7
   - 星期: {weekday}
   8
   
   9
   请在搜索记忆时考虑时间因素，如果用户提到时间相关的内容（如"昨天"、"上周"、"最近"等），请结合当前时间进行准确的记忆检索。
   

   这次调用的输出直接作为中间思考和主回答输出的记忆上下文，由于 memory_manager 是一个具备工具调用功能的Agent，它可以根据LLM的判断分别从各个collection和情绪状态机中读取记忆数据，因此没有直接的关于输出格式的要求，直接输出整理好的记忆上下文。

根据以上的RAG设计我们可以看出，在我V1的设计中，检索功能主要是基于 memory_manager 的判断、工具调用和信息整理，直接由代码实现的内容主要是提供给agent的工具如search_memories，get_user_profile_summary，search_user_profile，方便LLM进行调用。

这种方式的优势很明显：依靠模型决策和理解能力动态调用工具进行检索和汇总，减少了人为设计检索流程和方法的工作量，整体流程也比较直观，易于理解。但是它的问题也很明显，检索质量会高度依赖模型能力和当次决策稳定性，而不是更多地依赖系统本身的约束与设计。对很多希望效果稳定、可调试、可评估的真实应用来说，这种方式通常并不稳妥。另外这个版本还有一些具体问题，比如检索时没有给 Agent 提供充分的对话上下文、嵌入向量的 metadata 没有被充分利用等。

MiraMate-v2（开发于2025年8月）#

这个版本的记忆系统，本质上是一个“四层记忆”设计：

1. 短期会话记忆：TimeTokenMemory 保存当前会话消息，按 token、时间、连续性裁剪。
2. 长期语义记忆：ChromaDB 里 4 个 collection，统一用 bge-base-zh-v1.5 做 embedding，HNSW 配置是 cosine / M=32 / construction_ef=256。
3. 会话级检索缓存：检索到的长期记忆先进入 MemoryCache，默认 TTL 5 轮。在对话中有些记忆信息虽然不是与本次input最相关的，但是在前几轮被提及、召回过，为了保证在后续的对话中保持记忆的连贯表现，通过缓存衰减让被召回过的记忆在后续轮次也加入模型上下文。
4. 缓冲与空闲固化：事实/偏好/画像更新先写 JSON cache，空闲时再整合写回长期记忆；重大事件也是空闲时从最近对话和临时关注事件里再识别出来。

v2与v1的一个很大的区别在于v2不再使用真正的Agent调用工具的方式的来处理每个环节，而是利用Langchain的Runnable接口直接编排调用模型API接收输入并输出json参数，因此没有单独的Agent提示词。

RAG 整体链路：

• 先用小模型跑understanding_chain，产出 intent / emotion / memory_query。
• 再用 memory_query 去做综合检索：dialog_logs + facts + user_preferences + important_events，外加 temp_focus_events 的关键词匹配。
• 新检索到的记忆先放进会话缓存，再把“当前有效缓存记忆”注入回答流程中的系统提示词。
• 系统提示词里同时还会注入 user_profile.always_remember、当前状态、近期关注事件。

如果把 v2 的主链路画出来，大致是这样：

长期语义记忆：

我们从RAG的角度分析一下这里的collection设计：

• 提供基于对话上下文提取的对话摘要信息，补全了这段对话信息的背景→补全文本的业务上下文
• 时间信息使用将标准时间编码转化为自然语言的表述方式，更贴合查询时可能的查询方式，并降低后续模型使用该内容作为记忆上下文的理解难度，提升回答质量
• 抽取出文本标签并写入→提高嵌入向量的语义准确度（降低嵌入模型的“理解难度”）

检索层：

这里具体展示一下我在understanding_chain中的做法：

1
understanding_chain = (understanding_prompt | small_llm | JsonOutputParser()).with_config(run_name="EnhancedUnderstandingChain")

understanding_chain的模型提示词

1
你是一个对话分析专家。
2
基于近期对话历史，分析用户最新输入。
3
提取核心意图、情感，并生成一个最适合用于向量数据库检索的精准查询语句。
4
数据库中的记忆内容是以 AI 第一人称视角记录的……
5
对话历史:
6
{conversation_history}
7

8
用户最新输入: {user_input}
9
当前时间: {current_time}
10

11
严格输出 JSON，包含:
12
- intent
13
- emotion
14
- memory_query

这里的提示词我们可以看到一些对LLM工作场景上的优化细节：

• 你是一个对话分析专家→明确工作场景和思考方式
• 基于近期对话历史，分析用户最新输入→明确任务需求
• 提取核心意图、情感，并生成一个最适合用于向量数据库检索的精准查询语句→任务的具体处理方法，指导模型正确地完成生成任务
• 数据库中的记忆内容是以 AI 第一人称视角记录的……→明确数据存储方式，提示模型使用第一人称的查询
• 当前时间→针对本项目24小时情感陪伴Agent的场景的额外信息，帮助模型判断对话时间、查询相关时间的记忆

使用 Langchain 的 LLM 工作流编排方式构建整体系统，这更符合普遍 RAG 场景下的工作模式。模型不再需要做复杂且关键的全局决策，而是根据预先设定好的工作流输出下一个环节所需的参数，成为流水线上的一个环节。这样做显著降低了模型带来的不确定性，而省掉额外的工具调用流程也让一次完整链路的运行时间明显缩短，用户体验更稳定。

相较于 v1，我认为 v2 的改进主要体现在三点：

• 模型职责被收窄了，LLM 更像一个“局部任务执行器”，而不是负责全局决策的 Agent
• 检索链路变得更显式、更可观察，哪些输入影响了 query，哪些记忆被召回，哪些上下文被注入，都更容易调试
• 会话缓存和分层记忆让系统在多轮对话里的连续性更自然，不需要每一轮都完全从零开始重建记忆上下文
• 记忆文本包含更完善的对话上下文信息，使得检索和使用这些记忆时有更好的表现

当然，v2 也不是没有代价。相比让 Agent 自由调用工具的方式，工作流编排意味着更多规则前置和更多人工设计，系统的灵活性会下降一些，后续每增加一种新记忆类型、新检索策略，往往都要显式修改链路本身。这也是在设计 RAG 系统时需要抉择的部分。

另外，严格来说，RAG 系统里还有一个很常见但我在本文没有展开的话题，就是 reranker（重排序模型）。它通常用于在向量检索初步召回一批候选结果之后，再对这些候选片段做一次更精细的相关性排序，以提高最终送入 LLM 的上下文质量。由于我自己目前还没有在实际项目里深入使用和调优这类模型，所以这篇文章没有详细展开这一部分，只在这里作为一个值得继续关注的优化方向提一下。对一些召回范围较大、候选片段质量参差不齐的 RAG 场景来说，reranker 往往是很重要的一环。

从 MiraMate v1 到 v2，我逐渐明确了一点：在 RAG 系统里，不应该让模型承担过多高不确定性的全局决策，而应该让模型在受约束的流程里完成自己最擅长的局部任务。

无论是传统 RAG 的 query rewrite、metadata 利用、索引文本设计，还是 Graph RAG 中的 schema 提供、候选节点召回、Cypher 生成约束，本质上都在做同一件事：为模型补充正确的上下文，并让模型充分发挥自身能力。

所以，RAG 的优化很多时候不是“换一个更强的模型”就能解决，而是重新设计从数据入库、检索、排序到生成的整条链路。