介绍 mRAG：EverOS 如何检索真正重要的信息 - EverMind AI 长期记忆系统更新与突破

记忆系统存在检索问题。它们中的大多数只能找到那些听起来与查询相关的内容。EverOS mRAG 能找到真正相关的内容——通过深入一层，达到任何标准搜索都无法触及的地方。

这篇文章解释了什么是 mRAG、它为何存在，以及它对你和你的智能体意味着什么。

大多数记忆检索工作的方式有什么问题

当你向记忆系统提问时，标准做法是把你的查询转换成向量，并找出与之最接近的已存摘要。快、简单，但对于复杂问题来说，往往是错的。

原因如下。你真正需要的内容，往往埋在记忆的内部，而不是摘要层面可见。一段事件摘要可能会写着“讨论了项目时间表和团队分配”。你需要的细节——“团队一致认为第二季度的截止日期不现实”——则位于再往下两层的地方，也就是从那段对话中提取出的原子事实。

标准检索永远到不了那里。它能找到正确的街区，却在你需要公寓门牌号时只给你街道地址。

mRAG 的设计就是为了解决这个问题。

mRAG 的不同之处

mRAG 代表多模态 RAG。其核心思想是分层搜索：先对事件摘要进行粗略扫描，找到正确的大致范围，然后在这些事件中展开到精确的原子事实——并用这些事实在最终结果中替换更粗粒度的摘要。

换句话说，mRAG 把检索视为一个两层问题。摘要是一张地图。原子事实是领土。你用地图导航，但返回的是领土本身。

结果是一组具体、可验证、细粒度的事实，能够精确回答你的查询——而不是一堆仅仅大致相关的模糊摘要。

它如何工作：五阶段流水线

阶段 1：跨事件摘要的粗检索

mRAG 首先会针对你的事件记忆并行运行两种搜索：

嵌入搜索——使用余弦相似度，将你的查询的语义含义与事件摘要进行比较
BM25 关键词搜索——将查询中的实际词语与事件和摘要文本进行匹配

随后将这两组结果融合成一个统一的排序列表。默认情况下，EverOS 使用 RRF（倒数排名融合），它会结合两种搜索的排名位置，而不会过度偏向任一信号。在可训练模型能够学习最佳信号组合的环境中，也可使用 LR（逻辑回归）融合模式。

这一阶段会返回一个粗略的候选清单：那些大概率与你的查询相关的事件。

阶段 2：建立搜索结构

在展开到原子事实之前，mRAG 会初始化两个数据结构：

一个最小堆，用于保存当前前 N 个结果。最小堆使得可以高效地在 O(1) 时间内判断一个新候选是否足以挤掉现有结果。
一个覆盖所有粗检索结果的最大堆，按相关性得分排序，用于决定接下来展开哪些事件。

可以把它理解为：最小堆是你现在会给出的答案，而最大堆是仍在等待调查的事件队列。

阶段 3：展开——mRAG 的核心

这就是 mRAG 做出任何扁平检索系统都不会做的事情的地方。

流水线会批量处理事件队列。每次弹出一个事件时，它会检索与该事件相关的原子事实——也就是从那段对话或文档中提取出的具体、离散的陈述——并根据你的原始查询对它们进行打分。

评分公式为：

final_score = α × fact_score + (1 - α) × episode_score

其中：

fact_score 表示该原子事实与你的查询匹配得有多紧密（由余弦相似度和 BM25 的逻辑回归组合得出）
episode_score 表示父事件传播下来的相关性（由第 1 阶段中的余弦相似度和 BM25 的逻辑回归组合得出）
α 用来平衡应当给事实本身多少权重，以及给其来源事件多少权重（默认值：0.5）

关键设计是：当某个原子事实的得分足够高、进入前 N 结果时，它的父事件会从该集合中移除。精确的事实取代粗粒度的摘要。你得到的是具体细节，而不是它被存放的容器。

这个循环会一直持续，直到所有事件都处理完，或者连续若干轮都没有改进为止。后者是一个收敛检查，用于防止在结果已经稳定时继续浪费计算。

阶段 4：构建输出

一旦循环收敛，前 N 集合中就会包含多种项目：

