一场关于技术本质、落地挑战与未来展望的深度对话

李志宇首先抛出了核心问题:"记忆工程究竟是什么?它与我们熟悉的RAG、微调等技术本质上有什么区别?"他从自己的实践出发给出了答案:"从我的角度来看,记忆工程更关注的不是当前这个回答好不好,而是整个AI系统在长期运行过程中,是否能够持续去做积累、组织、修正和正确使用。比如哪些东西应该被记住,这些记忆应该放在哪里,用的时候怎么调用,有过期和错误的信息怎么修正,这些修正过的信息需不需要做审计。所以我认为记忆工程是一套比较偏系统性的工程理论和方法,而不是某一个具体的算法。"

胡晨从用户体验的角度补充道:"我觉得记忆工程的核心是获得一个跟人类对齐的上下文。什么意思呢?我们希望让模型有足够的上下文,跟人类尽量对齐。人类会从历史记忆中找出有效的信息,也会丢弃无效的信息。举个例子,我们跟一个智能助手讨论工作计划,传统系统问'今天有什么重要会议',它可能只会在当前对话里找,找不到就幻觉出一个答案。有记忆的系统不仅能回答你的工作安排,还能记得你之前提到的项目进展、关注的事,甚至主动提醒你在做这个事情前需要关注哪些材料。两者最大的区别,就是有没有给模型足够的上下文。"

于明则从产品实践的角度阐释:"记忆工程就是AIOS操作系统里的memory。它可以根据与人的对话过程,总结出跟个人相关的信息,比如我爱吃辣,推荐餐馆时就记住这一点;我明天有什么安排,问的时候能召回。它跟RAG的分界线其实没那么明显,很多地方会用到RAG的技术。至于微调,可能在一些垂直任务上让大模型学到知识,但微调周期长,对数据、算力要求高,效果也不够稳定。所以RAG和记忆工程可能更像是大模型的一个组件。"

三位嘉宾的观点呈现出有趣的互补:李志宇强调系统性和长期性,胡晨聚焦用户对齐和体验,于明关注产品落地和技术实用性。这恰恰说明,记忆工程不是单纯的技术问题,而是涉及架构、算法、工程、产品多个维度的系统工程。

当话题转向实际落地,三位嘉宾不约而同地提到了挑战的复杂性。

李志宇梳理了几个关键瓶颈:"在记忆写入时,到底写什么是个难点;随着用户跟agent交互越来越多,记忆量增大,检索调度的性能会成为瓶颈;用户对特定主题会持续更新,更新过程中也有技术瓶颈。"

于明从手机厂商的角度给出了更具体的回答:"对我们做手机的来说,有个词叫'快稳省'——要快、要稳定、要省电。在端侧,很多模型要在NPU上计算,这是个比较大的挑战。另外多模态能力,对图片或视频的召回,也是很大的挑战。还有表格、结构化文本这些方面。云端的话,在意图、实体、长期记忆、prompt过滤方面都有不少挑战。整个系统框架上,长期记忆是大家一直在探索、发展很快的方向,我们也在持续摸索。"

胡晨则从模型能力的角度分析:"首先是长文本能力。当前Transformer架构的模型有长度限制,从32K、64K到128K、256K,甚至有的能到两百万tokens。但一个人如果一天跟AI充分交流,稍微多聊一点就能到几十兆级别的数据量,不可能把所有上下文都放到提示词中。随着长度增长,模型能力也会下降。第二是评估困难。记忆非常主观,每个人偏好差别很大,很难有标准的评价体系,这让整个系统的评估难度非常高。第三是团队协同的挑战。记忆工程既牵扯模型算法,也牵扯数据、工程、评估,几个方面得协同优化。做RAG或模型微调时,稍微动一个模块,其他模块可能都得跟着更新。这种牵一发动全身的情况,会让整个系统在组织和协同方面带来很大挑战。"

从这些讨论中可以看出,端侧更关注效率和资源约束,云端更关注能力和系统复杂度,而两者都面临评估体系不完善、多模块协同困难的共性问题。

关于记忆系统的技术路线,三位嘉宾讨论了一个核心问题:是用类RAG的外部存储方案,还是把记忆训练到模型内部,还是两者混合?

