最近在复盘我们组做的AI原生应用时有个感受特别深生成式AI真正让用户留下来的不是生成能力本身而是“生成的内容到底是不是我的”。通用大模型什么都能写但写出来的东西放在任何人的场景里都成立也就意味着放在你的场景里完全不成立。所谓AI原生应用核心交互就是生成式AI驱动用户面对的不是一堆按钮而是一个能对话、能产出内容的智能体这时候个性化定制就从加分项变成了生死线。这篇文章想用我们做模拟项目X的实际过程来聊聊生成式AI的个性化定制到底怎么做有哪些技术路径、选型时看什么、落地会踩哪些坑、效果怎么评估。适合正在做或准备做AI原生应用的产品经理和研发同学也适合想搞清楚“为什么AI写的东西总是差点意思”的朋友。1. 从“能聊天”到“懂你”个性化定制是AI原生应用的核心命题1.1 先分清“AI原生应用”和“AppAI”这不是咬文嚼字。很多团队把应用里加一个Chat对话框就自称AI原生实际不是。像手机计算器里接一个大模型用户只是多了种输入方式产品架构和用户体验都没有重新设计这种还是传统App叠加AI功能。AI原生应用的标志是生成式AI的输出就是产品的主要界面交互流程、状态管理、内容生产都围绕模型输出设计。典型的是AI写作助手、AI工作流助手、AI知识库问答这类产品。在原生架构里用户对“生成质量”的感知会被无限放大因为没有别的功能可以补偿。通用模型生成的内容信息密度再高、文笔再好用户看完常说的还是那句——“说得都对但没法直接帮我干活”。这是因为通用模型面向的是“所有人”而用户来你的应用要解决的是“自己的事”。1.2 用户要的不是“正确答案”是“我的答案”传统个性化体验大家熟悉的是推荐算法一个候选池排序把最合适的推给你。但生成式AI里的个性化是一个完全不同的问题——它不是从有限集合里挑一个而是要在无限可能的空间里根据用户信息生成唯一合适的序列。同样是生成一条新品上市推广文案推荐算法最多帮用户选一个模板生成式AI得先知道这个品牌面向的是哪类人群、既往文案是什么语气、这轮打法重点是什么然后从头写一句不重复的话。我们当时在模拟项目X里做过一次很不成功的初版直接用通用Prompt让模型“帮电商运营生成新品上市方案”生成质量看着不错框架完整、词藻专业但运营同事反馈“这不是我们的调性”“目标人群写错了”“平台当前的活动玩法完全没提到”。这不是模型能力问题是我们的个性化做得不够。五类信号缺了四类用户画像、历史交互、外部知识库、业务规则只有实时对话上下文那一项勉强算有。那之后我们才把个性化定制正式当做一个系统工程来做而不是在Prompt后面加一句“请参考用户偏好”。提示判断一个AI原生应用的个性化做得是否到位最简单的方法是把用户姓名、公司、历史数据全部遮掉看输出内容是否还“千人一面”。如果遮掉之后几乎没区别说明个性化只是停留在话术层面。2. 个性化定制的四条技术路径与选型逻辑2.1 提示词工程最轻量但别指望它扛大梁提示词层面的个性化核心做法是把用户偏好转成若干约束条件写进系统提示词里。比如角色设定、语气要求、格式偏好、输出长度、禁止事项。我们给模拟项目X最早做的“基础版个性化”就是这一套给运营同学配置品牌角色的几句话加上“方案要包含行业洞察、目标人群、渠道策略、落地排期”这样的结构约束。改起来快、不要训练资源适合几百个用户的小规模验证。但也很快摸到了天花板。提示词是“一次性表达”模型每次都要从这句话里自己理解偏好遇到复杂的、冲突的偏好就露馅。比如用户既要求“专业严谨”又要求“简短口语”这种矛盾约束在提示词里经常互相打架。更麻烦的是它装不下长期记忆用户上周说过“这个产品线主打Z世代文案可以活泼一点”这周来写方案模型早就忘了。强行把历史记录拼进去很快就把上下文窗口塞爆。所以我把提示词个性化定位成“地基”必须有但个性化深水区在这里解决不了。2.2 RAG让生成内容建立在用户自己的知识之上RAG检索增强生成是第二条路也是我们落地最重的一条。它的思路是不要指望模型记住用户的私有信息而是把用户的知识库、历史文档、聊天记录切成块向量化存好每次请求来了先检索最相关的几段和问题拼在一起交给模型生成。这样生成出来的内容依据是用户自己的资料而不是全网平均知识。在模拟项目X里我们给用户接入了自家历史运营方案库、品牌调性文档、目标人群白皮书。效果最明显的变化是模型写“目标人群分析”时不再说“18-35岁城市年轻女性”这种空话而是能引用用户历史方案里“关注性价比、偏好国潮品牌、活跃在小红书和抖音”这些具体判断。用户反馈“这版终于看出来是懂我们这个品类的”。RAG的个性化质量很大程度取决于检索。我们一开始只用向量相似度结果经常检索到语义接近但不相关的文档片段。后面改成“关键词召回向量召回并行再给重排模型打分”相关性明显上了一个台阶。切块策略也有讲究按语义段落切比固定500字切块好得多——固定切块会把一个完整的“竞品分析”拆成两半检索到一半就等于没检索到。2.3 微调让模型表现得像你团队里的人RAG解决的是“依据”问题微调解决的是“行为”问题。有些场景里光是喂知识不够模型的表达方式、结构习惯、决策倾向都得改这时候就要用领域数据微调。比如法律文书助手、代码生成助手、医疗报告助手这些对输出格式和术语体系要求极高的场景通用模型的说话方式跟行内人格格不入加多少提示词都别扭。微调最常用的低成本方案是LoRA低秩适配不用更新全部模型权重几张卡就能跑产出一个几GB甚至几百MB的适配器文件挂在基座模型上。做微调之前一定要想清楚微调不是“往里塞事实”的手段。模型微调过程很容易把知识学错、学混事实型信息应该靠RAG去补充微调只负责改变行为风格和输出结构。我们团队给一个数据处理助手做过一次反面教材把用户手册里的大段操作说明混进微调数据模型在生成代码时经常一本正经地编造不存在的API参数。后来把事实类数据全部挪回知识库检索只保留语气、结构的示例才稳定下来。2.4 Agent与记忆系统跨对话的持续个性化AI原生应用和单轮问答最大的不同在于用户会带着目标反复来而且目标会演化。个性化也必须跟着演化。这里就轮到Agent和记忆系统登场。记忆系统要分两层讲。短期记忆是会话内的上下文这个模型本身就支持但要注意控制长度、及时摘要。长期记忆是要跨会话保存的分为两种一种叫情景记忆就是把某次对话的要点抽出来存成摘要另一种叫语义记忆是从多次交互里抽象出的用户偏好档案比如“用户偏好晚八点推送”“讨厌被动语态”“项目汇报只看风险项”。我们实践下来最好用的模式是“偏好显式化”与其让模型每次从历史里猜用户想要什么不如把从历史交互中抽取出来的高置信度偏好写成结构化档案在每次请求时注入系统提示词。这样有几个好处token可控、偏好可解释、用户可修正。我们在模拟项目X里做了一个“偏好面板”用户能看到系统记住了自己哪些习惯还能手动删除或者修改。结果很有意思那些被称为“很懂我”的评价往往发生在这个面板被用户主动编辑过之后——个性化一旦变得可见、可改信任感完全不同。四条路径的选择不是互斥的它们分别解决不同层次的问题。我们最终形成了一套组合逻辑可以看下面这个表路径解决的问题优势局限成本量级提示词工程短期约束、格式偏好改得快、零训练资源存不下长期记忆、抗冲突弱极低RAG事实与知识依据可溯源、实时更新依赖检索质量、延迟增加中微调行为风格、输出结构深度改变模型表现不适合装事实、需要数据高Agent记忆跨会话持续目标长期演化、可解释架构复杂、状态管理难中高3. 落地方案拆解模拟项目X的个性化改造全过程3.1 需求诊断通用Prompt到底缺在哪模拟项目X是一款面向电商运营人员的“新品上市策划助手”。最初上线时用的就是裸的生成式AI系统提示词只有两三句话。运营人员试用反馈集中在三类问题第一是信息缺口模型不知道品牌定位、产品卖点、目标人群这些基本背景所以生成出来的方案无法落地。第二是风格缺口品牌有自己的语气有的品牌官方严肃有的偏年轻活泼通用输出哪边都不靠。第三是策略缺口电商平台的运营有自己的节奏新品上市通常要配合平台活动节奏、竞品打法、达人投放策略通用模型不具备这些实时信息。这三个缺口恰好对应了第2节说的三条路径信息缺口用RAG解决风格缺口用微调解决策略缺口一部分靠RAG里注入业务规则文档一部分靠Agent编排流程来约束。这一步做完个性化不再是“要不要做”的问题而是“按什么层次组合做”的问题。3.2 数据侧准备语料清洗、偏好抽取和评估集构建个性化系统落地的第一道坎其实是数据。当时我们面临的是用户有历史运营方案文档、有对话记录、有采纳标记但数据又脏又散。清洗步骤我们总结为四步。第一步去隐私把所有包含用户手机号、地址、内部项目号的信息用规则加模型双重打标该脱敏的脱敏该删除的删除。第二步去重同一个方案的不同版本要归一避免模型被重复样本带偏。第三步格式统一文档里的扫描件要先走OCR表格要转成Markdown不然向量化全是乱码。第四步质量过滤太短的、乱码的、无意义的片段直接丢。偏好抽取我们用了模型辅助的方案。把用户历史成功案例被采纳、被点赞的方案喂给大模型让它按预设字段提取目标人群、品牌语气、内容长度偏好、常用结构、禁忌词。预设字段的好处是输出结构化后续好解析坏处是可能漏掉没预设到的偏好所以还要留一个“自由备注”字段人工抽检时补充。这里特别提醒一点一定要在动工之前就把评估集建好。我们从清洗后的数据里挑出一百条典型用户请求每条配好“参考方案偏好说明”之后所有技术改动都用这一套基准回归。没有这个你改完RAG参数根本说不清是变好了还是变差了。3.3 推理侧改造个性化上下文的组装策略数据准备好之后真正开发时我们发现推理侧的上下文组装比想象中更容易翻车。最初我们简单地把“用户画像JSON检索片段系统提示词用户问题”一股脑拼进Prompt结果模型经常忽略画布里靠后的信息生成结果还是偏通用。后来总结出组装顺序的三条经验。第一核心指令在最前面模型对开头的注意力最强我们要让它先明白“你是谁、输出什么结构”。第二用户数据画像、检索片段放在指令之后、用户问题之前让模型在读到具体问题时已经带着数据脑子上线。第三如果同时有多个检索片段按相关度降序排高相关片段靠前。这三点看着朴素实测对输出质量的影响非常明显。组装流程当时大概是这样的1. 读取用户长期记忆档案结构化偏好 2. 根据用户问题触发检索取Top-K知识片段 3. 组装系统提示词 - 角色与任务指令 - 个性化偏好摘要语气、长度、结构、禁忌 - 相关知识片段按相关度降序 4. 输入用户当前问题流式生成 5. 生成结束后异步更新短期/长期记忆流式输出也要专门处理。个性化检索必须在第一个token吐出来之前完成所以我们用了预取策略用户还在输入时后台先根据当前上下文跑一次轻量检索等用户真正提交检索结果已经就位响应时间能省下几百毫秒。3.4 实测效果我们量到的变化和没量到的变化改造前后我们做了一组对比测试同一批20位种子用户用同一个基座模型一边是通用Prompt一边是完整的个性化管线。结果整理如下指标通用版个性化版变化方案采纳率用户直接使用或微调后使用34%72%38个百分点平均修改轮数用户要求重写的次数3.2次1.1次-2.1次用户主动保存/收藏率21%58%37个百分点首token延迟1.1s1.6s0.5s单次生成平均成本基准43%成本上升这个结果印证了我们的判断个性化带来的核心收益不是“生成内容更漂亮”而是“更少返工”。但对延迟和成本的上升也要有预期。后来我们把用户画像缓存、把高频检索结果做了缓存延迟回升到1.3s左右成本增幅压缩到20%上下属于可接受范围。还有一类变化是表格量不出来的用户表达信任的方式变了。有几位用户开始直接在对话框里说“按老规矩来”意思是让系统基于他的历史偏好自动生成不再重复描述需求。这个信号出现的时候我们才觉得个性化真的成立了。4. 工程化过程中的五个坑与解决思路4.1 记忆塞多了模型反而变笨个性化最容易犯的错误就是什么都想记住。最开始我们天真地认为多塞历史对话更懂用户。结果上下文越拼越长模型开始被大量历史细节带跑生成内容变得啰嗦有时还会把用户某一次的临时想法当成永久偏好。解决方案是分级记忆架构。核心档案只放高置信度、经过验证的长期偏好总量控制在几十行以内情境记忆放最近几轮对话的摘要定期压缩原始对话不直接进Prompt只作为检索候选。每次写入记忆之前要有审计逻辑这条偏好置信度够不够、是否和现有信息冲突、有没有过期风险。宁可少记一点也不能乱记。举个我们真实遇到的例子一位用户某次临时说“这次方案帮我写长一点”系统把“写长方案”记成了长期偏好后面每次生成都默认展开成长篇。用户反馈“怎么越来越啰嗦”。后来在审计逻辑里加了“单次上下文触发的偏好默认只进入会话级记忆不写入长期档案”这个问题才消失。4.2 个性化效果的评测不能直接套用文本相似度指标传统生成任务常用BLEU、ROUGE这类指标衡量候选文本和参考文本的重合度。但个性化生成的特点是参考答案不唯一A用户觉得好的方案B用户可能完全不用。用相似度指标去卡会把那些“结构不同但更贴合用户需求”的结果误判为坏结果。我们的新思路是维度化评测把“好不好”拆解成可打分的动作。内容适配度看有没有覆盖用户任务目标风格一致性看口吻和用户历史是否匹配事实准确性看引用用户数据是否正确任务成功率看最终产物离“直接可用”有多远。每个维度设1到5分由评分模型加人工抽检共同完成。4.3 冷启动新用户没有历史拿什么定制个性化系统对新用户天然不友好没有历史数据画像就是空的。我们试过三种冷启动手段。第一主动收集新用户注册后用一个轻量的引导问题问目标、偏好、常用场景愿意填的人比想象中多因为用户明确知道自己想让AI记住什么。第二模板化默认配置按用户行业给一套默认画像比如电商运营默认就带“关注转化率、重视平台活动节奏”这些基础偏好后面再逐渐修正。第三渐进式个性化前几次交互只启用低强度个性化提示词RAG等积累到一定数量的历史交互后再开启记忆抽取和画像更新。冷启动期还有个心态问题不要急着向用户承诺“我懂你”让用户把预期放在“系统在逐步了解你”上反而体验更好。4.4 过度个性化会让用户陷入信息回声室只迎合用户偏好的生成短期满意度可能很高但长期会带来问题。比如我们监测到当系统一味按照用户喜爱的内容风格生成时用户对市场趋势的敏感度会下降——他们看到的世界全部经过了偏好过滤跟外界真实反馈脱节。这在决策支持类应用里风险很高。我们的对策是加入受控的多样性。在生成策略里设置一个探索率比如10%的请求会在约束中放宽一两个偏好条件让模型引入用户平时不常看的视角比如竞品打法、新兴渠道、不同人群的反馈。同时把“多样性采纳率”也纳入监测防止探索变成打扰。当然底线是不管用户怎么要求都不能生成违法违规、违背公序良俗的内容合规是硬约束。4.5 个性化的成本账每一分智能都要花钱个性化不是免费的。画像注入会推高输入token检索要额外占用计算资源微调模型需要训练和部署成本更长的上下文意味着更高的延迟。如果不做预算管理很容易出现“个性化效果好了但单用户毛利润为负”的尴尬局面。我们后来的成本控制方法是分级路由。轻量场景走提示词RAG只有高价值任务才调用微调模型画像和检索结果做缓存用户画像不是每次请求都全量注入而是根据当前任务只注入相关字段。另外把画像更新改成异步批量任务不要每次交互后都实时跑一次抽取既省成本又避免抖动。个性化要追求的是“恰到好处的懂”不是“无死角的懂”。5. 个性化定制的评测体系与持续迭代5.1 四个关键评测维度与打分标准前面反复提到维度化评测这里把细节补齐。我们在模拟项目X上试过很多评估方法最终沉淀下来的核心维度是四个内容适配度生成内容是否覆盖了用户请求的全部任务目标有没有漏掉关键要求。风格一致性输出的语气、结构、术语是否接近用户历史偏好是否符合品牌调性。事实准确性引用的用户数据、业务规则、知识库信息是否正确有没有编造。任务成功率最终产物用户能不能直接用或者只需少量修改。这是最贴近业务价值的指标。每个维度我们定义了1到5分的锚点描述。以任务成功率为例1分是“完全不能用等于从头写”3分是“框架可用但细节要改”5分是“直接采用无需修改”。锚点描述很重要否则不同评分人打出来的分没有可比性。5.2 自动化初筛加人工抽检缺一不可完全靠人工评测个性化迭代速度会被拖死完全靠自动化又容易丢掉对真实体验的判断。我们的组合是每次版本回归先用评分模型按rubric跑一遍全部测试集筛出分数异常的case然后每天抽20条真实线上对话由一位懂业务的同事人工复核并写评语。评分模型用的是更强的通用模型给它完整rubric和判断示例实测相关性跟人工评分能到0.8以上够用作初筛。比自动化打分更有价值的信号是用户主动反馈。在生成结果旁边放一个“这个结果是否可用”的按钮比让用户写评价的回收率高得多。收集到的正负样本会被整理成下一轮的评测集也会被拆解成失败模式反哺到Prompt、RAG或者微调数据的调整里。5.3 小步快跑的迭代节奏双周版本加AB实验个性化系统不适合憋大招。我们按双周一个版本的节奏每版包含两部分数据侧更新新增的用户反馈、修正的偏好档案和策略侧调整检索参数、组装顺序、探索率。每次上线前做一次全量回归上线后按用户分流做AB对比观察指标是方案采纳率、修改轮次、用户留存和个性化覆盖率。这里有一个容易被忽视的指标个性化覆盖率——即多少比例的请求在生成时实际用到了画像或知识检索。覆盖率太低说明系统的个性化只是在“形式上存在”用户感知不到。我们给自己定过目标核心场景的个性化覆盖率不低于70%低于就得排查是画像缺失还是检索触发条件太苛刻。迭代过程中印象最深的一次调整把探索率从5%调到10%短期采纳率降了3个百分点但两周后用户活跃度和方案多样性指标明显回升。这个案例告诉我们个性化评测不能只看单点指标要盯用户长期行为。6. 写在最后个性化定制真正难在哪6.1 我体会到的个性化边界做了这个项目之后我对“个性化”有了新的理解。它并不是越精准越好。过度个性化会压缩用户的信息视野让生成内容变得“正确但封闭”而真正的价值不是帮用户看到他爱看的而是帮用户更好地完成他真正要做的事。一个好的个性化系统应该是懂用户但不盲从跟随用户但保有底线。从技术角度说个性化定制最难的从来不是单点技术的调用而是把画像、检索、记忆、生成、评测这些环节串成一个有机整体。任何一个环节掉链子用户体验都会打折扣。我们踩过的坑绝大多数也都不是模型能力不够而是系统设计没跟上。6.2 下一步我想尝试的三个方向第一个是多模态个性化。现在的个性化主要围绕文本但AI原生应用很快会有图像、语音生成用户偏好在这些模态上怎么表达、怎么抽取是个新问题。第二个是用户可控个性化。我们做了偏好面板之后验证了“可见、可改”能大幅提升信任后续想让用户更细粒度地控制画像、记忆和生成策略。第三个是端侧小模型的个性化。把用户画像和微调适配器放在本地隐私数据不出设备也能定制这对隐私敏感的行业吸引力很大。如果你也在做AI原生应用我的建议是先把个性化当成一个系统工程来设计别沉溺在调Prompt和换模型里。数据、评测、迭代机制这三件事比任何单点技术都更能决定个性化定制的成败。这条路没有捷径但每一步改进用户都能实实在在地感受到。 
长河君 · 2026/10/17 8:33:54 · 阅读 1.2k AI原生应用个性化定制实战：从RAG到微调的系统工程
最近在复盘我们组做的AI原生应用时有个感受特别深生成式AI真正让用户留下来的不是生成能力本身而是“生成的内容到底是不是我的”。通用大模型什么都能写但写出来的东西放在任何人的场景里都成立也就意味着放在你的场景里完全不成立。所谓AI原生应用核心交互就是生成式AI驱动用户面对的不是一堆按钮而是一个能对话、能产出内容的智能体这时候个性化定制就从加分项变成了生死线。这篇文章想用我们做模拟项目X的实际过程来聊聊生成式AI的个性化定制到底怎么做有哪些技术路径、选型时看什么、落地会踩哪些坑、效果怎么评估。适合正在做或准备做AI原生应用的产品经理和研发同学也适合想搞清楚“为什么AI写的东西总是差点意思”的朋友。1. 从“能聊天”到“懂你”个性化定制是AI原生应用的核心命题1.1 先分清“AI原生应用”和“AppAI”这不是咬文嚼字。很多团队把应用里加一个Chat对话框就自称AI原生实际不是。像手机计算器里接一个大模型用户只是多了种输入方式产品架构和用户体验都没有重新设计这种还是传统App叠加AI功能。AI原生应用的标志是生成式AI的输出就是产品的主要界面交互流程、状态管理、内容生产都围绕模型输出设计。典型的是AI写作助手、AI工作流助手、AI知识库问答这类产品。在原生架构里用户对“生成质量”的感知会被无限放大因为没有别的功能可以补偿。通用模型生成的内容信息密度再高、文笔再好用户看完常说的还是那句——“说得都对但没法直接帮我干活”。这是因为通用模型面向的是“所有人”而用户来你的应用要解决的是“自己的事”。1.2 用户要的不是“正确答案”是“我的答案”传统个性化体验大家熟悉的是推荐算法一个候选池排序把最合适的推给你。但生成式AI里的个性化是一个完全不同的问题——它不是从有限集合里挑一个而是要在无限可能的空间里根据用户信息生成唯一合适的序列。同样是生成一条新品上市推广文案推荐算法最多帮用户选一个模板生成式AI得先知道这个品牌面向的是哪类人群、既往文案是什么语气、这轮打法重点是什么然后从头写一句不重复的话。我们当时在模拟项目X里做过一次很不成功的初版直接用通用Prompt让模型“帮电商运营生成新品上市方案”生成质量看着不错框架完整、词藻专业但运营同事反馈“这不是我们的调性”“目标人群写错了”“平台当前的活动玩法完全没提到”。这不是模型能力问题是我们的个性化做得不够。五类信号缺了四类用户画像、历史交互、外部知识库、业务规则只有实时对话上下文那一项勉强算有。那之后我们才把个性化定制正式当做一个系统工程来做而不是在Prompt后面加一句“请参考用户偏好”。提示判断一个AI原生应用的个性化做得是否到位最简单的方法是把用户姓名、公司、历史数据全部遮掉看输出内容是否还“千人一面”。如果遮掉之后几乎没区别说明个性化只是停留在话术层面。2. 个性化定制的四条技术路径与选型逻辑2.1 提示词工程最轻量但别指望它扛大梁提示词层面的个性化核心做法是把用户偏好转成若干约束条件写进系统提示词里。比如角色设定、语气要求、格式偏好、输出长度、禁止事项。我们给模拟项目X最早做的“基础版个性化”就是这一套给运营同学配置品牌角色的几句话加上“方案要包含行业洞察、目标人群、渠道策略、落地排期”这样的结构约束。改起来快、不要训练资源适合几百个用户的小规模验证。但也很快摸到了天花板。提示词是“一次性表达”模型每次都要从这句话里自己理解偏好遇到复杂的、冲突的偏好就露馅。比如用户既要求“专业严谨”又要求“简短口语”这种矛盾约束在提示词里经常互相打架。更麻烦的是它装不下长期记忆用户上周说过“这个产品线主打Z世代文案可以活泼一点”这周来写方案模型早就忘了。强行把历史记录拼进去很快就把上下文窗口塞爆。所以我把提示词个性化定位成“地基”必须有但个性化深水区在这里解决不了。2.2 RAG让生成内容建立在用户自己的知识之上RAG检索增强生成是第二条路也是我们落地最重的一条。它的思路是不要指望模型记住用户的私有信息而是把用户的知识库、历史文档、聊天记录切成块向量化存好每次请求来了先检索最相关的几段和问题拼在一起交给模型生成。这样生成出来的内容依据是用户自己的资料而不是全网平均知识。在模拟项目X里我们给用户接入了自家历史运营方案库、品牌调性文档、目标人群白皮书。效果最明显的变化是模型写“目标人群分析”时不再说“18-35岁城市年轻女性”这种空话而是能引用用户历史方案里“关注性价比、偏好国潮品牌、活跃在小红书和抖音”这些具体判断。用户反馈“这版终于看出来是懂我们这个品类的”。RAG的个性化质量很大程度取决于检索。我们一开始只用向量相似度结果经常检索到语义接近但不相关的文档片段。后面改成“关键词召回向量召回并行再给重排模型打分”相关性明显上了一个台阶。切块策略也有讲究按语义段落切比固定500字切块好得多——固定切块会把一个完整的“竞品分析”拆成两半检索到一半就等于没检索到。2.3 微调让模型表现得像你团队里的人RAG解决的是“依据”问题微调解决的是“行为”问题。有些场景里光是喂知识不够模型的表达方式、结构习惯、决策倾向都得改这时候就要用领域数据微调。比如法律文书助手、代码生成助手、医疗报告助手这些对输出格式和术语体系要求极高的场景通用模型的说话方式跟行内人格格不入加多少提示词都别扭。微调最常用的低成本方案是LoRA低秩适配不用更新全部模型权重几张卡就能跑产出一个几GB甚至几百MB的适配器文件挂在基座模型上。做微调之前一定要想清楚微调不是“往里塞事实”的手段。模型微调过程很容易把知识学错、学混事实型信息应该靠RAG去补充微调只负责改变行为风格和输出结构。我们团队给一个数据处理助手做过一次反面教材把用户手册里的大段操作说明混进微调数据模型在生成代码时经常一本正经地编造不存在的API参数。后来把事实类数据全部挪回知识库检索只保留语气、结构的示例才稳定下来。2.4 Agent与记忆系统跨对话的持续个性化AI原生应用和单轮问答最大的不同在于用户会带着目标反复来而且目标会演化。个性化也必须跟着演化。这里就轮到Agent和记忆系统登场。记忆系统要分两层讲。短期记忆是会话内的上下文这个模型本身就支持但要注意控制长度、及时摘要。长期记忆是要跨会话保存的分为两种一种叫情景记忆就是把某次对话的要点抽出来存成摘要另一种叫语义记忆是从多次交互里抽象出的用户偏好档案比如“用户偏好晚八点推送”“讨厌被动语态”“项目汇报只看风险项”。我们实践下来最好用的模式是“偏好显式化”与其让模型每次从历史里猜用户想要什么不如把从历史交互中抽取出来的高置信度偏好写成结构化档案在每次请求时注入系统提示词。这样有几个好处token可控、偏好可解释、用户可修正。我们在模拟项目X里做了一个“偏好面板”用户能看到系统记住了自己哪些习惯还能手动删除或者修改。结果很有意思那些被称为“很懂我”的评价往往发生在这个面板被用户主动编辑过之后——个性化一旦变得可见、可改信任感完全不同。四条路径的选择不是互斥的它们分别解决不同层次的问题。我们最终形成了一套组合逻辑可以看下面这个表路径解决的问题优势局限成本量级提示词工程短期约束、格式偏好改得快、零训练资源存不下长期记忆、抗冲突弱极低RAG事实与知识依据可溯源、实时更新依赖检索质量、延迟增加中微调行为风格、输出结构深度改变模型表现不适合装事实、需要数据高Agent记忆跨会话持续目标长期演化、可解释架构复杂、状态管理难中高3. 落地方案拆解模拟项目X的个性化改造全过程3.1 需求诊断通用Prompt到底缺在哪模拟项目X是一款面向电商运营人员的“新品上市策划助手”。最初上线时用的就是裸的生成式AI系统提示词只有两三句话。运营人员试用反馈集中在三类问题第一是信息缺口模型不知道品牌定位、产品卖点、目标人群这些基本背景所以生成出来的方案无法落地。第二是风格缺口品牌有自己的语气有的品牌官方严肃有的偏年轻活泼通用输出哪边都不靠。第三是策略缺口电商平台的运营有自己的节奏新品上市通常要配合平台活动节奏、竞品打法、达人投放策略通用模型不具备这些实时信息。这三个缺口恰好对应了第2节说的三条路径信息缺口用RAG解决风格缺口用微调解决策略缺口一部分靠RAG里注入业务规则文档一部分靠Agent编排流程来约束。这一步做完个性化不再是“要不要做”的问题而是“按什么层次组合做”的问题。3.2 数据侧准备语料清洗、偏好抽取和评估集构建个性化系统落地的第一道坎其实是数据。当时我们面临的是用户有历史运营方案文档、有对话记录、有采纳标记但数据又脏又散。清洗步骤我们总结为四步。第一步去隐私把所有包含用户手机号、地址、内部项目号的信息用规则加模型双重打标该脱敏的脱敏该删除的删除。第二步去重同一个方案的不同版本要归一避免模型被重复样本带偏。第三步格式统一文档里的扫描件要先走OCR表格要转成Markdown不然向量化全是乱码。第四步质量过滤太短的、乱码的、无意义的片段直接丢。偏好抽取我们用了模型辅助的方案。把用户历史成功案例被采纳、被点赞的方案喂给大模型让它按预设字段提取目标人群、品牌语气、内容长度偏好、常用结构、禁忌词。预设字段的好处是输出结构化后续好解析坏处是可能漏掉没预设到的偏好所以还要留一个“自由备注”字段人工抽检时补充。这里特别提醒一点一定要在动工之前就把评估集建好。我们从清洗后的数据里挑出一百条典型用户请求每条配好“参考方案偏好说明”之后所有技术改动都用这一套基准回归。没有这个你改完RAG参数根本说不清是变好了还是变差了。3.3 推理侧改造个性化上下文的组装策略数据准备好之后真正开发时我们发现推理侧的上下文组装比想象中更容易翻车。最初我们简单地把“用户画像JSON检索片段系统提示词用户问题”一股脑拼进Prompt结果模型经常忽略画布里靠后的信息生成结果还是偏通用。后来总结出组装顺序的三条经验。第一核心指令在最前面模型对开头的注意力最强我们要让它先明白“你是谁、输出什么结构”。第二用户数据画像、检索片段放在指令之后、用户问题之前让模型在读到具体问题时已经带着数据脑子上线。第三如果同时有多个检索片段按相关度降序排高相关片段靠前。这三点看着朴素实测对输出质量的影响非常明显。组装流程当时大概是这样的1. 读取用户长期记忆档案结构化偏好 2. 根据用户问题触发检索取Top-K知识片段 3. 组装系统提示词 - 角色与任务指令 - 个性化偏好摘要语气、长度、结构、禁忌 - 相关知识片段按相关度降序 4. 输入用户当前问题流式生成 5. 生成结束后异步更新短期/长期记忆流式输出也要专门处理。个性化检索必须在第一个token吐出来之前完成所以我们用了预取策略用户还在输入时后台先根据当前上下文跑一次轻量检索等用户真正提交检索结果已经就位响应时间能省下几百毫秒。3.4 实测效果我们量到的变化和没量到的变化改造前后我们做了一组对比测试同一批20位种子用户用同一个基座模型一边是通用Prompt一边是完整的个性化管线。结果整理如下指标通用版个性化版变化方案采纳率用户直接使用或微调后使用34%72%38个百分点平均修改轮数用户要求重写的次数3.2次1.1次-2.1次用户主动保存/收藏率21%58%37个百分点首token延迟1.1s1.6s0.5s单次生成平均成本基准43%成本上升这个结果印证了我们的判断个性化带来的核心收益不是“生成内容更漂亮”而是“更少返工”。但对延迟和成本的上升也要有预期。后来我们把用户画像缓存、把高频检索结果做了缓存延迟回升到1.3s左右成本增幅压缩到20%上下属于可接受范围。还有一类变化是表格量不出来的用户表达信任的方式变了。有几位用户开始直接在对话框里说“按老规矩来”意思是让系统基于他的历史偏好自动生成不再重复描述需求。这个信号出现的时候我们才觉得个性化真的成立了。4. 工程化过程中的五个坑与解决思路4.1 记忆塞多了模型反而变笨个性化最容易犯的错误就是什么都想记住。最开始我们天真地认为多塞历史对话更懂用户。结果上下文越拼越长模型开始被大量历史细节带跑生成内容变得啰嗦有时还会把用户某一次的临时想法当成永久偏好。解决方案是分级记忆架构。核心档案只放高置信度、经过验证的长期偏好总量控制在几十行以内情境记忆放最近几轮对话的摘要定期压缩原始对话不直接进Prompt只作为检索候选。每次写入记忆之前要有审计逻辑这条偏好置信度够不够、是否和现有信息冲突、有没有过期风险。宁可少记一点也不能乱记。举个我们真实遇到的例子一位用户某次临时说“这次方案帮我写长一点”系统把“写长方案”记成了长期偏好后面每次生成都默认展开成长篇。用户反馈“怎么越来越啰嗦”。后来在审计逻辑里加了“单次上下文触发的偏好默认只进入会话级记忆不写入长期档案”这个问题才消失。4.2 个性化效果的评测不能直接套用文本相似度指标传统生成任务常用BLEU、ROUGE这类指标衡量候选文本和参考文本的重合度。但个性化生成的特点是参考答案不唯一A用户觉得好的方案B用户可能完全不用。用相似度指标去卡会把那些“结构不同但更贴合用户需求”的结果误判为坏结果。我们的新思路是维度化评测把“好不好”拆解成可打分的动作。内容适配度看有没有覆盖用户任务目标风格一致性看口吻和用户历史是否匹配事实准确性看引用用户数据是否正确任务成功率看最终产物离“直接可用”有多远。每个维度设1到5分由评分模型加人工抽检共同完成。4.3 冷启动新用户没有历史拿什么定制个性化系统对新用户天然不友好没有历史数据画像就是空的。我们试过三种冷启动手段。第一主动收集新用户注册后用一个轻量的引导问题问目标、偏好、常用场景愿意填的人比想象中多因为用户明确知道自己想让AI记住什么。第二模板化默认配置按用户行业给一套默认画像比如电商运营默认就带“关注转化率、重视平台活动节奏”这些基础偏好后面再逐渐修正。第三渐进式个性化前几次交互只启用低强度个性化提示词RAG等积累到一定数量的历史交互后再开启记忆抽取和画像更新。冷启动期还有个心态问题不要急着向用户承诺“我懂你”让用户把预期放在“系统在逐步了解你”上反而体验更好。4.4 过度个性化会让用户陷入信息回声室只迎合用户偏好的生成短期满意度可能很高但长期会带来问题。比如我们监测到当系统一味按照用户喜爱的内容风格生成时用户对市场趋势的敏感度会下降——他们看到的世界全部经过了偏好过滤跟外界真实反馈脱节。这在决策支持类应用里风险很高。我们的对策是加入受控的多样性。在生成策略里设置一个探索率比如10%的请求会在约束中放宽一两个偏好条件让模型引入用户平时不常看的视角比如竞品打法、新兴渠道、不同人群的反馈。同时把“多样性采纳率”也纳入监测防止探索变成打扰。当然底线是不管用户怎么要求都不能生成违法违规、违背公序良俗的内容合规是硬约束。4.5 个性化的成本账每一分智能都要花钱个性化不是免费的。画像注入会推高输入token检索要额外占用计算资源微调模型需要训练和部署成本更长的上下文意味着更高的延迟。如果不做预算管理很容易出现“个性化效果好了但单用户毛利润为负”的尴尬局面。我们后来的成本控制方法是分级路由。轻量场景走提示词RAG只有高价值任务才调用微调模型画像和检索结果做缓存用户画像不是每次请求都全量注入而是根据当前任务只注入相关字段。另外把画像更新改成异步批量任务不要每次交互后都实时跑一次抽取既省成本又避免抖动。个性化要追求的是“恰到好处的懂”不是“无死角的懂”。5. 个性化定制的评测体系与持续迭代5.1 四个关键评测维度与打分标准前面反复提到维度化评测这里把细节补齐。我们在模拟项目X上试过很多评估方法最终沉淀下来的核心维度是四个内容适配度生成内容是否覆盖了用户请求的全部任务目标有没有漏掉关键要求。风格一致性输出的语气、结构、术语是否接近用户历史偏好是否符合品牌调性。事实准确性引用的用户数据、业务规则、知识库信息是否正确有没有编造。任务成功率最终产物用户能不能直接用或者只需少量修改。这是最贴近业务价值的指标。每个维度我们定义了1到5分的锚点描述。以任务成功率为例1分是“完全不能用等于从头写”3分是“框架可用但细节要改”5分是“直接采用无需修改”。锚点描述很重要否则不同评分人打出来的分没有可比性。5.2 自动化初筛加人工抽检缺一不可完全靠人工评测个性化迭代速度会被拖死完全靠自动化又容易丢掉对真实体验的判断。我们的组合是每次版本回归先用评分模型按rubric跑一遍全部测试集筛出分数异常的case然后每天抽20条真实线上对话由一位懂业务的同事人工复核并写评语。评分模型用的是更强的通用模型给它完整rubric和判断示例实测相关性跟人工评分能到0.8以上够用作初筛。比自动化打分更有价值的信号是用户主动反馈。在生成结果旁边放一个“这个结果是否可用”的按钮比让用户写评价的回收率高得多。收集到的正负样本会被整理成下一轮的评测集也会被拆解成失败模式反哺到Prompt、RAG或者微调数据的调整里。5.3 小步快跑的迭代节奏双周版本加AB实验个性化系统不适合憋大招。我们按双周一个版本的节奏每版包含两部分数据侧更新新增的用户反馈、修正的偏好档案和策略侧调整检索参数、组装顺序、探索率。每次上线前做一次全量回归上线后按用户分流做AB对比观察指标是方案采纳率、修改轮次、用户留存和个性化覆盖率。这里有一个容易被忽视的指标个性化覆盖率——即多少比例的请求在生成时实际用到了画像或知识检索。覆盖率太低说明系统的个性化只是在“形式上存在”用户感知不到。我们给自己定过目标核心场景的个性化覆盖率不低于70%低于就得排查是画像缺失还是检索触发条件太苛刻。迭代过程中印象最深的一次调整把探索率从5%调到10%短期采纳率降了3个百分点但两周后用户活跃度和方案多样性指标明显回升。这个案例告诉我们个性化评测不能只看单点指标要盯用户长期行为。6. 写在最后个性化定制真正难在哪6.1 我体会到的个性化边界做了这个项目之后我对“个性化”有了新的理解。它并不是越精准越好。过度个性化会压缩用户的信息视野让生成内容变得“正确但封闭”而真正的价值不是帮用户看到他爱看的而是帮用户更好地完成他真正要做的事。一个好的个性化系统应该是懂用户但不盲从跟随用户但保有底线。从技术角度说个性化定制最难的从来不是单点技术的调用而是把画像、检索、记忆、生成、评测这些环节串成一个有机整体。任何一个环节掉链子用户体验都会打折扣。我们踩过的坑绝大多数也都不是模型能力不够而是系统设计没跟上。6.2 下一步我想尝试的三个方向第一个是多模态个性化。现在的个性化主要围绕文本但AI原生应用很快会有图像、语音生成用户偏好在这些模态上怎么表达、怎么抽取是个新问题。第二个是用户可控个性化。我们做了偏好面板之后验证了“可见、可改”能大幅提升信任后续想让用户更细粒度地控制画像、记忆和生成策略。第三个是端侧小模型的个性化。把用户画像和微调适配器放在本地隐私数据不出设备也能定制这对隐私敏感的行业吸引力很大。如果你也在做AI原生应用我的建议是先把个性化当成一个系统工程来设计别沉溺在调Prompt和换模型里。数据、评测、迭代机制这三件事比任何单点技术都更能决定个性化定制的成败。这条路没有捷径但每一步改进用户都能实实在在地感受到。