仍然相关、但其事实没有取得更高分的事件
替代了其父事件的原子事实

二者都会在响应中展示。返回前会先按最终得分排序。

阶段 5：[可选] 重排序

对于精度至关重要的用例，mRAG 支持可选的最终重排序步骤。专门的重排序模型会重新为阶段 4 的输出打分，应用更深层的语义理解，从而生成最终排序列表。

这一步默认关闭，因为仅靠这五阶段流水线就已经能提供很强的精度。但对于高价值检索场景，如果额外延迟值得付出，它也可以启用。

返回什么内容

一次 mRAG 检索响应包含两部分：

事件——与查询提供上下文的相关记忆记录，其中没有原子事实能清晰地替代它们。

事实——从记忆中提取出的、能够直接回答你查询的精确原子陈述。每个事实都带有其主题标签、父记忆 ID 和最终相关性得分。

例如，像“我们就第二季度截止日期做了什么决定？”这样的查询，可能会返回：

{
  "episodes": [
    {
      "id": "ep_002",
      "summary": "Team discussed project timeline and resource constraints",
      "score": 0.72,
      "atomic_facts": [
        {
          "id": "fact_001",
          "atomic_fact": "The team agreed the Q2 deadline is unrealistic given current headcount",
          "topic_name": "Project timeline",
          "score": 0.91,
          "parent_episode_id": "ep_002"
        }
      ]
    }
  ],
  "profiles": [...],
  "raw_messages": [...],
  "agent_memory": {...},
  "query": {
    "text": "...",
    "method": "hybrid",
    "filters_applied": {...}
  }
}

mRAG 同时返回了事件和事实。事件提供更广泛的知识，而事实提供更精确的信息。

适用于你的所有内容类型

mRAG 与数据类型无关。相同的流水线可跨对话、文档、电子邮件、会议记录、PDF、表格、演示文稿和图像进行检索——因为这些内容在摄取时都会被处理成相同的 Episodic Memory 和 AtomicFact 结构。

支持多模态解析的格式：

PDF（基于文本和扫描件）
图像（.png、.jpg、.jpeg、.webp、.tiff、.bmp、.svg）
Word 文档（.docx、.doc）
电子表格（.xlsx、.xls）
演示文稿（.pptx、.ppt）
电子邮件（.eml）
HTML（.html、.htm）

无需解析即可直接提取的格式：

纯文本和 Markdown（.txt、.md）
字幕和转录稿（.vtt）
表格型纯文本（.csv、.tsv）

无论你的相关上下文是上周二的一段对话，还是六个月前上传的 PDF，mRAG 都会通过同一个端点，用同一个查询跨两者进行检索。

如何使用

mRAG 可作为 EverOS 搜索端点上的一种检索方法。请在你的搜索请求中将 "method" 设为 "hybrid"：

POST /api/v1/memories/search

{
  "query": "what did we decide about the Q2 deadline?",
  "method": "hybrid",
  "filters": { "user_id": "user_123" },
  "top_k": 10
}

响应将同时包含 episodes 数组和 facts 数组。对于已有集成，这一变化向后兼容：所有非 mRAG 方法都会返回一个空的 facts 字段，因此如果你不使用它，也不会有任何破坏。

何时使用 mRAG 而不是其他检索方法

EverOS 提供多种检索方法，每种都适用于不同场景：

keyword——快速、精确匹配的检索。适合你已经知道自己要找的具体术语时使用。

vector——基于向量相似度的纯语义嵌入检索。适合开放式、以意图驱动的查询，此时含义比字面词语更重要；也适合在术语不同但上下文相似时查找记忆。

agentic——使用 Memory Interleave 的迭代式多跳检索。适合复杂的、多步骤推理场景，即答案需要跨多个记忆串联证据。

hybrid——默认选项。层级式的事件到事实检索，在效率与效果之间取得平衡。最适合你需要精确性、答案是具体事实而非一般摘要，以及你的记忆包含多种内容类型的查询。尤其适合涉及具体决定、数字、承诺，或容易在更大范围摘要中丢失的细节的查询。

性能表现

