做商品推荐时我们面对的是一个经典问题商品很多但用户在当前时刻真正感兴趣的只有少数几个。系统需要从海量商品中找出候选过滤无效内容按用户兴趣排序并通过后续点击和购买持续修正结果。RAG 和 Agent 长期记忆看起来属于大模型应用但从工程结构上看它们与推荐系统高度相似区别只在于推荐的对象和优化目标。商品推荐推荐的是商品目标通常是点击、购买和长期留存。RAG 推荐的是能够支持回答的资料证据目标是相关、正确、可追溯。长期记忆推荐的是当前回答真正需要用到的用户偏好和稳定事实目标是回答一致、准确且不冒犯用户隐私。因此推荐系统的“数据采集、召回、过滤、排序、反馈闭环”是一套可迁移的工程范式而不是某一种只能用于电商的算法。1. 一个统一的视角从候选集合中找最该返回的信息三类系统都可以抽象为同一个问题给定当前请求和历史上下文从一个很大的候选集合中找出少量最有价值的信息。对应关系如下推荐系统RAG长期记忆商品库文档、网页、笔记的分块库用户的稳定偏好、目标、事实库用户当前行为和场景当前问题、已选择资料、会话上下文当前问题、当前会话和用户身份召回候选商品召回相关文档分块召回相关记忆无货、不可售、重复商品过滤权限、资料范围、低质量分块过滤用户归属、状态、敏感性、冲突记忆过滤点击/购买概率排序相关性和重排分数排序相关性、置信度、时效性排序点击、购买、退款反馈点赞点踩、引用正确性、回答质量反馈用户编辑删除、纠错和后续会话反馈这里的关键不是“它们都使用向量数据库”。向量检索只是召回手段之一真正相同的是系统都要解决候选集过大、结果不全相同、用户意图会变化以及结果需要被持续评估的问题。2. 商品推荐这套范式最成熟的形态电商商品池往往有百万级甚至更大不可能让一个模型对所有商品逐一精算。因此生产系统通常是多阶段的。采集行为和商品信息记录曝光、点击、收藏、加购、购买、退款同时维护商品类目、价格、品牌、库存和促销信息。多路召回快速找出几百到几千个候选商品。例如ItemCF根据“看过或买过 A 的用户也看过 B”召回相似商品也可以根据用户最近的行为序列、类目、关键词或商品向量召回。过滤和粗排去掉无库存、下架、不可配送、重复或用户明确不感兴趣的商品。精排和重排预测点击、购买或预期成交金额再控制多样性、新品曝光、价格范围和运营约束。反馈闭环新的点击、购买和退款进入日志用于更新相似关系、特征和排序模型。一个很具体的行业场景是商品详情页的“看了这件商品的人还看了什么”或“买了 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. 反馈闭环不是让模型自己决定一切三类系统都需要反馈但反馈来源和可信度不同。系统直接反馈可观测指标需要谨慎的地方商品推荐点击、加购、购买、退款CTR、CVR、GMV、复购率点击高不代表用户真的满意RAG点赞点踩、引用正确性、追问RecallK、NDCG、回答满意度、引用覆盖率模型自评不能代替真实证据校验长期记忆用户修改、删除、纠错、点赞点踩原因误写率、冲突率、编辑删除率、召回延迟、token 增量不能把模型自己的猜测循环写回记忆长期记忆的评估也不是全部交给模型。可以分三层系统自动统计记录召回了哪些memory_id、最终注入了哪些、增加了多少 token、检索耗时多久、用户是否编辑或删除。用户显式反馈在回答后提供点赞或点踩并让用户选择“记错了我的偏好”“不应该使用这条记忆”“风格不符合预期”等原因。离线人工或模型辅助评估从已标注样本中判断当前问题是否应该召回某条记忆、写入是否正确、冲突是否被正确处理。模型可以辅助批量评估但高风险样本仍应由人工抽检。为了将反馈归因到具体记忆可以记录一条 memory tracerun_id user_id retrieved_memory_ids injected_memory_ids memory_token_count retrieval_latency_ms user_feedback feedback_reason有了这条链路用户点踩“记错了我的偏好”时系统能定位当时究竟注入了哪条记忆而不是只能知道“模型这次答得不好”。7. 结论复用的是范式不是照搬目标把 RAG 和记忆机制看作推荐系统范式的迁移有助于设计出更完整的 Agent用多路召回避免只依赖一种检索信号。用过滤和重排控制相关性、权限、状态和上下文长度。用反馈闭环判断系统是否真的提高了用户体验。用数据生命周期管理处理失效、冲突、合并和删除。但不能把三者完全等同。商品推荐关心“用户可能想买什么”RAG 关心“哪段资料可以作为可信证据”长期记忆关心“哪些用户信息应该在此刻被使用”。一句话总结是推荐系统是在推荐商品RAG 是在推荐证据长期记忆是在推荐对当前回答最有价值的用户状态。它们共享召回、过滤、排序和反馈的工程骨架但必须分别围绕转化、可信度和记忆准确性设计目标函数与安全边界。