构建AI长期记忆系统：图记忆网络与向量检索的混合架构实践-编程实验室

1. 项目概述：一个为AI应用构建的“记忆宫殿”

最近在折腾AI应用开发，尤其是那些需要长期记忆和复杂上下文管理的场景，比如智能客服、个性化助手或者游戏NPC。我发现一个核心痛点：如何让AI记住过去几轮、甚至几天前的对话细节，并且能根据这些“记忆”做出连贯、个性化的回应？这不仅仅是把聊天记录塞进上下文窗口那么简单。你需要一个结构化的、可查询的、能动态关联信息的系统。这就是我深度使用并拆解spellshift/realm这个项目的原因。它不是一个简单的向量数据库包装器，而是一个为大型语言模型（LLM）应用量身定制的“记忆与推理引擎”，或者说，一个数字化的“记忆宫殿”。

简单来说，Realm 的核心目标是解决LLM的“健忘症”和“上下文碎片化”问题。它允许你将对话、文档、用户信息等任何非结构化数据，转化为一个可持久化、可检索、可推理的知识网络。对于开发者而言，这意味着你可以构建出真正拥有“长期记忆”和“背景知识”的AI智能体，而不仅仅是每次对话都从零开始的聊天机器人。无论你是想做一个能记住用户偏好的购物助手，还是一个拥有丰富世界观和角色历史的游戏NPC，Realm 提供了一套现成的、高性能的底层架构。

2. 核心架构与设计哲学拆解

2.1 从“向量检索”到“图记忆网络”的演进

传统的AI记忆方案大多围绕向量数据库展开：将文本切成块，嵌入成向量，存起来，需要时做相似性搜索。这套方案对于简单的文档问答（Q&A）很有效，但它存在几个根本性局限：

信息孤立：每个文本块是独立的，块与块之间缺乏显式的语义关联。你无法直接知道“用户上周提到的出差地点”和“他今天抱怨的航班延误”是否是同一件事。
缺乏推理：检索是基于相似度，而非逻辑推理。系统很难回答“自从我们上次讨论后，项目A的进展如何？”这类需要时间线和状态追踪的问题。
上下文冗余：为了记住一段复杂信息，你可能需要将大段重复的上下文反复送入模型，浪费tokens且效率低下。

Realm 的设计哲学跳出了“向量检索”的范式，转向了“图记忆网络”。它的核心数据结构是一个属性图。在这个图中：

节点代表实体或概念，比如“用户Alice”、“产品X”、“会议议题Y”。
边代表节点之间的关系，比如“Alice购买了产品X”、“会议议题Y关联于项目Z”。
节点和边都可以拥有丰富的属性，比如用户节点的“年龄”、“偏好”，购买关系边的“时间戳”、“金额”。

这种结构天然适合表示现实世界中相互关联的知识。Realm 的工作就是自动或半自动地从非结构化文本（如对话记录）中提取出这个图，并持久化存储。当AI需要回忆或推理时，它不再是搜索相似的文本片段，而是遍历和查询这个知识图。例如，当用户问“我买过哪些数码产品？”，系统可以直接查询图中类型为“用户”的节点，找到“购买”关系，并筛选出目标节点类型为“数码产品”的所有路径，然后组织成自然语言回复。

2.2 核心组件深度解析

Realm 的架构清晰地区分了“记忆的创建”、“记忆的存储”和“记忆的使用”三个阶段，对应其几个核心组件：

1. 提取器：从文本到知识的“翻译官”这是将非结构化文本转化为结构化知识图的关键。Realm 内置并支持自定义多种提取器：

实体提取器：识别文本中的人、地、组织、产品等命名实体。它不仅仅是简单的NER，还会对同一实体的不同表述进行归一化（如“苹果公司”、“Apple Inc.”、“苹果”在上下文指公司时会被归为同一节点）。
关系提取器：识别实体之间的关系。例如，从句子“张三向李四推荐了《三体》”中，提取出(张三)-[推荐]->(李四)和(张三)-[推荐]->(《三体》)两条关系。
摘要提取器：将长文本压缩成关键事实或摘要，作为一个属性或一个新的节点附加到图中。这对于消化长篇对话或文档特别有用。
自定义提取器：你可以用任何逻辑（规则、小模型等）来定义如何从文本中提取信息。比如，从客服对话中提取“用户情绪”和“问题类别”作为节点属性。