内部基准测试显示，mRAG 的层级方法在事实层面而非事件层面进行检索，在需要具体细节的查询上始终优于扁平检索。性能最高的配置会使用源级上下文进行检索并返回事实，将事件扫描的广覆盖与原子事实匹配的高精度结合起来。

相比之下，基于块的扁平检索在具体细节查询上的准确率更低，而且每个结果返回的有用上下文要少得多。

所有控制 mRAG 行为的参数——包括每个阶段检索的候选数量、得分传播权重、收敛阈值、重排序器开关——都可以通过环境变量进行配置。它们在系统级进行调优，不向单个 API 请求暴露，这意味着你无需额外配置即可获得强劲的默认性能。

这对你的智能体意味着什么

对于需要推理具体过去事件的智能体，例如会议中的承诺、文档中记录的决定、研究中提取出的事实，mRAG 就是让这种推理变得可靠的检索层。

使用标准检索的智能体也许只能找到“曾经有一段关于项目截止日期的对话”。而使用 mRAG 的智能体会找到第二季度的截止日期被延后了六周，这一点在 3 月 12 日的同步会议中得到确认，因为两名工程师被重新分配了工作。

当你的智能体要评估项目状态、起草跟进信息，或检查之前的承诺是否兑现时，这种差异就非常重要。

记忆只有在检索足够精确时才有用。这正是 mRAG 的目标。

mRAG 现已在 EverOS 上可用。开始使用：everos.evermind.ai
开源仓库：github.com/EverMind-AI/EverOS

记忆系统存在检索问题。它们中的大多数只能找到那些听起来与查询相关的内容。EverOS mRAG 能找到真正相关的内容——通过深入一层，达到任何标准搜索都无法触及的地方。

这篇文章解释了什么是 mRAG、它为何存在，以及它对你和你的智能体意味着什么。

大多数记忆检索工作的方式有什么问题

当你向记忆系统提问时，标准做法是把你的查询转换成向量，并找出与之最接近的已存摘要。快、简单，但对于复杂问题来说，往往是错的。

原因如下。你真正需要的内容，往往埋在记忆的内部，而不是摘要层面可见。一段事件摘要可能会写着“讨论了项目时间表和团队分配”。你需要的细节——“团队一致认为第二季度的截止日期不现实”——则位于再往下两层的地方，也就是从那段对话中提取出的原子事实。

标准检索永远到不了那里。它能找到正确的街区，却在你需要公寓门牌号时只给你街道地址。

mRAG 的设计就是为了解决这个问题。

mRAG 的不同之处

mRAG 代表多模态 RAG。其核心思想是分层搜索：先对事件摘要进行粗略扫描，找到正确的大致范围，然后在这些事件中展开到精确的原子事实——并用这些事实在最终结果中替换更粗粒度的摘要。

换句话说，mRAG 把检索视为一个两层问题。摘要是一张地图。原子事实是领土。你用地图导航，但返回的是领土本身。

结果是一组具体、可验证、细粒度的事实，能够精确回答你的查询——而不是一堆仅仅大致相关的模糊摘要。

它如何工作：五阶段流水线

阶段 1：跨事件摘要的粗检索

mRAG 首先会针对你的事件记忆并行运行两种搜索：

嵌入搜索——使用余弦相似度，将你的查询的语义含义与事件摘要进行比较
BM25 关键词搜索——将查询中的实际词语与事件和摘要文本进行匹配

随后将这两组结果融合成一个统一的排序列表。默认情况下，EverOS 使用 RRF（倒数排名融合），它会结合两种搜索的排名位置，而不会过度偏向任一信号。在可训练模型能够学习最佳信号组合的环境中，也可使用 LR（逻辑回归）融合模式。

这一阶段会返回一个粗略的候选清单：那些大概率与你的查询相关的事件。

阶段 2：建立搜索结构

在展开到原子事实之前，mRAG 会初始化两个数据结构：

一个最小堆，用于保存当前前 N 个结果。最小堆使得可以高效地在 O(1) 时间内判断一个新候选是否足以挤掉现有结果。
一个覆盖所有粗检索结果的最大堆，按相关性得分排序，用于决定接下来展开哪些事件。

