企业官网建设流程全解析

• 人工智能
• 大模型
• Agent 记忆
• AI Agent
• RAG
• 知识图谱
• dsh-plugin

记忆系统的好坏不能靠直觉判断，必须用标准化的长对话数据集与可复现的评测流水线来度量。MemOS 仓库在 docs/cn/open_source/evaluation/overview.md 中提供了一套完整的记忆评估框架，覆盖 LoCoMo、LongMemEval、PrefEval、PersonaMem 四大主流记忆评测数据集，支持以 MemOS 自身 API 为基准后端，并可横向对比 mem0、Zep、Memobase、Supermemory、Memu 等第三方记忆框架。读完本文，你将掌握如何部署 MemOS 记忆服务、配置评估环境、逐数据集运行评测脚本，以及如何解读 LLM-as-a-Judge、词法与语义指标的评估结果。

一、评估框架定位：记忆系统需要可量化的基准

LLM 与 AI Agent 的长对话记忆能力通常体现为“能否在后续对话中回忆起早期提及的事实”。为了把这种能力变成可复现的数字，学术界与工业界沉淀了若干标准数据集：LoCoMo 关注跨多轮会话的长期对话记忆、LongMemEval 侧重长上下文中的时间敏感问题、PrefEval 聚焦用户偏好记忆、PersonaMem 则围绕用户画像（Persona）构建问题。MemOS 的评估框架正是为这些数据集提供了开箱即用的评测工具与脚本。

该框架由仓库根目录的 evaluation/ 目录承载，核心能力如下：

• 数据集支持：LoCoMo、LongMemEval（longmemeval_s）、PrefEval、PersonaMem 四类评估入口，另有 LongBench-v2 与 RAG 全上下文对照实验脚本；
• 后端支持：官方优先支持memos-api与memos-api-online两种 MemOS 接入方式，同时为非官方实现提供了zep、mem0、memobase、supermemory、memu的适配客户端；
• 标准化流水线：每个数据集都遵循“数据摄入（ingestion）→ 记忆检索（search）→ 答案生成（responses）→ 自动评判（eval）→ 指标聚合（metric）”五段式流程。

二、环境安装与配置

2.1 设置 PYTHONPATH 与安装依赖

评估脚本通过PYTHONPATH指向仓库的src目录以导入 MemOS 核心模块，并依赖 poetry 管理依赖。在仓库根目录执行：

export PYTHONPATH=../src cd evaluation # 请在仓库根目录执行

注意：文档中的PYTHONPATH=../src与cd evaluation以仓库根目录为基准；若你的evaluation目录不在仓库根目录下，请按实际路径调整。

随后安装评估所需的全部依赖：

poetry install --extras all --with eval

--extras all会安装 MemOS 的完整可选依赖，--with eval会额外安装评估组依赖（如openai、sentence_transformers、bert_score、rouge_score、nltk、tiktoken、pandas等，这些均在 evaluation/scripts/locomo/locomo_eval.py 的导入列表中可以看到）。

2.2 配置文件 .env

框架通过环境变量注入各类 API 密钥与端点。仓库提供了模板文件 evaluation/.env-example，将其复制为.env并填写真实值即可：

cp evaluation/.env-example evaluation/.env

模板中的关键变量如下：

从客户端实现来看，SEARCH_MODE环境变量还会影响 MemOS 的检索模式（默认fast，见 evaluation/scripts/utils/client.py 中MemosApiClient.search的mode字段），高级用户可按需覆盖。

三、部署 MemOS 记忆服务：本地与在线两种接入方式

评估 MemOS 前需要先有一个可用的 MemOS 记忆后端。框架支持两种接入方式。

3.1 本地服务（推荐，用于 LongMemEval 等对时间语义敏感的评测）

先修改{project_dir}/.env完成 MemOS 自身的环境配置，然后以多 worker 方式启动 API 服务：

uvicorn memos.api.server_api:app --host 0.0.0.0 --port 8001 --workers 8

接着在评估目录的.env中把MEMOS_URL指向该服务：