2. 记忆库：知识图的存储与索引引擎这是Realm的心脏。它负责存储属性图数据，并为其建立高效的索引以支持复杂查询。

图存储：底层通常使用Neo4j或类似的开源图数据库。这提供了强大的图遍历和查询能力（如Cypher查询语言）。
向量索引：虽然Realm超越纯向量检索，但它并未抛弃向量。它会为节点和边的文本属性（如描述、内容）生成嵌入向量，并建立向量索引。这使得系统既能做精确的图查询，也能做模糊的语义搜索。例如，你可以先通过图查询找到“所有用户反馈”，再通过向量搜索找出其中与“登录困难”语义相似的反馈。
混合检索：Realm的真正威力在于混合检索。它可以根据查询，智能地结合图遍历和向量搜索的结果，并进行重排序，返回最相关、最符合逻辑的一组记忆节点。

3. 推理器：基于记忆的决策大脑推理器是连接记忆库和LLM的桥梁。它的任务是根据当前对话上下文和查询，从记忆库中检索出最相关的记忆子图，并组织成提示（Prompt）提供给LLM。这个过程不是简单的拼接，而是包含策略：

查询生成：将当前用户问题或对话状态，转化为对记忆库的查询语句（可能是图查询和自然语言查询的组合）。
记忆检索与组装：执行查询，获取一组相关的节点和边。然后，将这些结构化的图数据“扁平化”成一段连贯的自然语言描述，作为LLM的上下文。这里的一个关键技巧是包含关系的描述，比如“用户Alice（曾于2023-10-01表达过对科幻小说的兴趣）在2024-01-15购买了《三体》（作者：刘慈欣），并在后续对话中给出了5星好评。”
对话管理集成：推理器需要与你的对话管理框架（如LangChain, LlamaIndex的Agent）紧密集成，在每一轮对话的适当时机触发记忆的读取和更新。

2.3 为什么选择Realm？方案对比与选型思考

面对AI记忆这个问题，通常有几种方案：

方案A：简单上下文窗口：所有历史对话都塞进Prompt。优点：简单。缺点：长度有限，成本随对话平方级增长，无关信息干扰大。
方案B：向量数据库摘要：定期将对话摘要存入向量库。优点：突破了长度限制。缺点：摘要造成信息损失，缺乏结构化关联，难以进行复杂查询。
方案C：传统关系型数据库：自己设计表结构存储关键信息。优点：结构严谨，查询强大。缺点：设计复杂，难以从自由文本中自动提取和映射，灵活性差。
方案D：Realm（图记忆网络）：自动构建知识图，支持混合检索。

选型理由：对于需要深度个性化、多轮复杂交互、状态跟踪的应用，Realm的优势是决定性的。它平衡了自动化（通过提取器）和结构化（图模型）的能力。例如，在角色扮演游戏中，NPC需要记住玩家的选择、世界状态的变化、与其他角色的关系。用关系型数据库设计这些表会极其繁琐，而用Realm，你可以定义“角色”、“地点”、“事件”、“物品”等节点类型和“位于”、“拥有”、“经历过”等关系类型，后续的对话可以被自动提取并丰富这个知识图。当玩家问“我之前在这里放过一把钥匙吗？”，NPC可以通过查询(玩家)-[放置]->(钥匙)-[位于]->(当前地点)这条路径来准确回答。

注意：Realm引入了额外的复杂性。对于只需要简单Q&A或单轮对话的应用，直接使用向量数据库（如Chroma, Pinecone）可能更轻量、更合适。Realm适用于那些记忆本身就是核心价值的应用。

3. 实战：从零构建一个拥有记忆的AI助手

下面我将通过一个具体的场景——构建一个“读书俱乐部助手”——来演示Realm的完整实操流程。这个助手需要记住会员读过的书、他们的评价、讨论过的主题，并能基于这些记忆推荐新书或发起深度讨论。

3.1 环境搭建与初始化配置

首先，你需要一个图数据库后端。这里以Neo4j AuraDB（云托管版）为例，免去本地安装的麻烦。

创建Neo4j数据库：
- 访问Neo4j Aura官网，创建一个免费的AuraDB实例。创建成功后，你会获得一个连接URI（如neo4j+s://xxxx.databases.neo4j.io）和用户名密码。
- 记下这些信息，后面会用到。
安装Realm：
```
# 使用pip安装 pip install realm-recall
```
Realm的Python包名为realm-recall。