可以把它理解为：最小堆是你现在会给出的答案，而最大堆是仍在等待调查的事件队列。

阶段 3：展开——mRAG 的核心

这就是 mRAG 做出任何扁平检索系统都不会做的事情的地方。

流水线会批量处理事件队列。每次弹出一个事件时，它会检索与该事件相关的原子事实——也就是从那段对话或文档中提取出的具体、离散的陈述——并根据你的原始查询对它们进行打分。

评分公式为：

final_score = α × fact_score + (1 - α) × episode_score

其中：

fact_score 表示该原子事实与你的查询匹配得有多紧密（由余弦相似度和 BM25 的逻辑回归组合得出）
episode_score 表示父事件传播下来的相关性（由第 1 阶段中的余弦相似度和 BM25 的逻辑回归组合得出）
α 用来平衡应当给事实本身多少权重，以及给其来源事件多少权重（默认值：0.5）

关键设计是：当某个原子事实的得分足够高、进入前 N 结果时，它的父事件会从该集合中移除。精确的事实取代粗粒度的摘要。你得到的是具体细节，而不是它被存放的容器。

这个循环会一直持续，直到所有事件都处理完，或者连续若干轮都没有改进为止。后者是一个收敛检查，用于防止在结果已经稳定时继续浪费计算。

阶段 4：构建输出

一旦循环收敛，前 N 集合中就会包含多种项目：

仍然相关、但其事实没有取得更高分的事件
替代了其父事件的原子事实

二者都会在响应中展示。返回前会先按最终得分排序。

阶段 5：[可选] 重排序

对于精度至关重要的用例，mRAG 支持可选的最终重排序步骤。专门的重排序模型会重新为阶段 4 的输出打分，应用更深层的语义理解，从而生成最终排序列表。

这一步默认关闭，因为仅靠这五阶段流水线就已经能提供很强的精度。但对于高价值检索场景，如果额外延迟值得付出，它也可以启用。

返回什么内容

一次 mRAG 检索响应包含两部分：

事件——与查询提供上下文的相关记忆记录，其中没有原子事实能清晰地替代它们。

事实——从记忆中提取出的、能够直接回答你查询的精确原子陈述。每个事实都带有其主题标签、父记忆 ID 和最终相关性得分。

例如，像“我们就第二季度截止日期做了什么决定？”这样的查询，可能会返回：

{
  "episodes": [
    {
      "id": "ep_002",
      "summary": "Team discussed project timeline and resource constraints",
      "score": 0.72,
      "atomic_facts": [
        {
          "id": "fact_001",
          "atomic_fact": "The team agreed the Q2 deadline is unrealistic given current headcount",
          "topic_name": "Project timeline",
          "score": 0.91,
          "parent_episode_id": "ep_002"
        }
      ]
    }
  ],
  "profiles": [...],
  "raw_messages": [...],
  "agent_memory": {...},
  "query": {
    "text": "...",
    "method": "hybrid",
    "filters_applied": {...}
  }
}

mRAG 同时返回了事件和事实。事件提供更广泛的知识，而事实提供更精确的信息。

适用于你的所有内容类型

mRAG 与数据类型无关。相同的流水线可跨对话、文档、电子邮件、会议记录、PDF、表格、演示文稿和图像进行检索——因为这些内容在摄取时都会被处理成相同的 Episodic Memory 和 AtomicFact 结构。

支持多模态解析的格式：

PDF（基于文本和扫描件）
图像（.png、.jpg、.jpeg、.webp、.tiff、.bmp、.svg）
Word 文档（.docx、.doc）
电子表格（.xlsx、.xls）
演示文稿（.pptx、.ppt）
电子邮件（.eml）
HTML（.html、.htm）

无需解析即可直接提取的格式：

纯文本和 Markdown（.txt、.md）
字幕和转录稿（.vtt）
表格型纯文本（.csv、.tsv）

无论你的相关上下文是上周二的一段对话，还是六个月前上传的 PDF，mRAG 都会通过同一个端点，用同一个查询跨两者进行检索。

如何使用

mRAG 可作为 EverOS 搜索端点上的一种检索方法。请在你的搜索请求中将 "method" 设为 "hybrid"：

