标题

把 RAG 做成“个人记忆库”：开源项目 Mneme 项目解析

摘要

如果你已经看腻了“上传 PDF + 提问”的 RAG Demo，那这个项目可能会让你眼前一亮。Mneme 并不是一个只做检索问答的简单示例，而是一个围绕用户、知识库、文档、记忆条目、画像分析来构建的后端系统。它试图解决的不是“一次性回答问题”，而是让系统随着内容积累，逐步形成对用户的长期理解。项目当前已经打通了注册/登录、默认知识库创建、文档上传、文档切分与索引、向量检索、基于知识库的 RAG 问答这条主链路，同时还预留了画像、成长分析、建议生成、陪伴式回复等扩展能力。(GitHub)

---

正文

一、项目简介：Mneme 到底在做什么？

最近看了一个 GitHub 上的开源项目 Mneme，我觉得它和很多常见 RAG 项目最大的区别在于：它不是把“知识库问答”当成终点，而是把“个人长期记忆沉淀”当成目标。

项目 README 对它的定位非常明确：这是一个面向个人长期内容沉淀的记忆型 RAG 后端。它想承接的内容包括个人写作、笔记、复盘、经历等非结构化材料，然后逐步把这些内容转化成一个可检索、可分析、可追踪的“个人记忆库”。(GitHub)

换句话说，Mneme 不是那种“传一份文档，回答几个问题”就结束的项目，它更像是一个长期知识资产系统的后端雏形。这个思路其实很有意思，因为真正有价值的 RAG，往往不是临时问答，而是让系统在长期交互中越来越懂你。(GitHub)

---

二、这个项目和普通 RAG Demo 的区别

README 里提到，Mneme 相比普通问答型 RAG，更强调四件事：

1. 用户域与知识库域隔离
   不同用户、不同知识库的数据边界明确。

2. 检索优先
   先索引、再召回、后生成，而不是粗暴地把长文本直接塞进上下文。

3. 长期沉淀
   不只是保存原文，还会尝试沉淀为记忆条目、画像和成长线索。

4. 工程化后端结构
   不只是模型调用脚本，而是包含数据库模型、鉴权、迁移、容器化、向量库接入的一整套后端体系。(GitHub)

这四点其实非常关键。很多 RAG 项目都停留在“功能能跑”，但 Mneme 明显想往“系统能演进”这个方向做。尤其是“用户—知识库—记忆—分析”这条链路，一看就不是玩具项目的思路。(GitHub)

---

三、项目目前已经实现了什么？

从 README 来看，Mneme 当前已经完成了一条比较完整的主链路：

注册 / 登录 → 创建默认知识库 → 上传文档 → 文档切分与索引 → 向量检索 → 基于知识库的 RAG 问答。(GitHub)

另外，已经落地或可用的能力包括：

• 用户注册、登录、获取当前用户

• 默认知识库自动创建

• 用户知识库管理

• 文档上传与本地落盘

• 文档解析、文本切分、Chunk 入库

• 基于 Milvus 的向量索引与检索

• 基于知识库的 RAG 问答

• 记忆库视图查询

• 个人画像 / 成长报告生成接口(GitHub)

不过项目作者也写得很实在：记忆条目自动抽取还没有完全接入主索引流程，advice 和 companion 相关接口也还在打磨，聊天会话与任务记录模型虽然预留了，但还没形成完整业务闭环。
所以这不是一个“所有能力都已经成熟”的项目，而是一个主链路可用、扩展方向清晰的工程化后端。(GitHub)

---

四、技术栈一眼看懂

这个项目的技术栈比较典型，但选型比较务实：

1）Web / API 层

• FastAPI

• Pydantic v2

• Uvicorn

2）数据层

• PostgreSQL

• SQLAlchemy 2.x Async

• asyncpg

• Alembic

3）RAG / AI 能力

• LangChain

• Milvus

• langchain-milvus

• sentence-transformers/all-mpnet-base-v2 作为默认 Embedding 模型

• DashScope Compatible API / Qwen 作为默认大模型接入

• PyPDF 用于 PDF 解析

4）鉴权与安全

• JWT Bearer Token

• python-jose

• passlib + bcrypt

5）部署方式

• Docker / Docker Compose

• Milvus Standalone 依赖 etcd、MinIO(GitHub)

这套技术栈的好处是：没有过度炫技，基本都是当前 Python 后端和 RAG 工程里比较稳定、主流、可维护的方案。
如果你自己也想做一个 RAG 后端，这套选型是可以直接参考的。(GitHub)

---

五、从数据模型看，这个项目为什么叫“记忆型 RAG”？

我觉得 Mneme 最有意思的地方，不在于用了 FastAPI 还是 Milvus，而在于它的数据建模方式。

README 中列出的核心对象有：

• User

• KnowledgeBase

• Document

• Chunk

• MemoryEntry

• ChatSession（预留）

• TaskRecord（预留）(GitHub)

这说明作者不是把系统简单理解成“文档 + 向量库 + LLM”，而是明确区分了：

• 谁在用系统：User

• 知识沉淀在哪个空间：KnowledgeBase

• 原始资料是什么：Document

• 检索粒度是什么：Chunk

• 长期提炼后的结果是什么：MemoryEntry

这个设计非常像从“文档检索系统”往“长期记忆系统”演进的路线。
我的理解是：Chunk 解决的是召回问题，MemoryEntry 解决的是沉淀问题。 前者让模型能找到内容，后者让系统能逐渐理解内容。这个思路，比单纯做一个问答接口更有扩展空间。这个判断是基于 README 对核心对象和数据流的描述做出的工程层面推断。(GitHub)

---

六、项目主流程怎么跑起来？