初始化Realm客户端：

from realm import Realm # 配置连接你的Neo4j实例 realm = Realm( graph_db_url="你的AuraDB URI", graph_db_username="neo4j", graph_db_password="你的密码", # 指定嵌入模型，这里使用OpenAI的text-embedding-3-small embedding_model="text-embedding-3-small", openai_api_key="你的OpenAI API Key" )

这里我选择了OpenAI的嵌入模型，因为它质量和稳定性都很好。你也可以配置使用本地的开源模型（如BAAI/bge-small-en），但需要额外设置本地嵌入服务。

3.2 定义领域模型与提取规则

在投喂数据之前，我们必须先定义“记忆”的结构。对于读书俱乐部，我们关心哪些实体和关系？

# 定义节点类型（记忆类型） node_types = { "Member": "读书俱乐部的会员", "Book": "书籍", "Author": "作者", "Genre": "文学体裁", "DiscussionTopic": "讨论过的主题", "Meeting": "俱乐部聚会", } # 定义关系类型 relationship_types = { "READ": "会员阅读了某本书", "REVIEWED": "会员评价了某本书（边属性可包含评分、评论）", "LIKES_GENRE": "会员喜欢某个体裁", "WRITTEN_BY": "书籍由某位作者所著", "BELONGS_TO_GENRE": "书籍属于某个体裁", "DISCUSSED_IN": "主题在某次聚会中被讨论", "MENTIONED_IN": "书籍/作者在讨论中被提及", } # 定义属性（这里以Book节点为例，其他类似） # 属性可以附加在节点和边上 book_properties = { "title": "string", "isbn": "string", "publication_year": "int", "summary": "string", # 这个属性适合做向量嵌入 }

接下来，我们需要告诉Realm如何从对话中提取这些信息。我们可以组合使用内置提取器和自定义逻辑。

from realm.extractors import EntityExtractor, RelationExtractor # 1. 初始化实体提取器 - 使用一个强大的开源模型，如spaCy的en_core_web_lg # 你需要先 pip install spacy && python -m spacy download en_core_web_lg import spacy nlp = spacy.load("en_core_web_lg") def custom_entity_extractor(text): doc = nlp(text) entities = [] for ent in doc.ents: # 将spaCy的实体类型映射到我们的节点类型 if ent.label_ in ["PERSON"]: node_type = "Member" # 简单假设，实际需要更复杂的消歧逻辑 elif ent.label_ in ["WORK_OF_ART"]: node_type = "Book" elif ent.label_ in ["ORG"]: node_type = "Author" # 可能是出版社，这里简化处理 else: continue entities.append({ "text": ent.text, "type": node_type, "start_char": ent.start_char, "end_char": ent.end_char }) return entities # 2. 初始化关系提取器 - 这里用一个基于规则的简单示例，真实场景建议用微调的小模型 def custom_relation_extractor(text, entities): relations = [] words = text.lower().split() # 非常简单的规则：如果句子中有“read”和书名人名，则建立READ关系 if "read" in words: book_ents = [e for e in entities if e["type"] == "Book"] member_ents = [e for e in entities if e["type"] == "Member"] for member in member_ents: for book in book_ents: relations.append({ "source": member["text"], "source_type": member["type"], "target": book["text"], "target_type": book["type"], "relation": "READ", "confidence": 0.7 # 规则提取的置信度 }) return relations # 将提取器注册到Realm realm.register_extractor("entity", custom_entity_extractor) realm.register_extractor("relation", custom_relation_extractor)

实操心得：提取器的质量直接决定了记忆图的准确性。对于生产环境，不要依赖过于简单的规则。建议：
对于实体识别，可以使用更专业的NER API（如Azure Language Service）或微调一个领域模型。
对于关系提取，这是一个NLP中的难题。可以尝试使用像REBEL这样的预训练关系提取模型，或者用少量标注数据在LLM（如GPT-4）上做few-shot提取。Realm的灵活性在于，你可以将任何提取逻辑（包括调用LLM API）封装成一个提取器函数。

3.3 注入记忆：处理历史对话与资料

假设我们有一段读书俱乐部的历史聊天记录（book_club_chat.txt）和一份会员信息表（members.csv）。