李志宇提出了观察:"实际场景中有不同的技术路线讨论。有些场景比较适合用类RAG的解决方案去模拟记忆过程;也有些高频的记忆类型,倾向于把它训到模型内部,或者训练模型让它具备更好的记忆操纵能力。换句话说,有外部存储的范式,也有model-based的范式。在实际场景中做这些不同范式时,是否需要做一些权衡?还是说未来hybrid范式是必选路径?"

胡晨认为要根据场景灵活选择:"这得根据实际场景来看。比如我是云端无限算力的场景,可能大概率希望是model-based去解决一切,可以训练模型推理。有些像于老师遇到的端云结合场景,就非常考虑成本、开销、推理延迟等问题。从模型角度说,我们肯定希望所有东西都能融入模型中,这样系统复杂度会相对较低,不需要每次都推理召回一堆信息然后处理。如果一个模型足够智能,我可能希望做到这个程度。当然现在也有很多新技术,比如三星提到的HRM工作,通过无限上下文的网络结构来处理。所以解决方法非常多,一定得根据实际场景看哪几种方式结合起来比较好。当前范式下可能大部分都还是通过混合方式——有一部分模型微调的能力,有一部分通过RAG去加强。因为模型肯定需要持续训练,但训练周期赶不上外部知识库的更新,所以这肯定是存在的。从长期角度说,可能会有某种范式能突破这个架构,但现在还不太好估计。"

于明从实践经验给出了更具体的方案:"我觉得分流加上冗余的设计,可能对用户体验会更好。什么叫分流?很多跟个人相关的personal信息,大模型没法搞定。比如我的日程、我跟小孩拍的照片,这些需要去memory里找。但秦始皇是谁、给我说首诗,模型内部肯定能搞定。像手机设置这些垂直信息,我们可以微调模型。我们希望分流之后,简单的问题或大模型能搞定的问题让大模型来搞定,基于特定记忆的让RAG来召回。但当分错了,也要有一定的容错机制。比如你认为要通过RAG召回,但RAG没有召回,这时候可能需要大模型继续来回答。我觉得分流加冗余可能是一个比较好的方案,这个就是hybrid。"

李志宇总结道:"两位老师的观点可以这样理解:外部存储的优势是成本可控、可删除可更改、效率高,天然适配高频变化的事实和个性化内容。模型内部的记忆存储更倾向于吸收相对稳定、高价值的结构化知识。模型内部训练完成后,优势是调用成本低,推理路径更短;但带来的问题是没办法频繁更新,可解释性也相对较弱。所以总结起来,需要根据特定场景——是高频变化的场景,还是相对稳定的场景,来选择使用哪一部分的能力。结合我们自己的做法,我们认为确实需要根据不同场景类型,对参数化的记忆和提示词的记忆执行一定的调度行为,从而保证面向场景能达到hybrid的稳定性最优状态。"

这段讨论揭示了一个重要的共识:在当前技术阶段,hybrid模式不是可选项,而是必选项。关键在于根据场景特点(变化频率、稳定性、个性化程度)来合理分配外部存储和模型内部记忆的比例。

"除了准确率,我们还应该关注哪些关键指标?如何利用这些指标帮助我们持续迭代?"李志宇提出了评估这个关键问题。

胡晨给出了系统性的回答:"评估确实非常重要,如果评估不好,很难衡量系统到底哪个地方出了问题。我们得先从出发时机开始说。比如系统有一些自动唤醒记忆的时刻,这个既不能太早也不能太晚。用户问了问题,得判断什么时候去调用,就有相应的响应时间,所以响应时间非常重要。太慢了用户体验不好,太快了用户可能对你是否真的查了这个信息有疑虑。"

"第二部分是基于记忆本身的质量。这包含能不能召回相关内容,以及精准度。这就是RAG里我们非常看重的召回率和准确度,这两个需要平衡的指标。第三,我在召回之后,需要看模型是否通过记忆带来了增量的回复。如果召回完之后比原本不加memory表现还差,那我肯定不希望做这个操作。所以得看回答的好坏、相关性、满意度这些更细粒度的指标,来评判效果是不是带来正向收益。"