POST /api/v1/memories/search

{
  "query": "what did we decide about the Q2 deadline?",
  "method": "hybrid",
  "filters": { "user_id": "user_123" },
  "top_k": 10
}

响应将同时包含 episodes 数组和 facts 数组。对于已有集成，这一变化向后兼容：所有非 mRAG 方法都会返回一个空的 facts 字段，因此如果你不使用它，也不会有任何破坏。

何时使用 mRAG 而不是其他检索方法

EverOS 提供多种检索方法，每种都适用于不同场景：

keyword——快速、精确匹配的检索。适合你已经知道自己要找的具体术语时使用。

vector——基于向量相似度的纯语义嵌入检索。适合开放式、以意图驱动的查询，此时含义比字面词语更重要；也适合在术语不同但上下文相似时查找记忆。

agentic——使用 Memory Interleave 的迭代式多跳检索。适合复杂的、多步骤推理场景，即答案需要跨多个记忆串联证据。

hybrid——默认选项。层级式的事件到事实检索，在效率与效果之间取得平衡。最适合你需要精确性、答案是具体事实而非一般摘要，以及你的记忆包含多种内容类型的查询。尤其适合涉及具体决定、数字、承诺，或容易在更大范围摘要中丢失的细节的查询。

性能表现

内部基准测试显示，mRAG 的层级方法在事实层面而非事件层面进行检索，在需要具体细节的查询上始终优于扁平检索。性能最高的配置会使用源级上下文进行检索并返回事实，将事件扫描的广覆盖与原子事实匹配的高精度结合起来。

相比之下，基于块的扁平检索在具体细节查询上的准确率更低，而且每个结果返回的有用上下文要少得多。

所有控制 mRAG 行为的参数——包括每个阶段检索的候选数量、得分传播权重、收敛阈值、重排序器开关——都可以通过环境变量进行配置。它们在系统级进行调优，不向单个 API 请求暴露，这意味着你无需额外配置即可获得强劲的默认性能。

这对你的智能体意味着什么

对于需要推理具体过去事件的智能体，例如会议中的承诺、文档中记录的决定、研究中提取出的事实，mRAG 就是让这种推理变得可靠的检索层。

使用标准检索的智能体也许只能找到“曾经有一段关于项目截止日期的对话”。而使用 mRAG 的智能体会找到第二季度的截止日期被延后了六周，这一点在 3 月 12 日的同步会议中得到确认，因为两名工程师被重新分配了工作。

当你的智能体要评估项目状态、起草跟进信息，或检查之前的承诺是否兑现时，这种差异就非常重要。

记忆只有在检索足够精确时才有用。这正是 mRAG 的目标。

mRAG 现已在 EverOS 上可用。开始使用：everos.evermind.ai
开源仓库：github.com/EverMind-AI/EverOS

记忆系统存在检索问题。它们中的大多数只能找到那些听起来与查询相关的内容。EverOS mRAG 能找到真正相关的内容——通过深入一层，达到任何标准搜索都无法触及的地方。

这篇文章解释了什么是 mRAG、它为何存在，以及它对你和你的智能体意味着什么。

大多数记忆检索工作的方式有什么问题

当你向记忆系统提问时，标准做法是把你的查询转换成向量，并找出与之最接近的已存摘要。快、简单，但对于复杂问题来说，往往是错的。

原因如下。你真正需要的内容，往往埋在记忆的内部，而不是摘要层面可见。一段事件摘要可能会写着“讨论了项目时间表和团队分配”。你需要的细节——“团队一致认为第二季度的截止日期不现实”——则位于再往下两层的地方，也就是从那段对话中提取出的原子事实。

标准检索永远到不了那里。它能找到正确的街区，却在你需要公寓门牌号时只给你街道地址。

mRAG 的设计就是为了解决这个问题。

mRAG 的不同之处

mRAG 代表多模态 RAG。其核心思想是分层搜索：先对事件摘要进行粗略扫描，找到正确的大致范围，然后在这些事件中展开到精确的原子事实——并用这些事实在最终结果中替换更粗粒度的摘要。