import pandas as pd # 1. 处理结构化数据：会员信息 df_members = pd.read_csv("members.csv") for _, row in df_members.iterrows(): member_id = row["member_id"] # 创建Member节点，属性包括名字、加入日期等 realm.create_memory( content=f"Member {row['name']} joined in {row['join_date']}. Favorite genres include {row['fav_genres']}.", memory_type="Member", metadata={"name": row["name"], "member_id": member_id, "join_date": row["join_date"]}, # 关键：为这个节点生成一个唯一的外部ID，方便后续关联 external_id=f"member_{member_id}" ) # 2. 处理非结构化数据：聊天记录 with open("book_club_chat.txt", "r") as f: chat_log = f.read() # 将长聊天记录按对话轮次或段落分割 # 这里简单按行分割，实际可按空行或发言人分割 chat_segments = chat_log.split('\n\n') for segment in chat_segments: if segment.strip(): # 使用Realm处理这段文本，它会自动调用我们注册的提取器 # `commit=True` 表示立即将提取出的实体和关系写入图数据库 processed_segment = realm.process_text( text=segment, source="book_club_chat", commit=True, # 可以附加一些会话元数据，如时间戳、发言人 metadata={"timestamp": "2024-01-15T20:00:00"} ) print(f"Processed segment, extracted {len(processed_segment.entities)} entities and {len(processed_segment.relations)} relations.")

realm.process_text是这个流程的核心。它内部会：

为输入的文本段本身创建一个“文本节点”或“事件节点”。
运行所有注册的提取器，识别实体和关系。
将识别出的实体创建或合并到对应的节点（例如，如果“Alice”这个会员已存在，则更新其属性；如果不存在，则创建新节点）。
在实体节点之间创建关系边。
（如果commit=True）将所有变更持久化到图数据库。

3.4 查询与推理：让助手“回忆”并“思考”

现在，我们的记忆图已经初步建立。当新对话发生时，助手需要动态地查询相关记忆。

def generate_response_with_memory(user_query, conversation_history): """ 结合记忆生成助手的回复。 """ # 步骤1：基于当前查询和最近对话历史，生成一个对记忆库的搜索查询 # 这里可以简单地用用户查询本身，也可以用一个LLM来优化查询 search_query = user_query # 简化处理 # 步骤2：从Realm中检索相关记忆 # 使用混合检索：既做基于图的精确查找，也做基于向量的语义搜索 related_memories = realm.recall( query=search_query, memory_types=["Member", "Book", "Author", "DiscussionTopic"], # 限定在哪些类型的记忆中搜索 limit=10, # 返回最多10个相关记忆节点 hybrid_search=True, # 开启混合检索 graph_traversal_depth=2 # 在图遍历时，从直接相关节点再向外探索2层关系 ) # 步骤3：将检索到的结构化记忆组织成LLM能理解的提示上下文 memory_context = "" for memory in related_memories: # memory 是一个节点对象，包含其属性、类型和与其他节点的关系摘要 mem_text = f"- [{memory.type}] {memory.content}" # 可以添加其关键关系，例如“该会员读过X书” if memory.relations: rel_summary = "; ".join([f"{r.relation_type} -> {r.target_memory.content[:50]}..." for r in memory.relations[:2]]) mem_text += f" (关联：{rel_summary})" memory_context += mem_text + "\n" # 步骤4：构建最终Prompt，调用LLM生成回复 prompt = f""" 你是一个读书俱乐部助手，拥有以下关于俱乐部会员和书籍的记忆： {memory_context} 当前的对话历史： {conversation_history} 用户的最新问题：{user_query} 请基于你的记忆和对话历史，友好、专业地回答用户的问题。如果记忆中有相关信息，请利用它们使回答更个性化、更准确。 回答： """ # 调用OpenAI API (示例) import openai client = openai.OpenAI(api_key="your-api-key") response = client.chat.completions.create( model="gpt-4-turbo-preview", messages=[{"role": "user", "content": prompt}], temperature=0.7, ) assistant_reply = response.choices[0].message.content # 步骤5（可选但重要）：将本轮有信息量的对话内容，作为新记忆存入Realm # 我们可以判断本轮对话是否包含了新的、值得记录的事实 if "read" in user_query.lower() or "recommend" in user_query.lower() or "think about" in user_query.lower(): # 处理本轮对话，提取新记忆 realm.process_text( text=f"User asked: {user_query}. Assistant replied: {assistant_reply}", source="current_session", commit=True, metadata={"interaction_type": "Q&A"} ) return assistant_reply # 模拟一次对话 history = "User: Hi, I'm Alice.\nAssistant: Hello Alice! Welcome back to the book club." user_question = "What sci-fi books has Bob read recently? I'm looking for recommendations." reply = generate_response_with_memory(user_question, history) print(reply)