"有了这个基础评估之后,可能还有一些短期记忆和长期记忆的更新。得看系统的更新频率怎么样,能不能在用户出现错误记忆后快速修正或删除。对于长期记忆,要有有效性的判断,是否在系统中被记下来,在问相关内容时能回答出来。最后是安全或隐私,这也非常重要。一旦加密强度不够高,用户隐私被prompt工程泄露出来,这就非常危险。所以这几个角度都是非常重要的评估指标。"

于明补充了端侧产品的特殊关注点:"胡晨老师讲的已经比较全了。像召回和准确度我们用F1来评价。首字时间应该是最关键的指标,我们还会关注吐字速度。另外在上线前肯定有用户满意度的评测,看他对结果到底满不满意,这跟F1应该是线性相关但又不完全一样。我们还需要在线上建立实验看板,这跟评测也比较相关,看各模块的耗时、稳定性、P99的时延。另外对于评测来说,比较重要的一点是对整个RAG链路——从我们这边的实践就是从端到云各链路的这些指标也需要有一个衡量的手段,不然你不知道哪里是你的薄弱环节。"

李志宇进行了总结:"在记忆工程的实践过程中,我们不可能只评估端到端的回答是否正确、是否有效。我们要把它打开去看。特别对首字时间这个延迟、吞吐,可能是非常重要的考核目标。从整体角度上实现'用户越用越懂我',这个'懂'要拆解成整个链路系统里的各种指标——越用越省,从token消耗、功耗能耗角度来讲,我们需要把系统跟应用场景拆开,然后绑定起来。整个系统的稳定性也要有比较好的保障。相当于从快、省、稳这三个指标上,分别去绑定我们整个业务系统的指标。"

这部分讨论揭示了记忆系统评估的多维度特性:既要关注技术指标(召回率、准确度、延迟),也要关注用户体验(满意度、首字时间),还要关注系统健康度(各模块耗时、稳定性),形成一个立体的评估框架。

"未来记忆可能会成为每个用户最重要的资产",李志宇开玩笑说,"今天你调DeepSeek去回答老板的问题,我也调去回答老板的问题,哪个可能回答得更好?原因可能就是我平常跟DeepSeek交流很多,把我的一些理念、方法、思路都在交流过程中沉淀成记忆。从这个角度来讲,随着产品演进或技术演进,记忆可能会成为人最重要、最根本的资产。无论从系统框架的角度,还是从手机端云协同的用户角度,我们如何在记忆系统里解决隐私保护、数据安全或合规治理的问题?"

于明首先回应:"作为手机厂商,安全合规、敏感信息一直是我们的红线。这块我们在立项之前就开始考虑。端侧是天然安全的,数据只要不上云,在用户手机上是没问题的。所以我们尽量让能在端侧计算的数据都放在端侧,只有非常必要的、跟用户强相关的才会上云给大模型,因为端侧大模型的能力现在还没有达到让用户满意的阶段。"

"端侧之外的传输,我们采用加密传输。在云端,对于安全来说,我们都是用可信计算,就是PCC(Private Cloud Compute),通过端侧、传输和云端的硬件来保证用户数据安全。另外对隐私合规的信息,比如用户的密码、邮箱,我们的经验是用保险箱加密最好。因为你不管用什么东西替换,大模型最后都会出问题。所以在端侧把它进行脱敏,上云进行计算,最后返回端侧再还原回来。这种方式我们认为是比较不错的,对用户隐私保护比较好。"

胡晨表示认同:"我们大体的思路也是类似这种云端协同的方式。敏感数据一般在本地处理,比如一些图片,或者像UI的一些操作,涉及到用户要去设置自己的账户什么相关的信息,这种肯定在端侧处理。云端也一样,如果需要更强算力的模型去做,一定得做一些脱敏,并且尽量通过加密的方式去传输。这块跟于老师这边的设想是相近的。"

李志宇总结道:"整体上来讲,从记忆的生产到记忆的调度,到记忆的使用,从各个层面——包括物理层面的隔离存储、传输层面的加密、系统性的能力——进一步把安全性给它完整保障。当然从我们的角度来讲,可能还要做一些审计的能力。一旦某些记忆发现问题,我们能够做一些回溯,并且做一些溯源生成,保证每一条决策用户是能够感知到它背后的信息来源的。换句话说,确实需要我们把它打开,从系统各个角度去保障它本身的合规性和安全性。"

