做商品推荐时，我们面对的是一个经典问题：商品很多，但用户在当前时刻真正感兴趣的只有少数几个。系统需要从海量商品中找出候选，过滤无效内容，按用户兴趣排序，并通过后续点击和购买持续修正结果。

RAG 和 Agent 长期记忆看起来属于大模型应用，但从工程结构上看，它们与推荐系统高度相似：区别只在于推荐的对象和优化目标。

• 商品推荐推荐的是商品，目标通常是点击、购买和长期留存。
• RAG 推荐的是能够支持回答的资料证据，目标是相关、正确、可追溯。
• 长期记忆推荐的是当前回答真正需要用到的用户偏好和稳定事实，目标是回答一致、准确且不冒犯用户隐私。

因此，推荐系统的“数据采集、召回、过滤、排序、反馈闭环”是一套可迁移的工程范式，而不是某一种只能用于电商的算法。

1. 一个统一的视角：从候选集合中找最该返回的信息

三类系统都可以抽象为同一个问题：给定当前请求和历史上下文，从一个很大的候选集合中找出少量最有价值的信息。

对应关系如下：

这里的关键不是“它们都使用向量数据库”。向量检索只是召回手段之一；真正相同的是，系统都要解决候选集过大、结果不全相同、用户意图会变化，以及结果需要被持续评估的问题。

2. 商品推荐：这套范式最成熟的形态

电商商品池往往有百万级甚至更大，不可能让一个模型对所有商品逐一精算。因此生产系统通常是多阶段的。

1. 采集行为和商品信息：记录曝光、点击、收藏、加购、购买、退款；同时维护商品类目、价格、品牌、库存和促销信息。
2. 多路召回：快速找出几百到几千个候选商品。例如ItemCF根据“看过或买过 A 的用户也看过 B”召回相似商品；也可以根据用户最近的行为序列、类目、关键词或商品向量召回。
3. 过滤和粗排：去掉无库存、下架、不可配送、重复或用户明确不感兴趣的商品。
4. 精排和重排：预测点击、购买或预期成交金额，再控制多样性、新品曝光、价格范围和运营约束。
5. 反馈闭环：新的点击、购买和退款进入日志，用于更新相似关系、特征和排序模型。

一个很具体的行业场景是商品详情页的“看了这件商品的人还看了什么”或“买了 A 的人也买了 B”。用户看了一双跑鞋，系统会从与跑鞋共同浏览、共同加购或共同购买的商品中召回运动袜、鞋垫、速干衣等候选，再结合价格区间、库存和用户近期行为排序，而不是只靠“它们都属于运动类”这个粗糙规则。

ItemCF可以被理解为在“用户—商品”二部图上利用共同邻居找相似物品。它不是知识图谱的同义词：用户—商品交互图记录的是行为关系；知识图谱记录的则是品牌、类目、作者、概念等更显式的语义关系。两者都能帮助推荐，但不是同一种数据结构。

3. RAG：把“推荐商品”替换成“推荐证据”

在知识工作台中，用户并不希望系统随便给出一段看起来合理的答案，而是希望回答能依据自己选择的资料，并且能够追溯来源。因此 RAG 的候选不是商品，而是资料里的证据片段。

以 YouDaoNoteLM 的资料问答流程为例，完整链路可以写成：

这里能看到推荐范式的直接迁移：

• 资料解析和分块，相当于商品系统里的商品建模与特征建设。
• 关键词检索、稠密向量检索、混合检索，相当于多路召回。
• sourceIDs 过滤、权限校验、父子块去重和 TopK 截断，相当于候选过滤。
• RRF 融合和重排，相当于精排。
• 父块回溯与引用收集，则是 RAG 相比商品推荐多出来的“证据恢复”步骤。

真实项目场景：基于用户选中的资料生成面试回答

假设用户在知识工作台中选择了项目架构文档、长期记忆设计文档和 RAG 设计文档，并提出问题：

“为什么长期记忆不能只放在向量数据库里？请按 STAR 法则回答。”

系统不会把所有文档直接塞进 Prompt，而是先根据问题生成适合检索的 query，限定在用户选中的资料范围内；再通过向量检索和关键词检索召回“向量库作为索引、副本”“MySQL 是事实源”“memory_id 关联”等片段；融合、重排后回溯其所属父块，最后由 Agent 组织成 STAR 回答并带上引用。

这与商品推荐的差别在于：商品推荐可以把十个候选商品平铺展示；RAG 必须把多个证据综合为一段可验证的答案。所以 RAG 的排序目标不仅是“像不像问题”，还要考虑证据完整性、来源可信度和上下文是否足以支撑回答。

4. 长期记忆：把“推荐证据”替换成“推荐用户信息”

