你的分身Living Knowledge MVP 设计方案
Living Knowledge MVP 设计方案
1. 项目定位
Living Knowledge（活知识系统）
一个不会要求用户主动整理资料，而是能够自动理解、关联、记忆并帮助用户检索个人知识的 AI 知识系统。
核心理念：
知识不是静态文件，而是一个会成长、会演化、可追溯的知识生命体。
与传统 RAG 的区别：
传统 RAG：
文件
↓
切分 Chunk
↓
Embedding
↓
向量检索
↓
回答
Living Knowledge：
文件
↓
理解内容
↓
建立知识关系
↓
形成长期记忆
↓
智能检索
↓
回答 + 原始引用
2. 核心目标
用户不需要手动：
- 创建目录
- 分类文件
- 添加标签
- 编写摘要
- 整理知识关系
用户只需要：
告诉系统文件路径
或者
把资料放入指定目录
系统自动完成：
- 文件识别
- 内容理解
- 摘要生成
- 标签生成
- 实体抽取
- 知识关系建立
- 向量索引
- 智能问答
3. 核心设计思想
3.1 知识库不是文件仓库
Living Knowledge 不应该复制用户文件。
它应该类似 Google：
Google 不保存整个互联网，而是保存互联网索引。
Living Knowledge：
不拥有知识。
它拥有：
用户知识世界的索引。
4. 整体架构
用户文件系统
|
|
File Index Scanner
|
+----------------+----------------+
| |
v v
文件元数据管理 内容理解引擎
| |
| |
v v
Knowledge Store Knowledge Graph
|
|
v
Vector Index
用户问题
|
v
Retrieval Engine
|
+------------+-------------+
| |
v v
LLM回答 文件引用
5. 文件索引系统
5.1 文件不直接存储
建立 File Registry。
例如：
数据库：
knowledge_file
CREATE TABLE knowledge_file (
id BIGINT PRIMARY KEY,
file_path TEXT NOT NULL,
file_name VARCHAR(255),
file_hash VARCHAR(64),
file_size BIGINT,
mime_type VARCHAR(100),
created_time DATETIME,
modified_time DATETIME,
last_scan_time DATETIME
);
示例：
/home/user/docs/spring-ai.pdf
hash:
a83f9b7cxxxx
6. Hash 的作用
6.1 文件去重
例如：
spring-ai.pdf
spring-ai-copy.pdf
hash 相同：
认为是同一个知识源。
6.2 文件变化检测
旧版本：
risk_rule.docx
hash=A123
新版本：
risk_rule.docx
hash=B456
系统知道：
文件内容发生变化，需要重新分析。
6.3 知识版本管理
例如：
Spring AI笔记
v1
↓
v2
↓
v3
知识图谱可以记录：
Spring AI
has_version
Spring AI v3
7. 知识图谱设计
文件本身也是知识节点。
不是只有概念。
例如：
文件：
spring-ai.pdf
AI分析：
发现：
Spring AI
LangGraph
RAG
Vector Store
建立：
RAG
|
supports
|
Spring AI
|
mentions
|
spring-ai.pdf
8. 第一版知识节点设计
不要一开始设计复杂图谱。
MVP 只需要：
File
文件节点：
spring-ai.pdf
Concept
概念：
RAG
Agent
Embedding
Technology
技术：
Spring AI
LangGraph
OpenClaw
Organization
组织：
Microsoft
OpenAI
Google
关系：
FILE
|
mentions
|
CONCEPT
CONCEPT
|
related_to
|
CONCEPT
FILE
|
derived_from
|
FILE
9. Vector 存储设计
不要只保存文本。
Chunk 必须带引用信息。
例如：
{
"id":"chunk_001",
"text":
"Spring AI提供VectorStore接口",
"embedding":[],
"metadata":{
"file_id":123,
"file_path":
"/docs/spring-ai.pdf",
"page":5,
"section":"VectorStore"
}
}
这样回答时可以追溯来源。
10. 智能回答流程
不要：
问题
↓
Vector Search
↓
LLM
应该：
用户问题
↓
Query Understanding
↓
多路检索
|
|
+-- Vector Search
|
|
+-- Knowledge Graph Search
|
|
+-- Metadata Search
|
|
+-- Memory Search
↓
结果融合
↓
LLM回答
↓
回答 + 文件引用
11. 示例
用户：
Spring AI 如何实现 RAG？
系统：
回答：
Spring AI通过VectorStore抽象实现RAG流程。
主要包括：
1. Document Loader
2. Embedding
3. Similarity Search
来源：
[1]
spring-ai.pdf
路径：
~/knowledge/java/spring-ai.pdf
页码：
12
[2]
rag-design.md
路径：
~/notes/rag-design.md
12. MVP 功能范围
V0.1 文件理解
支持：
- Word
- Markdown
- TXT
能力：
- 文件扫描
- Hash检测
- 文本解析
- 自动摘要
- 自动标签
V0.2 知识连接
增加：
- 实体抽取
- 关系抽取
- 简单知识图谱
例如：
Spring AI
related_to
LangGraph
V0.3 智能问答
支持：
- 自然语言查询
- 多来源回答
- 文件引用
13. 技术选型
推荐：
后端
Python
FastAPI
原因：
AI生态成熟。
LLM
Gemini API
负责：
- 摘要
- 实体抽取
- 关系分析
- 问答
Embedding
第一阶段：
Gemini Embedding
或者：
BGE 系列模型
Vector Database
第一阶段：
Chroma
未来：
Qdrant
Knowledge Graph
第一阶段：
NetworkX
未来：
Neo4j / Memgraph
数据库
SQLite
保存：
- 文件信息
- Metadata
- 任务状态
14. 推荐目录结构
living-knowledge/
├── api/
├── ingestion/
├── parser/
├── embedding/
├── graph/
├── memory/
├── retriever/
├── planner/
├── scheduler/
├── ui/
└── data/
├── documents/
├── vectors/
├── graph/
└── metadata/
15. 第一版不要做
MVP 阶段不要加入：
- 多 Agent
- MCP
- Workflow Engine
- 浏览器自动操作
- 插件市场
- Neo4j
- 多模型调度
- 企业权限系统
先验证核心价值：
用户是否愿意持续把资料交给系统。
16. 长期演进方向
未来：
Living Knowledge
|
+---------------+---------------+
| | |
Knowledge Memory Agent
Graph Layer Runtime
|
|
Personal AI Assistant
能力：
- 自动整理资料
- 自动发现知识关系
- 自动提醒关联内容
- 自动生成学习路径
- 根据历史知识辅助决策
17. 产品成功标准
不是：
支持多少模型。
不是：
用了多少 AI 技术。
真正成功标准：
用户连续使用 30 天后，不再主动整理文件，而是习惯把所有新资料直接丢给 Living Knowledge。
当系统开始理解用户长期积累的知识，并且能够在需要的时候找到正确的信息，它才真正成为一个“会成长的大脑”。
暂无评论，快来抢沙发吧~