这段对话展示了业界对记忆安全的三层防护思路:端侧隔离(物理安全)、传输加密(通道安全)、云端可信计算(计算安全),再加上审计溯源(事后可控),形成了一个完整的安全保障体系。

在直播过程中,观众提出了几个很有代表性的问题。

"长期记忆和用户行为沉淀形成的知识库有什么区别?"

胡晨回答:"用户沉淀的知识库,是一个非常宝贵的专家经验,或者说他自己的一套做事的方法论。这种是用户念出来的信息,大部分用户自己都做了一些处理。长期记忆有点像你跟助手去聊天、互动、交流,可能更多以对话这种形式,或以某种方式存下来。"

于明补充:"长期记忆我理解更多是去刻画用户画像,它更加偏向于跟人交流学习到的。知识库有点像你在终端可能手写下来一些东西,或者从网上收藏一些东西,它相对来说更加结构化,且不太会发生变化。长期记忆可能是你在使用过程中会慢慢迭代的。"

李志宇总结:"长期记忆更偏向于持续性积累,在跟智能体长期的交互过程中不断沉淀的;知识库更偏向于一次性或阶段性沉淀的内容,是个人的一些方法论的有结构的沉淀。"

"如果多用户使用智能体,记忆怎么存储?"

于明:"端侧通常用户就一个,但比如车载座舱可能有多个用户,或者会议助手。我们一般会根据声纹识别或者user ID做一个分层的存储。如果这个用户下线了,或者它的上下文已经很长了,我们会做一些压缩或者过滤,把不必要的信息给它存掉,降低成本。"

"GraphRAG对记忆工程有帮助吗?"

胡晨:"GraphRAG对于比较体系化的知识提升还是比较明显的,比如医疗、金融领域。对于一些比较碎片化的信息,可能没那么明显。具体还是根据场景来看,但有肯定比没有要好。"

于明:"我们在手机上的场景都是比较碎片化的,比如文档、图片。GraphRAG这种方式性价比不是很高,因为在端侧做这个还是挺吃算力的。"

"记忆管理是主动的吗?用户不提出来,记忆系统会主动管理吗?"

李志宇:"从我的角度来看,记忆是既可以被动也可以主动的。系统应该在用户发出明确指令之前,就做好一些预判和准备,实现'化整为零'的调度。"

胡晨:"我们训练的记忆网络,是希望模型自己能够判断是否需要记录一条信息,或者修改或删除一些信息。所以本质上我们希望这是主动的。"

这些问答展示了记忆工程在实际应用中面临的细节问题,也反映出业界对这一技术的多样化需求。

当话题转向成本,三位嘉宾都表达了对这一现实问题的重视。

李志宇提问:"在座的各位老师,在这个系统里面对于这个算力成本或者说token成本这一块,有什么样的一些优化的方法?"

于明分享了端侧的实践:"端侧主要还是把模型转成他们的算子,通过剪枝、量化等手段优化。另外就是在搜索的时候,尽量让检索更加精准,把不必要的信息过滤掉,降低上下文的长度,这样可以降低成本。还有就是KV Cache的复用,这个也能降低一定的成本。"

胡晨从云端角度补充:"云端也是类似的。我们通过一些模型的量化、剪枝去降低推理成本。另外通过一些上下文的精简,或者通过一些总结的方式,把一些冗余信息去掉,保留核心的信息。这样既能保证效果,又能降低成本。"

李志宇总结道:"成本优化的核心思路,一是通过模型层面的技术手段(量化、剪枝、算子优化)降低单次调用成本;二是通过系统层面的优化(精准检索、上下文精简、KV Cache复用)降低调用频次和数据量;三是通过合理的分层存储策略,把高频访问的记忆放在快速缓存,低频的放在云端或低成本存储,实现成本和性能的平衡。"

"在多智能体协同的场景下,记忆是应该共享还是隔离?"这个问题引发了有趣的讨论。

胡晨认为:"这取决于场景。比如在企业级应用中,可能有一些公共的知识库是需要多个智能体共享的,但每个智能体也应该有自己的专属记忆。这就需要建立一个分层的记忆架构——有全局共享的层级,也有个体私有的层级。关键是要有清晰的权限管理机制。"