在这个例子中，当用户问“Bob最近读了哪些科幻书？”，realm.recall会：

通过向量搜索，找到与“sci-fi books Bob read”语义相关的节点（可能是Bob的Member节点、一些科幻书节点、包含“read”关键词的边）。
通过图遍历，从“Bob”这个Member节点出发，沿着“READ”关系边，找到所有Book节点，再过滤出那些连接着“Genre”节点且属性为“Science Fiction”的书。
将两种检索方式的结果融合、去重、排序，返回最相关的10个记忆节点（可能包括Bob本人、他读过的科幻书、这些书的作者等）。
LLM根据这些精确的记忆，就能生成如下的个性化回复：“根据我们的记录，Bob最近刚读完《Project Hail Mary》并给了五星好评，他去年也很喜欢《The Three-Body Problem》系列。如果你喜欢硬科幻，他读过的《Blindsight》可能也会合你胃口。”

4. 性能调优、问题排查与进阶技巧

4.1 检索质量优化：解决“找不到”或“找不准”

问题1：检索结果不相关。

原因：嵌入模型不匹配或提取器质量差，导致节点向量表示不准；图查询条件太宽泛。
解决方案：
- 嵌入模型：对于特定领域（如医学、法律），使用在该领域语料上微调过的嵌入模型（如BAAI/bge-large-zh对于中文）。可以通过在少量标注数据上测试不同模型的检索精度来选择。
- 查询重写：不要直接将用户问题作为搜索查询。用一个轻量级LLM（如GPT-3.5-turbo）将用户问题重写为针对记忆库的优化查询。例如，将“Bob喜欢什么书？”重写为“查找Member节点名为Bob，并通过READ关系连接的Book节点，按时间戳排序”。
- 调整混合权重：realm.recall的hybrid_search_alpha参数（通常在0到1之间）控制向量搜索和图搜索的权重。偏向图搜索（alpha接近0）更精确但需要好的图结构；偏向向量搜索（alpha接近1）更灵活但可能返回无关项。需要根据你的数据特点进行调整。

问题2：重要记忆被遗漏。

原因：limit参数设置太小；关系深度不够；节点内容太简短，缺乏语义信息。
解决方案：
- 增加检索宽度与深度：适当提高limit（如15-20）和graph_traversal_depth（如3）。注意，深度太大会引入噪声并增加查询时间。
- 丰富节点内容：在创建记忆时，content字段不要只放名字。尽量用描述性句子。例如，Book节点的content可以是“《三体》是刘慈欣创作的硬科幻小说，讲述了地球人类文明与三体文明的信息交流、生死搏杀及两个文明在宇宙中的兴衰历程。” 这样，即使图关系没有直接连接，通过向量搜索也能找到。
- 使用记忆链：对于复杂事件，可以创建“摘要节点”。例如，一次长达2小时的俱乐部讨论，可以提取多个“讨论主题”节点，并创建一个“Meeting”节点作为总结，链接到所有这些主题节点。检索时，先找到Meeting节点，再遍历到所有相关主题。

4.2 图数据库性能与可扩展性

问题：随着数据量增长，查询变慢。

原因：Neo4j未优化索引；复杂查询遍历过多路径。
解决方案：
- 索引策略：确保为经常用于查询条件的节点属性（如name,timestamp）和边属性创建索引。在Neo4j中：CREATE INDEX ON :Member(name)。
- 向量索引：Realm会管理向量索引，但需确保底层向量数据库（如pgvector if using PostgreSQL）的索引配置得当。
- 查询优化：使用Neo4j的EXPLAIN或PROFILE命令分析你的图查询，查看是否进行了全节点扫描。优化查询模式，尽量从具有索引的属性开始查找。
- 分片与归档：对于时间线明显的应用（如聊天记录），可以考虑按时间分片存储记忆图。将非常旧的、不常访问的记忆归档到冷存储，只保留热数据在活动图中。

