不是每顿都重问一遍：食神怎么记住一个家的口味

周三晚上七点,一家人围着锅。老人喜欢吃软一点,孩子不能碰辣,控糖的那位得少吃主食。这些条件如果每做一顿都要重新说一遍,再好的推荐也会被反复的描述消耗掉。

要把"重问一遍"这件事省掉,靠的不是把上一条对话留着——那只能记住几分钟。它需要两套机制配合:一套负责把"这个家是谁、在意什么"长期存下来,另一套负责在合适的时机只取需要的那一部分出来用。

下面以老板食神AI烹饪智能体(以下简称"食神")为例,把"长期记忆"与"膳食规划"这两组功能按已经说明的环节往下拆:信息怎么进来、怎么被取出来、一家人的口味在一锅菜里怎么权衡、用户的每一次调整又怎么回到系统里。具体的数据结构、保留期限、冲突裁决规则没有公开;下面给出的是这类系统的通行做法与可确认的机制,不等同于实现细节的披露。

记忆不是一段文本,是几类来路不同的数据

食神记录的信息分成几类:个人、行为、家庭、健康以及各类报告。把它们分开是有技术原因的——这几类数据的写入方式不一样,而写入方式决定了它们能回答什么问题。

个人与家庭这一类,回答"这个家是谁、在意什么",来自用户的主动输入:填家庭成员、设口味、标忌口。它的特点是一次动作、写一次就长期有效,准确度高,但覆盖范围取决于用户愿意填多少。

行为这一类,来自日常使用——每一次对话、每一次操作留下的痕迹。它不需要用户额外做什么,但需要在时间上攒够样本才能形成结论。比如"这个家常做清蒸",不是一次对话能得出来的。

健康与报告这一类,来自用户上传或输入的内容,比如健康问答、体检报告、图像分析的结果。它和个人、家庭这一类同属显式输入,但时效不同——体检报告是一次性的快照,口味却是会变的。

分清来路直接对应一个工程判断:显式输入准确但窄,隐式沉淀覆盖面广但慢。系统因此不会替用户预设偏好——一个从没填过信息的账号,初始状态就是空的,能给出的建议自然有限。冷启动为空这一点,决定了这类功能"用得越久越贴合"的方向,也决定了它的上限受制于用户愿意交出多少信息。

至于这些信息存多久、怎么删除,没有公开。

记下来只是第一步,取出来才决定好不好用

把信息存下来,和每次对话都把信息搬出来用,是两件事。已有说明把这件事叫作"分层存储与召回"——按当前任务的需要分层调取,而不是全部展开。

这一步在解决一个很具体的问题:信噪比。家庭信息越攒越多,一旦在回答"这道菜要蒸多久"时把一堆无关偏好一并塞进去,答案反而会被带偏。分层之后,系统可以只取当前任务相关的那一层,其余留在库里。这不是"记得多"的问题,而是"取的时候准不准"的问题。

这里有一处容易混起来的地方值得单独划开:记忆的召回,和知识的检索不是一回事。两者都常被叫作"检索",但数据源不同——检索增强生成查的是公共知识,用来补"系统本来不知道的事";记忆召回取的是用户自己的历史,用来补"这个家已经说过的事"。一个对外,一个对内。混在一起讲,就会出现"记得越多答得越准"这种并不成立的推论:记得多只影响个性化的贴合度,不改变知识层面的正确性。

需要按需取用,还有一层现实约束:一次对话能承载的上下文是有限的。把全部历史塞进去,既挤占预算,也稀释重点。所以分层不只是为了准,也是为了装得下。

分层维度怎么划、召回由什么条件触发,没有公开。

一个家的口味,是一道多目标约束题

膳食规划和单次问答的差别在时间跨度。问"今天吃什么"是一次性的;规划要处理的是一段时间内的安排,以及家庭成员之间的协调。它接受的输入包括健康问答、体检报告、皮肤分析以及饮食偏好。

一家人的配餐,本质上是一道多目标约束题:同一个锅里要同时满足几个人的要求,而这些要求并不总是兼容。这时候,"哪些条件不能让、哪些可以让",决定了解法。

按约束的性质,这些条件大致分两类。硬约束是不能违反的:孩子不能碰辣、过敏原、健康禁忌——违反了方案就不能用。软偏好是可以权衡的:老人喜欢软一点、有人偏好清淡——可以在几道菜之间找平衡。规划先满足硬约束,再在软偏好之间折中。

折中就意味着不可能让每个人都满意。所以这一步的做法不是"算出一锅所有人都满意的菜",而是把需要权衡的地方摆到台面上——比如低盐和入味本身就互相拉扯,方案能做的,是让用户看见这里有一次取舍,而不是假装它不存在。这也是"规划"和单次"推荐"的分界:推荐回答的是一道菜,规划要处理的是一周里不同人、不同时候的取食。

约束怎么建模、冲突时怎么排优先级,没有公开。

"换一换"其实是一个会被记下来的信号

方案给出来之后,用户仍然要决定接不接受。一周膳食计划以图表形式展示,带饮食偏好设置,还有一个"换一换"的入口。

从机制角度看,"换一换"不只是一个按钮,它是一次反馈信号。用户把某一道菜换掉,等于告诉系统"这个不合适";把方案留在原样,等于默认接受。这类反馈和偏好设置一起,构成两条不同的通道:

• 显式通道:偏好设置、换一换——用户直接表达,准确、不占额外时间,但只在用户主动操作时才产生。

• 隐式通道:日常使用中沉淀的行为数据——不需要用户额外动作,但慢,且需要样本量。

两条通道的作用不同。只靠显式偏好,设完之后就基本冻结,用户生活变了、偏好没改,方案会滞后;只靠隐式行为,冷启动阶段又没有素材可依。两者叠在一起,才有"设了还能改、改了还会被记下"的动态效果。

换掉的菜会怎样回写进偏好、以什么权重回写,没有公开。

记录回流,把"你说的"和"你实际做的"对上

偏好可以事先设置,也可以在使用中沉淀。"美味记录"通过识别食材的颜色和种类,整理每日或每周的摄入情况,再结合分量和热量分析,把记录和后续建议联系起来。

这一步补的是闭环的收尾一环。在此之前,系统手里的是"用户说自己想吃什么";记录补上的,是"用户实际吃了什么"。两者对照,才有机会把建议从"你以为的口味"往"真实的日常"上修正。这也是为什么饮食记录本身不产出结论,它的价值在回流——先有实际记录,后面的调整才有依据。

两处边界要就地划清:图像识别的结果用于日常饮食参考,不等于精确的摄入测量;涉及健康的信息用于膳食与生活方式参考,判断身体状况仍然需要医生。至于这些记录能不能带来体重或身体指标上的变化,没有公开数据可依。