MEMOS_URL="http://127.0.0.1:8001"

从源码看，本地客户端MemosApiClient会调用POST {MEMOS_URL}/product/add写入记忆、POST {MEMOS_URL}/product/search检索记忆（见 evaluation/scripts/utils/client.py），因此启动的是 MemOS 的product产品接口，服务入口对应 src/memos/api/server_api.py。

3.2 在线服务

如果使用 MemOS 云服务，则在{project_dir}/evaluation/.env中配置：

MEMOS_KEY="Token mpg-xxxxx" MEMOS_ONLINE_URL="https://memos.memtensor.cn/api/openmem/v1"

在线客户端MemosApiOnlineClient使用POST /add/message与POST /search/memory接口，且检索响应中会额外返回preference_detail_list（显式/隐式偏好）与preference_note，用于把用户偏好作为上下文的一部分注入答案生成（见 evaluation/scripts/utils/client.py 的MemosApiOnlineClient.search）。

四、支持的记忆框架矩阵

评估脚本统一通过--lib（或脚本内的LIB变量）指定记忆后端。可选的取值包括：

每种后端都有对应的客户端封装在 evaluation/scripts/utils/client.py 中，统一暴露add(messages, user_id, ...)与search(query, user_id, top_k)两个核心方法，这使得各数据集的 ingestion/search 脚本可以完全复用同一套流程，仅需替换客户端实现。这种“插件化客户端”的设计也意味着你可以基于同样的接口自行接入新的记忆框架。

五、LoCoMo 评估：从摄入到指标的完整流水线

LoCoMo（Long Conversation Memory）评估关注“跨 10 个用户、多天多会话”的长期对话记忆。仓库已随附采样数据 evaluation/data/locomo/locomo10.json。

5.1 一键运行

编辑 evaluation/scripts/run_locomo_eval.sh 中的LIB、VERSION、WORKERS、TOPK等配置后执行：

evaluation/scripts/run_locomo_eval.sh

脚本内部依次执行五个阶段（各阶段失败即退出）：

1. locomo_ingestion.py：将 LoCoMo 对话按用户分批写入所选记忆后端；
2. locomo_search.py：针对每个问题检索 Top-K 记忆作为上下文；
3. locomo_responses.py：基于检索上下文生成答案；
4. locomo_eval.py：以 LLM 作为裁判对答案打分（默认--num_runs 3，即每道题独立评判 3 次）；
5. locomo_metric.py：聚合词法、语义与耗时指标，输出 JSON 与 Excel 报告。

脚本默认参数为LIB="memos-api"、VERSION="default"、WORKERS=10、TOPK=20，运行前可在文件头部直接修改。

5.2 结果存放与分类

评估中间结果与最终报告存放在results/locomo/{lib}-{version}/目录下，包括*_locomo_responses.json、*_locomo_judged.json、*_locomo_grades.json以及*_locomo_results.xlsx。

LoCoMo 的问题被划分为四类，evaluation/scripts/locomo/locomo_metric.py 中的分类映射为：