长期记忆服务的不是“资料里有什么”，而是“这个用户长期有哪些稳定且值得影响回答的信息”。例如：偏好的输出格式、长期学习目标、稳定的项目背景、明确要求保存的信息，以及在多个会话中反复确认的事实。

它同样有完整的数据链路。

真实项目场景：面试回答偏好的跨会话延续

本文讨论中，用户多次提出“面试回答希望简洁”“最好按 STAR 法则”“每个问题要基于这个 Agent 项目，而不是大概念”。这类要求不是一次性的资料证据，而是稳定的表达偏好，适合作为候选长期记忆。

一条写入后的记忆可以是：

{"memory_id":"mem_01","memory_type":"output_preference","content":"回答项目面试问题时，优先使用简洁的 STAR 结构，并结合 Agent 项目实现细节。","confidence":0.95,"status":"active","source":"多轮用户明确要求","version":1}

当用户下一次问“怎么解释长期记忆和会话摘要的区别”时，系统会先把当前问题向量化，在向量库里找到mem_01，再通过memory_id回查 MySQL。MySQL 负责确认这条记忆确实属于当前用户、仍处于active状态、没有被用户删除或被新版本覆盖。验证通过后，系统只把这条高相关记忆加入上下文，Agent 就会自然地按简洁 STAR 风格回答。

这里不能简单地说“用户画像同时存进 MySQL 和向量数据库”。更严谨的设计是：

• MySQL 是事实源：保存记忆正文、用户归属、类型、状态、置信度、来源、版本和生命周期信息，支持更新、删除和审计。
• 向量数据库是语义索引：保存 embedding 与memory_id，负责根据当前问题找候选。
• memory_id 是两者的关联键：向量召回负责“找得像”，MySQL 负责“这条记忆现在还能不能用、是不是这个用户的、内容是否可信”。

这和推荐系统中的“召回索引 + 商品主数据”也很相似：召回层追求快，事实源追求可管理和可恢复。

5. 为什么长期记忆比推荐更保守

推荐错误的代价通常是这次商品不够合适；长期记忆错误却可能持续影响之后的每一轮回答。例如用户说“这次写正式一点”，如果被误写成永久偏好，后续回答都会变得生硬。

因此，长期记忆的写入应当遵循以下边界：

• 只提取用户明确要求保存的信息、稳定偏好、长期目标和反复出现的事实。
• “本次、这次、临时”等一次性约束不写入长期记忆。
• 敏感信息默认不写，或进入需要确认的状态。
• 模型输出不能直接当作用户事实；它最多作为写入候选的上下文或证据。
• Agent 调用 RAG 工具获得的外部资料内容，不能直接写成“用户的长期事实”。
• 低置信度候选进入pending，冲突的旧记忆可以降权、失效或被新版本覆盖。

推荐系统会通过探索机制给新商品更多曝光；长期记忆却不应该因为“需要探索”就把不确定的猜测注入上下文。它的第一原则是高精度和可控，而不是召回越多越好。

6. 反馈闭环：不是让模型自己决定一切

三类系统都需要反馈，但反馈来源和可信度不同。

长期记忆的评估也不是全部交给模型。可以分三层：

1. 系统自动统计：记录召回了哪些memory_id、最终注入了哪些、增加了多少 token、检索耗时多久、用户是否编辑或删除。
2. 用户显式反馈：在回答后提供点赞或点踩，并让用户选择“记错了我的偏好”“不应该使用这条记忆”“风格不符合预期”等原因。
3. 离线人工或模型辅助评估：从已标注样本中判断，当前问题是否应该召回某条记忆、写入是否正确、冲突是否被正确处理。模型可以辅助批量评估，但高风险样本仍应由人工抽检。

为了将反馈归因到具体记忆，可以记录一条 memory trace：

run_id user_id retrieved_memory_ids injected_memory_ids memory_token_count retrieval_latency_ms user_feedback feedback_reason

有了这条链路，用户点踩“记错了我的偏好”时，系统能定位当时究竟注入了哪条记忆，而不是只能知道“模型这次答得不好”。

7. 结论：复用的是范式，不是照搬目标

把 RAG 和记忆机制看作推荐系统范式的迁移，有助于设计出更完整的 Agent：

• 用多路召回避免只依赖一种检索信号。
• 用过滤和重排控制相关性、权限、状态和上下文长度。
• 用反馈闭环判断系统是否真的提高了用户体验。
• 用数据生命周期管理处理失效、冲突、合并和删除。

但不能把三者完全等同。商品推荐关心“用户可能想买什么”；RAG 关心“哪段资料可以作为可信证据”；长期记忆关心“哪些用户信息应该在此刻被使用”。

一句话总结是：推荐系统是在推荐商品，RAG 是在推荐证据，长期记忆是在推荐对当前回答最有价值的用户状态。它们共享召回、过滤、排序和反馈的工程骨架，但必须分别围绕转化、可信度和记忆准确性设计目标函数与安全边界。