换句话说，mRAG 把检索视为一个两层问题。摘要是一张地图。原子事实是领土。你用地图导航，但返回的是领土本身。

结果是一组具体、可验证、细粒度的事实，能够精确回答你的查询——而不是一堆仅仅大致相关的模糊摘要。

它如何工作：五阶段流水线

阶段 1：跨事件摘要的粗检索

mRAG 首先会针对你的事件记忆并行运行两种搜索：

嵌入搜索——使用余弦相似度，将你的查询的语义含义与事件摘要进行比较
BM25 关键词搜索——将查询中的实际词语与事件和摘要文本进行匹配

随后将这两组结果融合成一个统一的排序列表。默认情况下，EverOS 使用 RRF（倒数排名融合），它会结合两种搜索的排名位置，而不会过度偏向任一信号。在可训练模型能够学习最佳信号组合的环境中，也可使用 LR（逻辑回归）融合模式。

这一阶段会返回一个粗略的候选清单：那些大概率与你的查询相关的事件。

阶段 2：建立搜索结构

在展开到原子事实之前，mRAG 会初始化两个数据结构：

一个最小堆，用于保存当前前 N 个结果。最小堆使得可以高效地在 O(1) 时间内判断一个新候选是否足以挤掉现有结果。
一个覆盖所有粗检索结果的最大堆，按相关性得分排序，用于决定接下来展开哪些事件。

可以把它理解为：最小堆是你现在会给出的答案，而最大堆是仍在等待调查的事件队列。

阶段 3：展开——mRAG 的核心

这就是 mRAG 做出任何扁平检索系统都不会做的事情的地方。

流水线会批量处理事件队列。每次弹出一个事件时，它会检索与该事件相关的原子事实——也就是从那段对话或文档中提取出的具体、离散的陈述——并根据你的原始查询对它们进行打分。

评分公式为：

final_score = α × fact_score + (1 - α) × episode_score

其中：

fact_score 表示该原子事实与你的查询匹配得有多紧密（由余弦相似度和 BM25 的逻辑回归组合得出）
episode_score 表示父事件传播下来的相关性（由第 1 阶段中的余弦相似度和 BM25 的逻辑回归组合得出）
α 用来平衡应当给事实本身多少权重，以及给其来源事件多少权重（默认值：0.5）

关键设计是：当某个原子事实的得分足够高、进入前 N 结果时，它的父事件会从该集合中移除。精确的事实取代粗粒度的摘要。你得到的是具体细节，而不是它被存放的容器。

这个循环会一直持续，直到所有事件都处理完，或者连续若干轮都没有改进为止。后者是一个收敛检查，用于防止在结果已经稳定时继续浪费计算。

阶段 4：构建输出

一旦循环收敛，前 N 集合中就会包含多种项目：

仍然相关、但其事实没有取得更高分的事件
替代了其父事件的原子事实

二者都会在响应中展示。返回前会先按最终得分排序。

阶段 5：[可选] 重排序

对于精度至关重要的用例，mRAG 支持可选的最终重排序步骤。专门的重排序模型会重新为阶段 4 的输出打分，应用更深层的语义理解，从而生成最终排序列表。

这一步默认关闭，因为仅靠这五阶段流水线就已经能提供很强的精度。但对于高价值检索场景，如果额外延迟值得付出，它也可以启用。

返回什么内容

一次 mRAG 检索响应包含两部分：

事件——与查询提供上下文的相关记忆记录，其中没有原子事实能清晰地替代它们。

事实——从记忆中提取出的、能够直接回答你查询的精确原子陈述。每个事实都带有其主题标签、父记忆 ID 和最终相关性得分。

例如，像“我们就第二季度截止日期做了什么决定？”这样的查询，可能会返回：

{
  "episodes": [
    {
      "id": "ep_002",
      "summary": "Team discussed project timeline and resource constraints",
      "score": 0.72,
      "atomic_facts": [
        {
          "id": "fact_001",
          "atomic_fact": "The team agreed the Q2 deadline is unrealistic given current headcount",
          "topic_name": "Project timeline",
          "score": 0.91,
          "parent_episode_id": "ep_002"
        }
      ]
    }
  ],
  "profiles": [...],
  "raw_messages": [...],
  "agent_memory": {...},
  "query": {
    "text": "...",
    "method": "hybrid",
    "filters_applied": {...}
  }
}

