从数字人到智能标签：AI伴侣的长期记忆与用户理解重构-北京尧图网络

2025年下半年我做了一个让团队不少人意外的决定把凤希AI伴侣的主界面从那个耗费了大量精力的数字人形象换成了一排安静的、可以点击的智能标签。很多人问我是不是在开倒车毕竟我们之前花了好几个月打磨数字人的表情、口型和动作用户也确实喜欢那个有人样的界面。但我心里清楚数字人只是壳智能标签才是凤希真正能记住你、理解你的骨架。这篇文章我想把这段实践和思考完整梳理出来聊聊为什么我会从拟人化的数字人转向务实的智能标签凤希的标签体系是怎么设计、怎么落地的以及我在这个过程中踩过的坑和现在仍在坚持的做法。如果你正在做AI伴侣、智能助手或者任何需要长期记忆的对话产品这篇内容应该对你有用。在开始之前先交代一下背景。凤希是一个面向普通用户的AI伴侣项目最早的形态是带数字人形象的情感陪伴类应用用户可以和数字人聊天、倾诉、记录日常。我们一度把大部分精力投入到让数字人更像真人上但后来发现用户真正在意的并不是那张脸够不够好看而是它到底记不记得我上次说过的事。这个认知的转变直接促成了凤希从数字人到智能标签的架构调整。1. 为什么我从拟人化数字人转向智能标签一次产品反思1.1 数字人形态的三大硬伤我先说说数字人这条路的真实体验。凤希早期版本是一个完整的数字人分身有定制的3D形象、表情驱动、口型同步甚至还做了简单的肢体动作。技术上我们用了实时渲染方案接入了语音合成和多模态情感识别。投入不可谓不大问题也相当明显。第一大硬伤是成本太高。这里说的不只是渲染成本更是内容制作成本。数字人的每个新表情、每套新衣服、每种情绪表达都需要美术资源和动捕数据去支撑。我们是个小团队光是维护数字人形象的生产管线就占用了大量人力。用户看到的是一个会动的人我们背后付出的却是持续的、近乎内容行业级别的生产成本。第二大硬伤是记忆黑盒。我们早期用对话向量库做长期记忆用户说过的话被塞进向量数据库对话时通过相似度检索召回。这套方案在技术demo里跑得很好实际用起来却让人头疼——检索结果完全不可解释产品同学没法跟用户解释为什么AI突然提起你三个月前随口说的一句话。更麻烦的是向量检索经常召回一些语义相似但毫不相关的内容导致AI说错话用户体感就是这个AI记性很差还喜欢胡说八道。第三大硬伤是评估困难。数字人像不像真人、有没有灵魂这类指标没法量化。我们曾经做过用户访谈用户普遍觉得数字人挺可爱的但说不清哪里好。到了迭代版本的时候产品经理根本不知道改哪里能提升用户留存。没有数据抓手团队只能靠感觉做事这种状态对一个要持续迭代的产品来说是致命的。1.2 一个用户反馈触发了我对智能标签的思考真正让我下定决心转变的是一次偶然的用户反馈。有个用户在和凤希闲聊时提到自己最近在备考某个证书结果第二天凤希在打招呼时真的在不经意间问了句昨天的题刷得怎么样了。用户当时很惊喜在应用商店写了条长评夸凤希有灵性。我们团队看到这条评论都很高兴但内部复盘时却发现这其实是向量检索碰巧命中的一次巧合并不是系统真的理解了用户的备考状态。这个巧合让我意识到一个关键问题用户需要的并不是AI偶然记住某句话而是稳定的、可依赖的被记住的体验。如果我们的记忆机制是不可控的、黑盒的、偶尔灵验的那用户对产品的信任就永远建立在运气之上。于是我开始思考能不能把记住用户这件事从玄学变成工程能不能把用户认知拆解成一个一个明确的数据单元让AI的理解过程可解释、可修正、可评估智能标签这个方向就是在这样的思考下慢慢成型的。1.3 从表现层到底层数据一次彻底的架构转向凤希的架构调整说起来只有一句话把重心从让数字人更像人转向让系统更懂用户。数字人形象我们没有完全砍掉而是降级成了可选皮肤变成了一个表现层的插件。核心的智能能力全部转移到一套独立的标签管线上。这套标签管线的目标很明确把用户在和凤希交互过程中产生的所有信息经过抽取、推断、收敛之后沉淀为一组结构化、可解释、可更新的标签。这些标签不仅是对话时的记忆上下文更是凤希理解用户、做出合适反应的基础。我们用这套标签系统重新定义了AI伴侣的懂你并且让懂到什么程度变成了一组可以量化的指标。说实话这个转向是有阵痛的。团队里数字人方向的同事一开始并不理解觉得我们是在否定他们过去的工作。但我反复跟他们讲数字人和智能标签不是替代关系而是表现和内核的关系。数字人负责让交互更亲切标签系统负责让交互更准确。只是对于一个资源有限的团队来说我们必须优先把内核做扎实。2. 凤希AI伴侣的整体架构会话引擎、记忆仓库与标签管线2.1 三层架构是怎么拆出来的调整后的凤希架构我习惯把它分成三层来看。最上层是交互层负责用户能看到的一切聊天界面、数字人形象可选、消息推送。中间层是认知层也就是我们这次重点打造的标签管线它负责从对话中提取信息、更新用户画像、生成对话策略。最底层是存储层主要存放两类数据对话原文事实数据和标签数据结构化认知。为什么把标签管线单独拎出来作为中间层而不是让它直接嵌在对话引擎里这是我有意为之。对话引擎是高频调用、低延迟要求的组件如果你把标签抽取逻辑写死在对话引擎里那每一次对话都要承担标签更新的计算开销而且很难单独做性能优化和故障隔离。单独拆出来之后标签管线可以异步运行用户聊完天对话引擎先把原文写入存储然后触发标签管线在后台慢慢更新标签整个过程不阻塞用户的下一句话。2.2 标签服务独立带来的三个直接好处独立出来的标签服务第一个好处是可观测性大幅提升。我们可以随时查看某个用户的标签列表、每个标签的来源对话、置信度变化历史等于给AI的理解过程装上了仪表盘。第二是可回滚。标签如果更新错了可以基于历史快照恢复到之前的状态这在做产品迭代时非常重要不用怕新规则上线后出问题而无路可退。第三是可复用。标签服务不只是给对话引擎用凤希的推荐功能、情感陪伴功能、用户的自我认知报告全都复用了这套标签数据。我举个实际的例子。凤希每周会生成一份关系周报里面会告诉用户这周你提到了3次工作压力比上周多了两次。这个功能在标签系统上线之前是完全没法做的因为当时我们只有对话向量根本没法做统计聚合。有了标签体系之后这类数据化的功能变得非常简单只要查询标签库按类型做聚合就行。2.3 技术选型为什么用规则小模型LLM三层漏斗标签抽取的技术方案我们没有一上来就全交给大模型而是设计了一个三层漏斗。第一层是规则抽取专门处理那些高度结构化、只要不傻都能抽对的信息比如用户提到的地点、时间、年龄、职业等明确实体。这层用正则和词典就能搞定速度快、成本低、完全可控。第二层是小模型分类处理那些需要一定理解但类别有限的场景比如对话的情感倾向正面、负面、中性、对话主题工作、家庭、健康、兴趣爱好。这一层我们用了一个几亿参数的分类模型不贵也不慢。第三层才是LLM推断处理真正复杂的信息比如从用户一句略带抱怨的这周又要加班到十点了感觉身体被掏空推断出工作压力大和对当前工作状态不满意的标签。这个三层设计非常关键。起初我们也想过全部用LLM来抽取标签毕竟效果确实是最好的。但实际跑了之后发现两个问题一是成本扛不住凤希的活跃用户每天会产生大量对话全部过LLM的话推理费用相当可观二是延迟不稳定LLM的响应时间波动会直接影响标签更新的及时性。分层之后80%左右的标签可以通过规则和小模型完成抽取只有剩下20%的复杂情况才需要LLM介入。既省了钱又保证了系统的稳定。3. 智能标签的核心设计从懂你到可落地的数据结构3.1 标签的三种类型事实、推断、关系在设计凤希的标签体系时我先把标签分成了三大类这三类对应的可靠程度和更新频率是完全不同的。第一类是事实标签记录用户明确说过的客观信息比如养了一只叫毛毛的猫、在一家互联网公司做运营、住在杭州。事实标签的特点是来源明确、置信度高、更新频率低它们构成了用户画像的骨架。第二类是推断标签是根据用户行为或言论推断出的结论性信息比如对现状不太满意、偏好独立音乐、有规律的健身习惯推断自每周提到跑步。这类标签置信度通常没有事实标签高需要结合置信度评分和时效衰减来管理。第三类是关系标签记录用户和凤希之间的交互关系特征比如用户更愿意在晚上倾诉、用户对鼓励类回应反馈积极、用户不喜欢被过度打扰。这类标签是AI伴侣区别于普通助手的核心它记录的不是用户的客观属性而是用户与AI之间的互动默契。三类标签我用一张表来区分它们的特征标签类型典型示例来源置信度更新频率用途事实标签职业、居住城市、宠物用户明确陈述高低用户画像骨架推断标签性格倾向、情绪状态规则/模型推断中中个性化策略依据关系标签回复偏好、互动时段交互行为统计中高高对话节奏与风格调整3.2 置信度、来源权重与时效衰减有了标签类型还远远不够。真正让标签体系活起来的是置信度和时效管理。凤希的每个标签都有一个置信度字段取值0到1。事实标签用户直接说过置信度直接给到0.9以上推断标签则根据信息来源的数量和一致性来计算。我把置信度的计算逻辑设计成可解释的。简单来说一条推断标签的出现会基于信息来源数量和信息一致性来更新它的置信度。如果用户一周内在三个不同语境下都提到压力大那压力大这个标签的置信度会快速上升如果只是偶然一次提过置信度就维持在一个很低的水位随时准备被新的信息覆盖。时效衰减是另一个非常重要的机制。用户的偏好和状态是会变的标签如果永远不变就会从懂你变成刻舟求剑。我设计了两套衰减策略事实标签几乎不做时效衰减除非有确切的反驳性信息推断标签和关系标签则采用指数衰减半衰期可以按标签类型配置。情绪类标签的半衰期大约是三天兴趣类标签大约是两周稳定的性格类标签则是三个月。这样一个用户如果上个月疯狂迷上露营这个月已经不提了标签自然衰减后就不会在对话中反复出现避免AI显得听不懂人话。3.3 标签生成流程从对话原文到结构化认知标签生成的整体流程是这样的用户和凤希的每一轮对话都会先进入一段预处理把包含关键信息的语句抽取出来。这里不是把整段对话扔给模型而是先做一轮候选句筛选只有那些包含值得沉淀信息的句子才会进入标签抽取管线这一步能省下不少成本。候选句进入抽取管线后按前面说过的三层漏斗逐层处理。规则层先看看有没有明确的实体或时间信息如果有就直接打事实标签小模型层判断句子的主题和情感基调最后如果真的需要深度推断才交给LLM。每一层产出的候选标签都会带上两个关键信息来源引用的原文片段和证据强度。这个设计方便我们溯源——任何一个标签产品经理都能点进去看到它最初是来源于哪句话用户承认过还是我们猜的。这里贴一段标签数据的简化结构方便大家理解{ tag_id: infer_20260204_001, type: infer, name: 近期工作压力偏大, confidence: 0.76, source_quote: 这周又要加班到十点了感觉身体被掏空, created_at: 2026-02-04T12:30:00Z, last_updated: 2026-02-04T12:30:00Z, decay_half_life_days: 3, status: active }你可能注意到了这个标签的置信度是0.76不是1。因为这是从一个单句话推断出来的证据还不够充分。等到后面用户又一次提到加班、疲惫这个置信度才会往上走。产品上我们不允许低置信度的推断标签直接影响对话内容它们只能作为上下文的小型参考。3.4 标签如何反哺对话三个真实使用场景标签体系建设得再好如果只是躺在数据库里的数据那就没有任何价值。让标签活起来的关键是利用它们来改变AI的行为。凤希里目前有三个场景在用标签反哺对话。第一个场景是话题开启。每天凤希跟用户第一次打招呼时会优先选取近期高频标签和高置信度关系标签来生成开场白。比如用户之前连续三个晚上倾诉过工作压力第二天凤希就不会傻傻地问今天过得怎么样而是会带着共情地问一句今天工作上有少一点加班吗。这个细节改动带来的用户打开率提升非常明显。第二个场景是内容偏好控制。凤希会定期给用户推荐一些音乐、文章或者小知识。过去这些推荐是通用的、随机的内容用户反馈一般。接入标签体系后推荐逻辑会根据用户的兴趣类标签来做内容召回同时避开用户明确表达过不感兴趣的话题。推荐点击率几乎翻了一倍这或许可以证明标签的价值。第三个场景是情绪反应的动态调节。我们通过标签识别用户的长期情绪倾向和短期情绪波动。如果用户当前的疲惫标签置信度高凤希的回复就会偏向简洁、安慰、少输出反问如果用户处于兴奋状态凤希会顺着用户的节奏多聊一些开放性的内容。这套机制让对话的情商提升了不少用户的负面反馈率也降下来了。4. 实测中的关键问题与踩坑记录标签爆炸、过度推断和误标漂移标签体系上线后的前两个月我们过得并不轻松。系统在demo里永远表现良好一旦上了真实流量各种问题就冒出来了。我挑几个影响最大、也最值得讲的坑详细说说。4.1 标签爆炸没有收敛策略的标签体系是一场灾难上线第一周我们就发现标签数量以一种失控的速度在增长。规则层抽取的标签里出现了大量近义词和同义表达比如喜欢猫、爱猫、家里有猫、猫奴会被抽取成完全不同的四五个标签。用户聊了半个月有的标签库里已经积累了上千条标签其中大量是重复或近似的。更可怕的是对话引擎在召回上下文时看到这么多碎片标签反而不知道该用哪条效果比没有标签时还差。这次事故让我认清了一个道理标签体系和用户认知一样必须要有收敛机制。我引入了两个手段来解决标签爆炸。一是标签归一化给每个标签增加别名和归属字段所有同义表达在写入时先经过一层归一化映射最终统一到一个标准的词条条目里。二是标签层级化把标签分为领域-主题-实例三级。例如宠物是领域猫是主题家里养了一只布偶叫毛毛是实例。对话引擎在召回时可以灵活选择按领域召回还是按实例召回既保留了细节又避免了碎片化。4.2 冷启动下的过度推断两三次对话就开始猜性格第二个踩到的坑是冷启动阶段的过度推断。标签系统的规则和模型在没有足够用户数据时很容易做出离谱的判断。我印象很深的是一次测试一个新用户只和凤希聊了两轮内容就是你好和今天天气不错系统居然给用户打上了乐观开朗的推断标签。原因是小模型把今天天气不错识别成了正面情绪表达再加上LLM在证据不足时倾向于输出一个合理但未必准确的推断。这种过度推断在生产环境里是会伤害用户信任的。试想一个刚注册的用户突然被AI问你是不是一个很乐观的人用户的真实反应大概率是你怎么知道然后AI答不上来这就变成了信任危机。为了根治这个问题我给标签系统立了几条规矩。首先是最小证据窗口任何推断标签至少在三个不同对话场景中出现过才允许进入可用状态否则只能作为草稿不能影响对话。其次是置信度门槛推断标签的置信度低于0.6时永远不会进入对话策略的参考范围。第三是单条不推断核心特质的规则涉及性格、价值观等核心特质的标签至少要五个证据来源并且跨七天时间跨度才有资格被激活。这些规则听起来有点保守但在AI陪伴产品里保守恰恰是对用户信任的保护。4.3 误标漂移的完整排查链路从现象到根因第三个坑是最隐蔽也最难排查的标签漂移。它不像标签爆炸那样立竿见影而是悄悄发生的。某段时间我们收到用户反馈说凤希变笨了总是把用户和同事的关系搞混。我们查了标签库发现同事A这个事实标签在某些用户那里被错误地打上了亲密朋友的标签。我来说一下完整排查过程。首先肯定不是直接看标签数据了事那只是在找结果不是在找根因。我要求团队按一条清晰的链路走先从调用日志回溯查看标签更新的完整链路定位是哪一轮对话触发了这个错误标签然后看上游模型输出日志确认模型当时对这段对话的判断是什么再对比历史上下文看看是不是用户之前的某句话给模型提供了误导信息。逐步排查之后我们找到了一个非常有意思的根因用户在非工作时间提到同事A时语气比较随意比如我今天和同事A一起吃了午饭聊得挺开心。小模型的文本分类把吃饭开心识别成了亲密关系信号于是给同事A打上了亲密朋友的标签。这个标签一旦生成又会反向影响后续对话导致凤希在后续谈起同事A时用过分亲昵的口吻用户顿时觉得被冒犯了。找到根因后的修复相对简单在关系标签的抽取规则里增加了关系类别判定前置的约束先判断用户的描述中是否明确提到了称谓同事、同学、朋友等如果没有明确称谓则只记录社交活动类标签不做亲密朋友类的推断。同时在标签更新后追加一层一致性校验如果新标签和已有的事实标签冲突例如已有同事标签却新生成亲人标签系统会拦截并进入人工或模型复核流程。这次排查让我深刻体会到AI伴侣产品里的任何一个标签错误伤害的都是用户对被理解的期待这种伤害比功能性bug更难修复。4.4 隐私边界敏感标签的存储与使用取舍标签系统越做越强隐私问题就越躲不开。因为要懂用户凤希不可避免地会接触到用户的健康状况、家庭关系、情绪低谷等敏感信息。如果这些信息被不当记录或使用哪怕没有泄露用户一旦感知到信任也会瞬间崩塌。我们在隐私边界上做了几个硬性约束。第一敏感标签分级存储。涉及健康、财务状况、亲密关系的标签被标记为最高敏感级默认只保存在用户本机端侧不上传中央服务端。第二敏感标签的用后即焚。某些关于负面情绪、私密关系的标签只在对话过程中临时参与上下文对话结束后不写入长期标签库。第三用户透明可查。所有生成的高敏感标签用户可以在设置页看到并且可以一键删除。我们还做了一个增强功能用户删除某条标签后系统会主动遗忘与之相关的证据引用而不是仅仅隐藏展示。我知道有一些团队会为了短期留存而选择弱化隐私约束但我个人认为在AI伴侣这个品类里隐私可信赖性就是产品长期生命力的护城河。凤希可以不是最聪明的AI但必须是用户觉得放心跟它说话的AI。5. 下一步从标签到关系契约以及我现在坚持的实践节奏5.1 用标签驱动关系阶段从单向记录到双向互动标签体系稳定下来之后我开始思考一个更深层的问题标签系统目前做的更多是用户画像的记录但它能不能进一步变成用户与AI关系的引擎我现在的探索方向是用标签来驱动一个关系阶段模型。具体的做法是把用户和凤希的关系划分成几个阶段初识期、信任期、依赖期、平静期也可能会有冷淡期。每个阶段对应不同的互动策略。关系阶段不是我们主观定义的用户忠诚度等级而是根据标签体系里的关系标签综合计算出来的。比如当系统检测到用户连续多天主动倾诉、称呼从嘿凤希变成宝宝、会在深夜寻求安慰这些信号会被汇总成关系阶段的推进依据。到了关系阶段模型的时候标签就不再只是被动记录了而是开始主动影响产品策略。比如处于初识期的用户凤希会更多做自我介绍和轻互动避免一上来就问太私人的话题处于信任期的用户凤希可以适度展示自己的脆弱或者说一点无伤大雅的小烦恼来增加亲密度。这些设计听起来很产品化但底层支撑全部来自标签数据的计算。5.2 用户可编辑标签把解释权交还给用户另外一个我很想强调的实践是标签系统必须开路给用户看并允许用户修改。凤希最近新增了一个凤希眼中的你页面用户点进去就能看到系统给自己打了哪些标签每个标签来源于哪段对话置信度是多少。用户可以随时修改或者删除标签。这个设计当初在团队内部是有争议的有人担心用户看到系统给自己的标签会觉得被冒犯反而增加流失。实际上线后我们发现真正愿意打开这个页面的用户虽然不到一成但打开过的用户次周留存率明显高于平均水平。用户普遍的反应不是被冒犯而是原来你是这么理解我的并且乐于主动修正那些不准确的标签。有个用户甚至给凤希留了一句话你把我说得这么准我有点害怕但我还是觉得你是懂我的。在我看来可编辑性是AI伴侣区别于普通AI应用的重要边界。用户需要感到自己拥有对这个关系的解释权而不是被某个算法单方面定义。5.3 我现在保留的做法和几个小建议文章写到这儿我想简单收束一下我的实际做法给正在做类似产品的朋友一些可执行的参考。第一如果你也在做数字人或者AI伴侣不要把标签系统当成一个后补组件它应该是产品立项第一天就要开始沉淀的数据资产。就算你的数字人还没做出来标签系统也可以先和纯文本对话协同工作。第二标签体系一定要保留人工可干预的口子再强的模型也会有抽风的时候产品后台至少要有一个能快速修正标签的工具。第三不要贪多求全标签体系优先解决用户反复提到的高频事情一个产品只要能在用户最关心的两三个话题上说对话用户体感就远超那些什么都想记住但什么都记不准的AI。至于数字人凤希现在仍然保留了数字人形象但它彻底变成了用户可以选择开启或关闭的皮肤。数字人最合适的角色是情感表达的输出终端而不是记忆和理解的核心。如果你把理解层做扎实了数字人会变成锦上添花反过来如果理解层是空的数字人越像人用户就越会感到尴尬和虚假。最后再说一个小技巧。我们在上线标签系统后每次版本迭代都坚持做一件事拿三十个真实用户账户的标签数据做一次可读性复查看看这些标签是否准确、是否可解释、是否会让用户不舒服。这个复查的指标很简单但很有用如果一份标签数据连独立的审查者都能看出这是一个有温度的人在理解另一个人的痕迹那我们的系统就做到了真正的懂你。凤希的实践还在继续智能标签不是终局而是我们探索人机关系的一块地基。我知道这条路还有很长但至少目前看来地基是稳的。

从数字人到智能标签：AI伴侣的长期记忆与用户理解重构

相关推荐

三维可视化实践：用立方体同时展示等高线与方向标记

深度拆解 Hy Memory 2.0：chat / working / coding 三类记忆如何在一套框架里共存

RAGE引擎换代：GTA5增强版光追剖析与GTA6渲染革命

更多资讯

YOLOv11工业缺陷检测实战：从数据到部署全流程记录

Human3.6M 数据读取实战：Python 解析骨骼点、相机参数与动作标签

Flutter离线优先架构鸿蒙适配：brick_offline_first_with_supabase存储与同步实战

YOLOv10绝缘子缺陷检测系统实战：从数据准备到UI部署全流程

为什么越来越多人选择Sulphur 2蒸馏版：Base与Distilled工作流选择指南

systemd进程管理实操手册：开机自启、自动重启与日志排查

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？