4.3 记忆的维护与“遗忘”机制

问题：记忆中存在错误或过时信息。

挑战：AI提取的信息可能有误；用户偏好会改变。
解决方案：
- 置信度与人工审核：在提取器中为每个提取出的实体和关系附加一个confidence分数。在管理后台，可以设置阈值，低置信度的提取需要人工审核确认后才写入记忆库。
- 记忆更新与合并：Realm的create_memory在遇到相同external_id的节点时会执行更新（upsert）。设计好你的外部ID逻辑（如user_123,book_9787536692930），使得同一实体的新信息能合并到原有节点上，而不是创建重复节点。
- 实现软删除与衰减：可以为节点和边添加valid_until或strength属性。通过定期任务衰减strength，或标记过期的信息为无效。在检索时，过滤掉无效或强度低于阈值的内存。这模拟了人类的“遗忘曲线”。
- 提供用户修正接口：在对话中，如果助手基于错误记忆做出了回答，应提供让用户纠正的途径。例如：“我记得您喜欢科幻小说，对吗？（如果不对，请告诉我您喜欢的类型）”。用户的纠正反馈可以直接用来更新对应的记忆节点。

4.4 与现有AI开发框架集成

Realm本身是一个相对底层的引擎。在实际项目中，你通常会将其与LangChain、LlamaIndex或AutoGen等框架结合。

与LangChain集成示例：

from langchain.agents import Tool, AgentExecutor from langchain.memory import ConversationBufferMemory from langchain.agents import initialize_agent from langchain.llms import OpenAI # 将Realm的recall功能包装成一个LangChain Tool class RealmRetrievalTool(Tool): name = "Club Memory" description = "Useful for recalling facts about book club members, books they've read, and past discussions." def _run(self, query: str) -> str: memories = realm.recall(query, limit=5, hybrid_search=True) return "\n".join([m.content for m in memories]) async def _arun(self, query: str) -> str: # 异步实现 pass # 创建Agent llm = OpenAI(temperature=0) tools = [RealmRetrievalTool()] memory = ConversationBufferMemory(memory_key="chat_history") agent = initialize_agent(tools, llm, agent="conversational-react-description", memory=memory, verbose=True) # 现在，Agent在对话中可以主动调用“Club Memory”工具来获取记忆 agent.run("What kind of books does Alice usually enjoy?")

这种集成方式让Realm成为了AI智能体的一个“长期记忆”工具，智能体可以根据对话需要，自主决定何时去查询记忆。

5. 总结与展望：构建真正有“灵魂”的AI体验

使用spellshift/realm这套系统几个月下来，我的核心体会是：它为AI应用从“工具”迈向“伙伴”提供了最关键的基础设施——连续、结构化的记忆。它解决的不仅仅是技术上的“上下文长度”问题，更是体验上的“连贯性”和“个性化”问题。

一个让我印象深刻的测试案例是，我构建了一个基于Realm的D&D（龙与地下城）游戏主持人助手。我将整个游戏世界的设定、历史事件、NPC背景、玩家过往的选择都作为记忆注入。当玩家在第三次会话中突然问起：“我们之前在黑森林里放过那个地精俘虏，它后来怎么样了？” 助手能够准确地从记忆图中找到“黑森林”、“地精俘虏”、“释放”这些节点和关系，并推理出后续可能发生的事件（基于预设的世界规则），生成一个合乎逻辑的延续剧情。这种体验是简单的聊天上下文或向量搜索完全无法提供的。

当然，这套系统引入的复杂度不容忽视。你需要精心设计领域模型、投入精力优化提取器、管理和维护一个图数据库。它可能不适合所有项目，但对于那些记忆即价值的应用——比如高级客服、个性化教育导师、复杂游戏NPC、企业知识管家——Realm所带来的能力提升是质的飞跃。

最后一个小技巧：在项目初期，不要试图一次性构建完美的记忆图。可以从最简单的实体识别开始，先让系统能记住“谁”和“什么”。然后逐步增加关系提取、属性丰富。采用迭代的方式，结合真实用户的交互数据来不断修正和扩展你的记忆模型，这样能更有效地逼近那个让AI显得真正“有记性、有常识”的甜蜜点。