mRAG 同时返回了事件和事实。事件提供更广泛的知识，而事实提供更精确的信息。

适用于你的所有内容类型

mRAG 与数据类型无关。相同的流水线可跨对话、文档、电子邮件、会议记录、PDF、表格、演示文稿和图像进行检索——因为这些内容在摄取时都会被处理成相同的 Episodic Memory 和 AtomicFact 结构。

支持多模态解析的格式：

PDF（基于文本和扫描件）
图像（.png、.jpg、.jpeg、.webp、.tiff、.bmp、.svg）
Word 文档（.docx、.doc）
电子表格（.xlsx、.xls）
演示文稿（.pptx、.ppt）
电子邮件（.eml）
HTML（.html、.htm）

无需解析即可直接提取的格式：

纯文本和 Markdown（.txt、.md）
字幕和转录稿（.vtt）
表格型纯文本（.csv、.tsv）

无论你的相关上下文是上周二的一段对话，还是六个月前上传的 PDF，mRAG 都会通过同一个端点，用同一个查询跨两者进行检索。

如何使用

mRAG 可作为 EverOS 搜索端点上的一种检索方法。请在你的搜索请求中将 "method" 设为 "hybrid"：

POST /api/v1/memories/search

{
  "query": "what did we decide about the Q2 deadline?",
  "method": "hybrid",
  "filters": { "user_id": "user_123" },
  "top_k": 10
}

响应将同时包含 episodes 数组和 facts 数组。对于已有集成，这一变化向后兼容：所有非 mRAG 方法都会返回一个空的 facts 字段，因此如果你不使用它，也不会有任何破坏。

何时使用 mRAG 而不是其他检索方法

EverOS 提供多种检索方法，每种都适用于不同场景：

keyword——快速、精确匹配的检索。适合你已经知道自己要找的具体术语时使用。

vector——基于向量相似度的纯语义嵌入检索。适合开放式、以意图驱动的查询，此时含义比字面词语更重要；也适合在术语不同但上下文相似时查找记忆。

agentic——使用 Memory Interleave 的迭代式多跳检索。适合复杂的、多步骤推理场景，即答案需要跨多个记忆串联证据。

hybrid——默认选项。层级式的事件到事实检索，在效率与效果之间取得平衡。最适合你需要精确性、答案是具体事实而非一般摘要，以及你的记忆包含多种内容类型的查询。尤其适合涉及具体决定、数字、承诺，或容易在更大范围摘要中丢失的细节的查询。

性能表现

内部基准测试显示，mRAG 的层级方法在事实层面而非事件层面进行检索，在需要具体细节的查询上始终优于扁平检索。性能最高的配置会使用源级上下文进行检索并返回事实，将事件扫描的广覆盖与原子事实匹配的高精度结合起来。

相比之下，基于块的扁平检索在具体细节查询上的准确率更低，而且每个结果返回的有用上下文要少得多。

所有控制 mRAG 行为的参数——包括每个阶段检索的候选数量、得分传播权重、收敛阈值、重排序器开关——都可以通过环境变量进行配置。它们在系统级进行调优，不向单个 API 请求暴露，这意味着你无需额外配置即可获得强劲的默认性能。

这对你的智能体意味着什么

对于需要推理具体过去事件的智能体，例如会议中的承诺、文档中记录的决定、研究中提取出的事实，mRAG 就是让这种推理变得可靠的检索层。

使用标准检索的智能体也许只能找到“曾经有一段关于项目截止日期的对话”。而使用 mRAG 的智能体会找到第二季度的截止日期被延后了六周，这一点在 3 月 12 日的同步会议中得到确认，因为两名工程师被重新分配了工作。

当你的智能体要评估项目状态、起草跟进信息，或检查之前的承诺是否兑现时，这种差异就非常重要。

记忆只有在检索足够精确时才有用。这正是 mRAG 的目标。

mRAG 现已在 EverOS 上可用。开始使用：everos.evermind.ai
开源仓库：github.com/EverMind-AI/EverOS