于明从产品角度补充:"在手机场景中,我们更倾向于隔离。每个用户的记忆应该是独立的,不能互相干扰。但在一些特定场景,比如家庭共享或团队协作,可能需要有选择性的记忆共享。这时候就需要用户明确授权,而且要有细粒度的控制。"

李志宇总结:"记忆的共享与隔离不是二选一,而是需要根据场景灵活配置。核心原则是:默认隔离,按需共享,明确授权,细粒度控制。这样既能保护隐私,又能发挥协同的价值。"

临近直播尾声,三位嘉宾展望了记忆工程的未来。

胡晨表达了他的期待:"我觉得未来的记忆系统应该能做到几点:第一,真正实现与人类记忆机制的对齐,不仅仅是记录信息,还能理解信息的重要性、时效性,自主进行遗忘和强化;第二,跨模态的记忆能力,不仅能记住文字,还能记住图像、声音、甚至情感;第三,记忆的可解释性和可控性,用户能够清楚地知道AI记住了什么,为什么记住,也能方便地管理和修改。"

于明从产品角度分享:"我们希望未来的记忆系统能够更加智能化、自动化。用户不需要刻意去管理记忆,系统就能自动帮你记住该记的,忘掉该忘的。同时,随着端侧算力的提升,更多的记忆处理能力可以下沉到端侧,这样既能保证隐私,又能降低延迟,提升体验。"

李志宇总结道:"记忆工程的终极目标,是让AI系统真正拥有'经验'。不是简单的信息存储和检索,而是能够从历史交互中学习、成长,形成自己的'认知'。这需要我们在技术架构、算法设计、工程实现、评估体系、隐私安全等多个维度持续创新。这条路还很长,但方向是清晰的。"

最后,三位嘉宾给出了对开发者的实践建议。

李志宇:"我建议开发者先从一个具体的场景入手,不要一开始就追求大而全的记忆系统。比如先做一个能记住用户偏好的推荐助手,或者能记住项目上下文的工作助手。在这个过程中,你会遇到记忆写入、检索、更新、评估等各个环节的具体问题,这些经验是最宝贵的。"

胡晨补充:"选择合适的技术栈很重要。如果是小团队或个人开发者,可以先基于现有的开源框架,比如LangChain、LlamaIndex这些,它们已经提供了基础的记忆管理能力。重点放在场景设计和prompt工程上。如果是企业级应用,就需要考虑更完整的架构,包括分层存储、权限管理、评估体系等。"

于明分享:"从产品角度,我建议先明确你的用户需要什么样的记忆能力。是希望AI记住个人偏好?还是记住工作上下文?还是记住知识和经验?不同的需求对应不同的技术方案。另外,一定要重视隐私和安全,这不是可有可无的,而是底线。用户对AI的信任很大程度上取决于他们是否相信自己的数据是安全的。"

结语

从记忆工程的本质定义,到落地挑战,到技术路线选择,到评估体系,到隐私安全,再到未来展望,本次讨论为我们描绘了一幅完整的记忆工程全景图。

记忆工程不是一个简单的技术特性,而是AI系统从"工具"向"伙伴"演进的关键。它让AI不再是一次性的对话机器,而是能够在长期交互中积累经验、理解用户、提供个性化服务的智能助手。这个过程充满挑战——技术上要解决长文本处理、多模态召回、实时更新等难题,工程上要平衡性能与成本、端侧与云端、共享与隔离,产品上要赢得用户对隐私安全的信任。

但正如三位嘉宾所展示的,业界已经在这条道路上迈出了坚实的步伐。从手机端侧的快稳省优化,到云端的复杂记忆管理,从hybrid技术路线的探索,到立体化评估体系的建立,从三层安全防护,到主动记忆管理,每一个细节都在推动记忆工程从概念走向现实。

这场对话,已经让我们看到了记忆工程这个新兴领域的巨大潜力和光明前景。正如李志宇所说:"记忆可能会成为人最重要、最根本的资产。"在AI时代,谁掌握了记忆工程,谁就可能掌握了通向真正智能的钥匙。

点个在看你最好看

SPRING HAS ARRIVED