按照 README 的说明，本地启动流程并不复杂：

1. 安装依赖

pip install -r requirements.txt

2. 配置环境变量

复制 .env-example 为 .env，然后补充数据库、JWT、LLM、Milvus 等配置。

3. 准备 PostgreSQL

确保 DATABASE_URL 可用。

4. 执行迁移

alembic upgrade head

5. 启动服务

uvicorn main:app --reload

默认访问地址：

• API：http://127.0.0.1:8000

• Swagger：http://127.0.0.1:8000/docs (GitHub)

如果你不想本地手动拉起数据库和向量库，项目也给了完整的 Docker 部署文件，可以直接：

docker compose up --build

默认会启动 FastAPI 应用、PostgreSQL、Milvus，以及 Milvus 依赖的 etcd 和 MinIO。容器启动时还会自动执行 alembic upgrade head。(GitHub)

这一点很加分，因为很多开源项目 README 写得挺热闹，真正跑起来一堆坑；Mneme 至少在部署说明上是比较完整的。这个评价基于 README 中列出的本地与 Docker 启动步骤。(GitHub)

---

七、有哪些核心接口值得关注？

如果你想快速理解这个项目的业务边界，直接看接口就够了。

认证相关

• POST /auth/register

• POST /auth/login

• GET /auth/me

用户与知识库

• GET /users

• POST /users/{user_id}/knowledge-bases

• GET /users/{user_id}/knowledge-bases

文档

• POST /kb/documents/upload

• GET /kb/documents

• POST /kb/documents/{document_id}/index

RAG / 记忆 / 分析

• POST /kb/chat/query

• GET /memory/knowledge-bases/{knowledge_base_id}/library

• GET /memory/documents/{document_id}/library

• GET /profile/knowledge-bases/{knowledge_base_id}

• GET /analysis/knowledge-bases/{knowledge_base_id}/growth

开发中能力

• POST /advice/knowledge-bases/{knowledge_base_id}

• POST /companion/knowledge-bases/{knowledge_base_id}/reply (GitHub)

从接口命名就能看出来，作者已经不满足于“问答”本身，而是把系统扩展到了记忆库查看、画像生成、成长报告这样的方向。这就意味着，Mneme 更像一个“个人知识与成长系统”的底座，而不是一个单点功能 API。(GitHub)

---

八、目录结构也很有参考价值

README 给出的目录结构如下：

• conf/：配置、数据库连接

• crud/：数据访问层

• models/：SQLAlchemy 模型

• routers/：FastAPI 路由

• schemas/：Pydantic 请求/响应模型

• utils/：RAG、鉴权、画像、分析等核心逻辑

• alembic/：数据库迁移

• storage/：本地存储目录

• main.py：应用入口(GitHub)

这套分层非常标准，但正因为标准，所以适合学习。
对于想练手 FastAPI + RAG 工程的人来说，这种目录结构比那种“所有逻辑全塞一个 app.py”强太多了。至少后续你想继续接入聊天会话、任务追踪、多知识库、多租户逻辑时，代码不会第一时间崩掉。这个判断是结合 README 公开的目录结构做出的工程经验分析。(GitHub)

---

九、Mneme 适合什么人？不适合什么人？

README 里写得也很明确，Mneme 更适合这几类需求：

• 想沉淀个人博客、笔记、复盘、文章

• 想基于长期材料做检索与问答

• 想在知识库基础上做画像、阶段分析与成长总结

• 想搭建一个偏“个人记忆库”方向的 RAG 后端(GitHub)

但如果你只是想做一个最轻量的 FAQ Demo，那这个项目可能会显得有点重。因为它从一开始就不是按“最小演示系统”来设计的，而是按“未来要继续长”的思路来搭骨架。(GitHub)

---

十、我对这个项目的几点评价

优点一：方向比普通 RAG Demo 更有想象力

多数项目都在卷召回、卷 prompt、卷模型，但 Mneme 在尝试回答一个更重要的问题：RAG 能不能成为个人长期记忆系统的一部分？
这个视角本身就比“做一个聊天问答接口”更有价值。(GitHub)

优点二：工程骨架比较完整

项目已经包含认证、数据库建模、迁移、容器化、向量库接入、API 分层等内容，不是那种只能截图演示的 Demo。(GitHub)

优点三：演进路线很清晰

从文档索引、RAG 问答，到记忆库、画像、成长分析，再到 advice、companion，这条路线是连贯的。即便某些能力还在开发中，也能看出作者在想什么。(GitHub)

目前的不足

项目作者也明确说明了，一些增强能力还没有完全闭环，比如 MemoryEntry 自动抽取还没完全融入主索引流程，建议生成和陪伴式回复接口也还在完善。
所以如果你现在把它当成一个“可二开、可学习、可扩展”的后端骨架，会比较合适；如果你期待的是“开箱即用的成熟产品”，那还差一些火候。(GitHub)

---

十一、总结

如果让我用一句话概括 Mneme，我会说：

它不是在做一个简单的 RAG Demo，而是在尝试做一个面向长期内容沉淀的“个人记忆型 RAG 后端”。 目前项目已经完成了认证、知识库、文档上传索引与问答主链路，并在画像、成长分析、建议和陪伴能力上留出了扩展接口和数据模型。(GitHub)

这类项目最大的价值，不一定是你拿来直接上线，而是它提供了一种值得参考的系统设计思路：

• RAG 不只是问答

• 知识库不只是文档堆积

• 用户长期内容，是可以被组织成“记忆”的

如果你最近也在做知识库、个人 AI 助手、长期记忆系统、或者想用 FastAPI + PostgreSQL + Milvus 搭一个更像样的 RAG 后端，我觉得 Mneme 值得看看。(GitHub)