category_mapping = { "4": "single hop", # 单跳 "1": "multi hop", # 多跳 "2": "temporal reasoning", # 时间推理 "3": "open domain", # 开放领域 }

最终报告会按“总体（overall）、分类（category）、单个用户（user）”三个粒度分别输出得分，便于定位记忆系统在哪类问题上表现薄弱。

5.3 指标体系：LLM 裁判 + 词法/语义双通道

locomo_eval.py对每个“问题-答案”对同时计算两类指标：

• LLM-as-a-Judge：使用gpt-4o-mini（可通过环境变量EVAL_MODEL覆盖），要求模型输出CORRECT或WRONG的 JSON 标签，并宽容处理“触及同一主题”的答案（时间类问题允许“last Tuesday”这类相对表达）。每次运行独立评判，最终输出平均分与标准差；
• NLP 指标：
  • 词法（lexical）：token 级 F1、ROUGE-1/2/L F 值、BLEU-1~4、METEOR；
  • 语义（semantic）：基于Qwen/Qwen3-Embedding-0.6B的余弦相似度与 BERTScore 的bert_f1；
  • 上下文与耗时：context_tokens（检索上下文 token 数）、search_duration_ms、response_duration_ms、total_duration_ms，并给出 P50/P95 分位数。

这些实现细节均可在 evaluation/scripts/locomo/locomo_eval.py 与 evaluation/scripts/locomo/locomo_metric.py 中逐一核对。

六、LongMemEval 评估：reference_time 是关键

6.1 数据集准备与运行

LongMemEval 需要从 Hugging Face 下载longmemeval_s数据集，保存为data/longmemeval/longmemeval_s.json（相对evaluation/目录）。然后运行：

# 编辑 evaluation/scripts/run_lme_eval.sh 中的配置 # 指定要使用的模型和记忆后端（例如 mem0、zep 等） evaluation/scripts/run_lme_eval.sh

脚本同样按“ingestion → search → responses → eval → metric”五段执行，默认TOPK=20、WORKERS=10。

6.2 问题日期与 reference_time 的传递机制

LongMemEval 的每个问题都带有一个问题日期（question_date），表示“这个问题是在哪一天被问出的”。评估时必须把这个日期作为“当前时间”参考，而不是脚本运行时的真实时间——否则时间推理类问题的答案判定会失真。

从 evaluation/scripts/longmemeval/lme_search.py 的源码可以看到，memos_search会把question_date作为reference_time显式传给客户端：

def memos_search(client, query, user_id, top_k, reference_time=None): results = client.search( query=query, user_id=user_id, top_k=top_k, reference_time=reference_time ) ...

并在process_user中通过reference_time=question_date完成传递。MemOS Cloud（在线版）目前不支持在搜索时提供问题日期，因此在在线平台上运行 LongMemEval 的得分可能与完全遵循规范的结果存在差异。如果希望得到可比较的数值，建议使用开源的本地 MemOS 服务器评估 LongMemEval。

七、PrefEval 评估：偏好记忆的三阶段流水线

7.1 数据集准备

PrefEval 数据集来自 Amazon Science 的 PrefEval benchmark，需要下载benchmark_dataset/filtered_inter_turns.json并保存为./data/prefeval/filtered_inter_turns.json。

7.2 运行与流水线

# 编辑 evaluation/scripts/run_prefeval_eval.sh 中的配置 # 指定要使用的模型和记忆后端（例如 mem0、zep 等） evaluation/scripts/run_prefeval_eval.sh

run_prefeval_eval.sh 是各数据集中最完整的三阶段流水线示例：

1. preprocess：prefeval_preprocess.py将原始数据整理为data/prefeval/pref_processed.jsonl；
2. add（摄入）：pref_{lib}.py add将对话写入记忆后端并生成user_id映射，--add-turn参数控制追加的上下文轮数（可选0、10、300）；
3. search（检索）：pref_{lib}.py search基于user_id检索 Top-K 记忆（TOP_K=10）；
4. response（回答）：pref_{lib}.py response基于检索结果生成答案；
5. eval（评判）：pref_eval.py对答案进行评判打分。

脚本会根据LIB自动映射到对应的实现脚本（如memos→pref_memos.py、mem0→pref_mem0.py），结果按后端隔离存放在results/prefeval/{lib}_{version}/目录。PrefEval 的WORKERS默认 20，并同时控制摄入与评判的并发度。

八、PersonaMem 评估：用户画像记忆

PersonaMem 数据集需从 Hugging Face 获取questions_32k.csv与shared_contexts_32k.jsonl，保存到data/personamem/目录。随后运行：

# 编辑 evaluation/scripts/run_pm_eval.sh 中的配置 # 指定要使用的模型和记忆后端（例如 mem0、zep 等） # 如需使用 MIRIX，请编辑 evaluation/scripts/personamem/config.yaml 中的配置 evaluation/scripts/run_pm_eval.sh

run_pm_eval.sh 针对zep后端走独立的pm_ingestion_zep.py/pm_search_zep.py分支（利用 Zep 的图谱语义），其他后端则统一走pm_ingestion.py → pm_search.py → pm_responses.py → pm_metric.py的主干流程，默认参数为WORKERS=10、TOPK=20。

九、扩展评估：OpenAI Memory 在 LoCoMo 上的手动评测

除上述基于 API 的自动化评估外，仓库还提供了针对 OpenAI Memory 的手动评估指南docs/cn/open_source/evaluation/openai_memory_locomo_eval_guide.md。由于 OpenAI Memory 没有公开 API，整个流程需要人工介入，适合作为“闭源记忆系统”对照实验的参考方案：

1. 生成记忆提取输入：运行文档提供的 Python 脚本，把 LoCoMo 每个会话格式化为带时间戳的对话历史 + 提取提示，输出为openai_inputs/下的.txt文件（如0-D9.txt）；
2. 在 ChatGPT 中逐会话提取记忆：开启 Settings → Personalization → Memory，处理前先清除已有记忆，以 GPT-4o 模型粘贴输入，确认出现“Memory updated”后，从记忆管理页把每条记忆复制到与输入同名的本地.txt文件中（每条一行）；完成一个对话后务必再次清除全部记忆，保证下一个对话从干净状态开始；
3. 合并记忆：将同一对话的所有会话记忆合并为一个conversation_0_memories.txt；
4. 自动化评估：运行evaluation/scripts/run_openai_eval.sh，其内部调用locomo_openai.py（基于合并后的记忆生成答案），随后复用 LoCoMo 的locomo_eval.py与locomo_metric.py完成打分与指标聚合。

文档特别提示两点注意事项：免费账号与 Plus 账号在上下文长度与可存记忆数量上可能存在差异；记忆提取应按会话粒度进行，一次性把整段长对话丢给模型通常效果不佳，容易忽略重要细节。

十、结果解读与对照实验建议

各数据集完成后，locomo_metric.py（LoCoMo）等指标聚合脚本会输出结构化 JSON 与 Excel 报告，核心关注点如下：

• LLM-as-a-Judge 分数（均值 ± 标准差）：主指标，--num_runs次独立评判的稳定性由标准差体现；LoCoMo 默认 3 次；
• 分类得分：LoCoMo 区分 single hop / multi hop / temporal reasoning / open domain，LongMemEval 则按问题类型分类统计，帮助定位记忆检索的短板（例如时间推理类得分偏低，往往与reference_time支持有关）；
• 词法与语义指标：作为 LLM 裁判的补充，F1/ROUGE/BLEU/METEOR 与语义相似度/BERTScore 可以反映答案的表述贴合度；
• 耗时指标：search_duration_ms、response_duration_ms的均值与 P50/P95 可用于评估记忆系统的检索时延。

如需与“不依赖记忆系统”的基线对比，仓库还提供 RAG 全上下文对照脚本 evaluation/scripts/run_rag_eval.sh，它通过locomo_rag.py把原始对话按CHUNK_SIZE切块并拼接为完整上下文直接送入 LLM 生成答案，再用同一套 eval/metric 流程打分，结果存放于results/locomo/rag-{chunk}-{num_chunks}/。这组对照可以清晰说明“加入记忆检索后相比全量上下文带来的增益（例如上下文 token 压缩与得分保持程度）”。

结语

MemOS 的记忆评估框架把“记忆能力”从定性描述变成了一套可复现、可对比、可定位问题的量化流程：以 LoCoMo、LongMemEval、PrefEval、PersonaMem 覆盖长期对话、时间敏感、偏好与画像四类记忆场景，以统一的 ingestion/search/response/eval/metric 流水线屏蔽了后端差异，并以 LLM-as-a-Judge 加词法/语义指标双通道度量答案质量。无论是验证 MemOS 自身的检索质量，还是横向对比主流记忆框架，这套框架都提供了可以直接落地的实验入口——相关实现与配置全部可以在 evaluation/ 目录中查阅与复现。

• 人工智能
• 大模型
• Agent 记忆
• AI Agent
• RAG
• 知识图谱
• dsh-plugin