简介在个性化推荐与智能客服场景中用户画像的精准度直接决定业务效果。传统规则与机器学习模型在处理非结构化文本时难以理解语义、识别隐含情绪导致画像标签粗糙且滞后。大语言模型LLM凭借强大的语义理解与上下文推理能力为智能用户画像带来了新思路。本文从多源数据融合出发讲解如何将结构化特征与非结构化文本高效喂给LLM并拆解情感识别、消费习惯挖掘、价值观推断等核心模块的实现细节同时针对动态标签生成、幻觉控制、成本优化与效果评估给出可落地的工程方案。这套方法论不仅适用于电商与内容平台也可为智能客服、用户行为分析等场景提供直接参考让数据真正转化为可信任、可行动的用户洞察。1. 这个系统不是拍脑袋想出来的传统用户画像卡在哪儿了先交代一下背景。我之前在电商和内容平台都做过用户画像相关的工作从最早的规则标签到后来的机器学习打分模型前前后后折腾了七八年。最近这一年多我把大语言模型引入到画像系统里做出了一个基于LLM的智能用户画像分析系统覆盖客户画像、用户行为分析、情感识别、消费习惯挖掘、价值观推断和动态标签生成这几个模块。这篇文章就把整个系统从设计到落地的完整过程拆开讲一遍包括我踩过的坑和最后稳定运行的方案。先说为什么要用大语言模型来做这件事。过去我们做用户画像主流做法是两条路一条是纯粹的规则体系比如用户点了某个商品类目三次以上就给他打一个喜欢3C数码的标签另一条是浅层的机器学习模型比如用逻辑回归或者GBDT预测用户的购买意愿分数。这两条路在数据量小、场景固定的情况下够用但一旦数据来源变多、涉及文本语义理解问题就来了。传统的标签体系有一个硬伤它只能处理结构化字段。用户的年龄、性别、消费金额、访问次数这些是结构化的直接进规则引擎或者模型特征矩阵都没问题。但用户留下的真正有价值的信息其实藏在非结构化数据里——客服聊天记录、商品评价、论坛发言、社交媒体的评论这些文本数据才是理解用户真实意图的关键。过去我们处理这些文本的方式特别笨先分好词再统计高频词然后用TF-IDF或者Word2Vec转化成向量。这样做的结果就是你只能知道用户说了什么词但无法理解用户想表达什么。举个例子。一个用户在售后工单里写东西还行就是发货速度真的让我有点无语。传统的关键词提取会抓出发货速度和无语这两个词然后打上物流敏感的标签。但这个用户真的是对物流不满意吗如果结合上下文看他之前买过三次东西都选的普通快递这次也是因为急着用才抱怨那这个标签就不够准确。更深一层的问题是这种文本分析根本没办法识别反讽、对比、隐含态度这些复杂情绪更不用说去推断用户的价值观和生活方式了。这就是我决定引入大语言模型的原因。LLM最核心的能力是语义理解和上下文推理它能把一段零散的文本还原成有逻辑的意图和情感还能跨文本地总结用户的一致性偏好。用一个大模型作为画像分析的中枢配合传统的结构化处理管线整个系统的画像维度、准确度和动态响应能力都有了质的提升。这篇文章不打算只讲原理和架构图我会把每个模块的实现细节、Prompt设计思路、数据融合方案以及我在实践中调整过的参数都写出来。如果你正在做用户画像、用户行为分析、智能客服、个性化推荐或者手里有一堆用户文本却不知道如何挖掘价值这篇文章应该能给你一套可以直接上手的思路。2. 多源数据融合结构化与非结构化数据怎么喂给LLM做画像系统第一步遇到的永远是数据问题。标题里写了多源数据融合和结构化与非结构化数据这两个词看着简单实际操作起来非常容易出现两套数据各跑各的、最后没法合并的窘境。我在第一个版本就犯了这个错误所以这里单独拿出来详细讲。2.1 结构化数据的ETL管道设计先说结构化数据。这部分主要包括用户注册信息性别、年龄、地域、行为日志浏览、点击、下单、加购、交易数据消费金额、频次、品类分布、客服工单类型、处理状态、处理时长等。这些数据的格式相对规整字段名、类型、取值逻辑都是确定的处理起来最稳妥的方式就是走传统的ETL管道。我的方案是用Airflow做任务调度数据从业务库同步到数据仓库的ODS层然后经过清洗、标准化、宽表拼接最终落到一个叫 user_feature_wide 的宽表里。宽表按 user_id 做主键每行对应用户的全量结构化特征。具体来说我在宽表里维护了以下几个维度基础属性年龄、性别、城市等级、注册时长、会员等级消费特征近30天消费金额、近90天消费频次、客单价分位、品类偏好Top3、价格敏感度分位行为特征近7天活跃天数、平均停留时长、核心页面访问次数、搜索频次、加购转化率服务特征近90天投诉次数、平均响应时长、售后工单类型占比这批特征的产出频率是每天早上跑一次全量、每两小时跑一次增量。宽表的产出结果会写入两个下游一个是给传统算法模型用的特征存储另一个是给LLM用的上下文输入。注意这里我就已经埋了一个伏笔——结构化数据不是直接丢给LLM的而是要先做一层语义化加工后面会具体讲。2.2 非结构化数据的清洗、切分与嵌入非结构化数据是这套系统相比传统画像多出来的关键增量。来源包括商品评价、客服对话记录、用户问卷调查、论坛/社区发言、舆情评论等。这些数据有几个特点格式混乱有长段落、有碎片、有表情符号、口语化严重、存在大量指代和不完整表达。我的处理流程分四步第一步是清洗。去掉HTML标签、无意义符号、乱码、广告夹杂的内容。这里有一个比较细节的点不要过度清洗。很多人做文本清洗时会把标点、数字全部去掉这对于分词任务可能是合理的但对于LLM来说标点和数字往往承载着情感强化的作用。比如这东西太慢了和这东西太慢了情感强度完全不同。所以我只做基础去噪保留标点和数字的原始状态。第二步是IDF筛选和分段。先统计一下所有文本的总量如果一个用户在所有数据源里的文本加起来超过一定长度比如超过2000字就按语义段落切分成多个chunk。切分的时候要保证每个chunk是一个相对完整的语义单元不能把一句话拦腰切断。我用的是滑动窗口 句号分隔符的双重策略窗口大小为800字、重叠128字。第三步是向量化嵌入。我最初用的是text-embedding-ada-002后来切换到更便宜且效果接近的bge-large-zh。对于中文场景bge系列的稳定性比OpenAI的嵌入模型更让人放心。嵌入后的向量统一存到向量数据库里同时存储原始文本和对应的元数据用户ID、来源渠道、时间戳。第四步是建立用户级别的文本聚合视图。这一步很关键。向量数据库存的是chunk级的索引用于后续的检索但画像系统还需要一个用户维度的聚合理解。我会把同一个用户的所有文本按时间排序拼接成一份用户文本档案这份档案会在后续的画像生成中被LLM整体读取。2.3 融合层为什么不能直接把原始数据全塞给LLM这是我在架构设计上做得最纠结也最值得说的一点。刚开始我试过一种简单粗暴的方案把用户宽表的所有字段加上所有文本记录拼成一个巨大的JSON然后一次性丢给LLM让它自由发挥生成画像。结果惨不忍睹——Token消耗巨大、响应延迟高、生成结果不稳定而且经常出现幻觉比如明明用户没有买过母婴商品LLM却因为某个上下文片段推断出该用户可能已为人父母。后来我总结出正确的融合方式不是把数据都塞给LLM而是先由前置模块加工成LLM友好的输入。结构化数据经过统计分析后变成一个高度浓缩的画像摘要非结构化数据则通过检索或者总结得到一个观点摘要。LLM拿到的是这两份摘要加上一小部分关键的原始引用而不是海量的原始记录。具体而言我设计了一个 query_rewriter 模块它负责根据当前画像任务比如这次要分析情感还是推断价值观从宽表和文本聚合视图中有选择地提取最相关的信息拼装成上下文。这个方案的核心思想是数据量越大越要靠信息筛选而不是全文搬运来保证结果质量。2.4 数据更新的节奏实时与批量的取舍多源数据有一个容易被忽视的问题数据的时效性不一致。交易数据是秒级产生的客服文本是事件驱动的情感态度则可能随着时间变化。如果所有数据都按同一频率更新要么浪费计算资源要么导致画像滞后。我的方案是分级更新策略。行为类指标活跃、浏览走准实时通道Kafka接入后5分钟刷新一次交易类指标走小时级文本画像标签走天级价值观、生活方式这类稳定性高的标签走周级。这样既控制了成本又能保证高时效性特征不拖后腿。这里有一个经验不要为了追求实时画像而把所有标签都实时化。价值观、消费风格、兴趣偏好这类标签本来就是一个相对稳定的量你实时刷新100次结论也不会变只是白白消耗算力。真正需要实时的是当前意图比如用户正在看什么、准备买什么这个另建一套实时通道来管就好。3. 画像能力拆解情感识别、消费习惯挖掘、价值观推断的实现细节这一节是整套系统的核心部分。标题里列了客户画像、用户行为分析、情感识别、消费习惯挖掘、价值观推断、动态标签生成这几个子能力我逐个讲实现方式和Prompt工程细节。3.1 情感识别比正负二分类多走一步很多团队做情感分析止步于正面/负面二分类顶多再加一个中性。但做用户画像时这种粗粒度的情感远远不够。用户说质量还行和用户说质量惊艳都归类为正面但两者映射到用户心智和复购行为上完全不同。我在系统里用的是六分类的细粒度情感体系认可、期待、不满、失望、愤怒、平静。前两种是正向情感中间两种是负向情感但强度有差异愤怒是强负向需要拉响服务预警平静则是中性但往往意味着低卷入度。Prompt的设计上我要求模型输出JSON格式的结果包含情感类别、情感强度1~10、触发原因、涉及的实体对象。这里贴一下我实际在用的Prompt模板已经做了脱敏和简化你是一个专业的用户情感分析助手。请分析以下用户文本的情感倾向。 要求 1. 从以下类别中选择最匹配的一个认可、期待、不满、失望、愤怒、平静 2. 给出情感强度评分1-10分分数越高代表情感越强烈 3. 用一句话说明触发该情感的具体原因 4. 提取文本中涉及的实体对象如商品、服务、物流、客服等 输出格式严格JSON {sentiment: 类别, intensity: 分数, reason: 原因, entities: [实体1, 实体2]} 用户文本 {text}这个Prompt看起来简单但有几个细节值得注意。第一输出格式限定为JSON这能大幅降低后续解析成本第二要求模型给出触发原因这个原因本身就能作为画像中的证据字段方便后续核查第三实体对象的提取为后续的品类偏好分析做了铺垫。实测效果在人工标注的2000条测试集上六分类的准确率在82%左右强度评分的平均绝对误差约为0.7。相比我之前用BERT微调做三分类的方案准确率提升了大约5个百分点而且泛化能力更好遇到新品类、新表述方式时不会轻易翻车。3.2 消费习惯挖掘从订单数据到行为模式的解释性总结消费习惯挖掘是这类系统里跟业务指标结合最紧的部分。传统做法是统计用户在各品类的消费占比、价格区间分布、购买时段分布然后贴上一堆高价值用户价格敏感型的标签。但这样做出来的标签解释力很弱运营同学看到高价值用户四个字依然不知道该怎么跟用户沟通。我的思路是用LLM来做解释性总结。先让统计模块产出结构化的消费指标——品类偏好Top3、价格带分布、购买时间分布、大促参与度、优惠券使用率、退货率等然后把这些指标以JSON的形式提供给LLM让它生成一段连贯的用户消费习惯描述。以我实际得到的输出为例对于一位用户系统生成的结果是这样的该用户近90天的消费集中在美妆和个护品类客单价处于中高水平200-400元区间对套装类商品偏好明显。用户有明显的价格敏感行为购买决策前通常会对比3-5个同品类商品优惠券使用率高达78%。值得注意的是用户晚22点至24点时段的购买占比超过40%属于典型的夜间决策型消费者。这段话的效率非常高。它不仅是几个标签的堆砌还给出了消费场景的画像和潜在的行动建议——晚间时段推送、重视性价比验证环节这些都是做营销干预时可以直接使用的信息。实现上有几个提速技巧。一是用结构化指标直出文本不要让LLM自己看流水数据否则又贵又慢二是把常见的消费模式总结做成少量样本示例放进Prompt里引导输出风格保持一致三是对近30天无消费记录的用户在Prompt里强制要求标注近期活跃度下降避免模型产出与事实冲突的结论。3.3 价值观推断最有争议也最有价值的模块价值观推断是这套系统里最具智能感的部分也是最容易做砸的部分。为什么这么说因为价值观不像消费行为那样有明确的统计信号它需要从用户的言论、选择、偏好中做归纳和推理出错风险很高。我的实现思路是不做判断只做归纳。具体来说系统不直接输出该用户属于某某类型人群这样的判断性标签而是输出该用户在以下维度上表现出稳定的倾向每一个倾向都附带证据文本。Prompt的引导词大概是这样请基于用户的文本记录归纳该用户在以下几个方面表现出的稳定倾向 1. 对品质与服务的要求层级 2. 对新事物的接受程度 3. 对品牌的态度品牌忠诚 vs 功能导向 4. 生活方式取向效率优先 vs 体验优先 要求 - 只归纳有文本证据支撑的倾向不要推测用户的身份、职业、收入等敏感属性 - 每个倾向标注证据引用原文片段 - 如果没有足够证据请明确输出证据不足这个设计有两点考虑。第一用倾向替代标签在表达上更严谨也更容易被业务方接受第二强制要求证据引用和证据不足的存在就是为了抑制LLM的过度推测倾向。实测初期不做这个约束时模型经常脑补出用户的职业和家庭情况比如从买了一次母婴用品就推断用户是宝妈这显然是危险且不准确的。价值观推断这个模块上线后我最常收到的反馈是它生成的用户描述比传统标签更容易让一线的运营同事产生认同感。因为传统标签只是高活跃“高消费”这类冷冰冰的词而LLM生成的内容更像一个真正理解用户的人写的用户小传。3.4 用户行为分析把行为序列翻译成用户语言用户行为分析我用了另一个思路——把行为序列转成自然语言事件流然后让LLM做模式识别。传统的用户行为分析用序列挖掘算法比如PrefixSpan、FP-Growth找频繁模式但找到的模式往往是浏览A→浏览B→购买C这种可读性很差的结构。我的方案分两步。第一步用一个行为翻译器把原始行为日志转成事件描述比如原生日志{event: detail_view, sku: 12345, category: 手机, duration: 45}翻译后文本用户在22:13分查看了一款手机商品详情页停留45秒第二步把用户一段窗口时间内的所有事件文本交给LLM让它识别行为模式。系统会输出类似这样的分析用户有明确的目标导向型购买行为决策链路集中在对比阶段通常会在3天内完成从浏览到购买的转化但容易受到评价中负面信息的影响而在最后一步放弃。这种分析的价值在于它不只能回答用户做了什么还能回答用户的行为路径说明了什么。这一点是传统序列挖掘很难做到的。实际应用的时候这套行为分析的结果会被用来做流失预警和干预触发比如识别出连续多次放弃结算的用户自动触发客服关怀任务。4. 动态标签生成从静态标签到有生命周期、有证据链的标签用户画像的最终呈现形态是标签。市面上大多数标签系统都是静态的打上去就是打上去了几个月不动。这种静态标签的问题在于用户的兴趣和意图会漂移很多标签等到真正使用时已经过时了。我在这个系统里设计了动态标签生成机制核心是给每个标签加上生命周期和证据链。4.1 标签体系的层级结构与生成逻辑我把标签分成三个层级基础标签、业务标签、推理标签。基础标签直接来自结构化数据比如女性北京30-35岁注册时长大于2年这类标签不需要LLM参与用规则就能处理我保留它们在传统管线里生产。业务标签是运营视角的概念标签比如高潜力转化用户价格敏感型夜间活跃内容创作者偏好这些标签由LLM综合结构化特征和文本特征生成带有一定的业务解释性。推理标签是LLM综合判断后的深层标签比如品质生活导向家庭决策型消费者品牌忠诚度高这类标签不直接依赖某个指标而是通过对多源信息的归纳推理得出。标签生成不是一步到位的。我的系统采用两阶段生成第一阶段LLM基于用户所有的上下文信息生成候选标签列表和证据文本第二阶段一个校验模块对候选标签做合法性检查过滤掉敏感标签、证据不足的标签和与基础事实冲突的标签然后才写入标签库。4.2 标签的置信度、生命周期与自动化更新每个标签在入库时都带着四个字段置信度分数、证据引用、首次生成时间、最后更新时间。置信度由LLM生成时的自评分和规则校验结果共同决定低于阈值的标签只留在候选区不进入正式的用户画像接口。生命周期管理是动态标签的核心。我的策略是行为驱动的标签更新优先时间驱动的标签衰减为辅。具体来说当用户产生新行为时触发相关标签的更新如果某标签长期没有被触发置信度会按时间衰减。衰减系数我调成了平滑线性衰减90天内无激活的标签置信度减半180天无激活的标签自动降级为候选标签等待重新验证。这套机制解决了一个很现实的问题画像系统的标签不再越积越多、越来越脏。我见过很多团队做画像做了两三年标签库膨胀到几万个大量标签互相矛盾实际可用率不到一半。有了生命周期管理之后标签库维持在相对精简的状态每个标签都有存活依据使用方也更容易信任系统输出。4.3 标签解释性设计给业务方一个宁可展示证据的界面标签系统的最后一个拦路虎是业务方的信任问题。运营同学和客服同学天然不信任一个黑盒标签他们会问为什么系统说这个用户是价格敏感型依据是什么我因此在标签管理的输出接口里加入了一个证据展示字段。每个标签输出时都附带上证据链——具体的数据指标或者文本片段引用。业务侧查看的时候可以直接看到依据用户原文再便宜点我就下单了比了好几家了这样的支撑信息。这个改动看起来很小但对系统落地帮助巨大。信任感上来了系统使用率自然就上去了画像数据也才能真正驱动业务的精细化运营。5. 上线之后的坑幻觉控制、成本控制、评估方法论这一节是实战经验的集中展示。再漂亮的架构跑到生产环境都会遇到一堆文档里不会写的问题。我挑几个典型的来讲。5.1 幻觉问题LLM会一本正经地编造用户特征幻觉是LLM应用到画像场景最危险的问题。我遇到过一个典型案例一位用户只买过一次宠物用品LLM在生成标签时写了该用户养了一只柯基犬。这个结论是怎么来的因为用户的某条评价里出现了我家狗子这个口语化表达而训练语料里柯基和狗子的关联度太高模型就自行脑补了品种信息。这类幻觉如果不加控制后果很严重。一是画像失真二是如果业务方拿着错误标签去做营销比如给用户推送狗粮用户根本不需要反而造成体验损伤。我总结了三道防线的控制方案。第一道防线是Prompt层明确要求模型只能基于提供的文本做推断不得补充背景知识第二道防线是证据校验标签的生成必须附带证据引用如果证据无法从原文中定位标签直接丢弃第三道防线是结果审核对生成画像做抽样人工复核统计幻觉率作为监控指标一旦超过阈值就触发告警。这三道防线并不能完全消灭幻觉但能把影响降到可接受的范围。我现在系统里的幻觉率控制在3%以内且大多集中在低风险标签上影响有限。5.2 成本控制Token消耗的优化策略LLM做画像的Token消耗是传统算法不需要考虑的额外成本。一开始我把所有用户的全部文本都塞给模型分析一个月下来账单数字相当惊人。后来做了三个优化成本下降到原来的四分之一。第一把固定不变的内容移到System Prompt里。用户画像的任务说明和输出格式是每次调用都一样的这部分放入System Prompt可以稳定复用不用重复计费到每次的上下文里。第二做文本预筛选。不是所有文本都值得给LLM分析。我先用低成本的关键词匹配和情感得分初筛一遍只把信息密度高、情感强度高的文本喂给LLM。纯寒暄类的客服对话、毫无信息量的评论直接跳过。第三引入缓存层。用LLM生成的画像结果按用户时间窗口做缓存同一个用户在短时间内重复请求画像时直接命中缓存不重新调用模型。画像本身就是低频变动的数据缓存命中率只要做得好收益非常可观。5.3 画像质量的评估方法论最后一个坑是如何评估画像做得好不好。传统标签的评估可以用准确率、覆盖率这些指标但LLM生成的描述性画像没有唯一的标准答案很难做自动化评估。我的做法是构建了两套评估体系。第一套是从业务效果侧的A/B测试把画像结果用于实际的运营策略——比如用画像做个性化Push的文案优化、商品推荐的排序调整——然后对比实验组的点击率、转化率、客单价等业务指标。这是最客观的评估毕竟画像系统的最终价值还是要落到业务指标的提升上。第二套是定期的模型输出人工盲评。把LLM生成的画像和传统算法生成的画像混合在一起让业务侧的同学盲评从准确性丰富度行动指导性三个维度打分。这套评估虽然耗时但能发现很多自动化指标发现不了的问题比如生成内容模板化、过于泛泛而谈、缺乏个性化的现象。目前系统稳定运行了大半年画像的月活调用量在千万级别业务侧的核心转化指标相比使用传统画像系统时提升了约12%。这个提升当然不只是画像系统的功劳但它至少说明一点让LLM参与用户画像分析方向是对的关键是把工程细节做扎实。最后再分享一个我个人操作中的小技巧。很多人用LLM做用户分析习惯一次性把所有任务丢给模型让它既做情感分类又做消费总结又做价值观推断结果每个任务都做得不够好。我的建议是拆分成独立的调用链路每个模块专注一件事模块之间用数据管道串联。虽然调用次数多了、整体延迟变长了但每个环节的质量都更容易保证和迭代——工程上宁要多个小步的确定性也不要一个大步的碰运气。本文还有配套的精品资源点击获取
基于LLM的智能用户画像系统：从多源数据到动态标签的工程实践
简介在个性化推荐与智能客服场景中用户画像的精准度直接决定业务效果。传统规则与机器学习模型在处理非结构化文本时难以理解语义、识别隐含情绪导致画像标签粗糙且滞后。大语言模型LLM凭借强大的语义理解与上下文推理能力为智能用户画像带来了新思路。本文从多源数据融合出发讲解如何将结构化特征与非结构化文本高效喂给LLM并拆解情感识别、消费习惯挖掘、价值观推断等核心模块的实现细节同时针对动态标签生成、幻觉控制、成本优化与效果评估给出可落地的工程方案。这套方法论不仅适用于电商与内容平台也可为智能客服、用户行为分析等场景提供直接参考让数据真正转化为可信任、可行动的用户洞察。1. 这个系统不是拍脑袋想出来的传统用户画像卡在哪儿了先交代一下背景。我之前在电商和内容平台都做过用户画像相关的工作从最早的规则标签到后来的机器学习打分模型前前后后折腾了七八年。最近这一年多我把大语言模型引入到画像系统里做出了一个基于LLM的智能用户画像分析系统覆盖客户画像、用户行为分析、情感识别、消费习惯挖掘、价值观推断和动态标签生成这几个模块。这篇文章就把整个系统从设计到落地的完整过程拆开讲一遍包括我踩过的坑和最后稳定运行的方案。先说为什么要用大语言模型来做这件事。过去我们做用户画像主流做法是两条路一条是纯粹的规则体系比如用户点了某个商品类目三次以上就给他打一个喜欢3C数码的标签另一条是浅层的机器学习模型比如用逻辑回归或者GBDT预测用户的购买意愿分数。这两条路在数据量小、场景固定的情况下够用但一旦数据来源变多、涉及文本语义理解问题就来了。传统的标签体系有一个硬伤它只能处理结构化字段。用户的年龄、性别、消费金额、访问次数这些是结构化的直接进规则引擎或者模型特征矩阵都没问题。但用户留下的真正有价值的信息其实藏在非结构化数据里——客服聊天记录、商品评价、论坛发言、社交媒体的评论这些文本数据才是理解用户真实意图的关键。过去我们处理这些文本的方式特别笨先分好词再统计高频词然后用TF-IDF或者Word2Vec转化成向量。这样做的结果就是你只能知道用户说了什么词但无法理解用户想表达什么。举个例子。一个用户在售后工单里写东西还行就是发货速度真的让我有点无语。传统的关键词提取会抓出发货速度和无语这两个词然后打上物流敏感的标签。但这个用户真的是对物流不满意吗如果结合上下文看他之前买过三次东西都选的普通快递这次也是因为急着用才抱怨那这个标签就不够准确。更深一层的问题是这种文本分析根本没办法识别反讽、对比、隐含态度这些复杂情绪更不用说去推断用户的价值观和生活方式了。这就是我决定引入大语言模型的原因。LLM最核心的能力是语义理解和上下文推理它能把一段零散的文本还原成有逻辑的意图和情感还能跨文本地总结用户的一致性偏好。用一个大模型作为画像分析的中枢配合传统的结构化处理管线整个系统的画像维度、准确度和动态响应能力都有了质的提升。这篇文章不打算只讲原理和架构图我会把每个模块的实现细节、Prompt设计思路、数据融合方案以及我在实践中调整过的参数都写出来。如果你正在做用户画像、用户行为分析、智能客服、个性化推荐或者手里有一堆用户文本却不知道如何挖掘价值这篇文章应该能给你一套可以直接上手的思路。2. 多源数据融合结构化与非结构化数据怎么喂给LLM做画像系统第一步遇到的永远是数据问题。标题里写了多源数据融合和结构化与非结构化数据这两个词看着简单实际操作起来非常容易出现两套数据各跑各的、最后没法合并的窘境。我在第一个版本就犯了这个错误所以这里单独拿出来详细讲。2.1 结构化数据的ETL管道设计先说结构化数据。这部分主要包括用户注册信息性别、年龄、地域、行为日志浏览、点击、下单、加购、交易数据消费金额、频次、品类分布、客服工单类型、处理状态、处理时长等。这些数据的格式相对规整字段名、类型、取值逻辑都是确定的处理起来最稳妥的方式就是走传统的ETL管道。我的方案是用Airflow做任务调度数据从业务库同步到数据仓库的ODS层然后经过清洗、标准化、宽表拼接最终落到一个叫 user_feature_wide 的宽表里。宽表按 user_id 做主键每行对应用户的全量结构化特征。具体来说我在宽表里维护了以下几个维度基础属性年龄、性别、城市等级、注册时长、会员等级消费特征近30天消费金额、近90天消费频次、客单价分位、品类偏好Top3、价格敏感度分位行为特征近7天活跃天数、平均停留时长、核心页面访问次数、搜索频次、加购转化率服务特征近90天投诉次数、平均响应时长、售后工单类型占比这批特征的产出频率是每天早上跑一次全量、每两小时跑一次增量。宽表的产出结果会写入两个下游一个是给传统算法模型用的特征存储另一个是给LLM用的上下文输入。注意这里我就已经埋了一个伏笔——结构化数据不是直接丢给LLM的而是要先做一层语义化加工后面会具体讲。2.2 非结构化数据的清洗、切分与嵌入非结构化数据是这套系统相比传统画像多出来的关键增量。来源包括商品评价、客服对话记录、用户问卷调查、论坛/社区发言、舆情评论等。这些数据有几个特点格式混乱有长段落、有碎片、有表情符号、口语化严重、存在大量指代和不完整表达。我的处理流程分四步第一步是清洗。去掉HTML标签、无意义符号、乱码、广告夹杂的内容。这里有一个比较细节的点不要过度清洗。很多人做文本清洗时会把标点、数字全部去掉这对于分词任务可能是合理的但对于LLM来说标点和数字往往承载着情感强化的作用。比如这东西太慢了和这东西太慢了情感强度完全不同。所以我只做基础去噪保留标点和数字的原始状态。第二步是IDF筛选和分段。先统计一下所有文本的总量如果一个用户在所有数据源里的文本加起来超过一定长度比如超过2000字就按语义段落切分成多个chunk。切分的时候要保证每个chunk是一个相对完整的语义单元不能把一句话拦腰切断。我用的是滑动窗口 句号分隔符的双重策略窗口大小为800字、重叠128字。第三步是向量化嵌入。我最初用的是text-embedding-ada-002后来切换到更便宜且效果接近的bge-large-zh。对于中文场景bge系列的稳定性比OpenAI的嵌入模型更让人放心。嵌入后的向量统一存到向量数据库里同时存储原始文本和对应的元数据用户ID、来源渠道、时间戳。第四步是建立用户级别的文本聚合视图。这一步很关键。向量数据库存的是chunk级的索引用于后续的检索但画像系统还需要一个用户维度的聚合理解。我会把同一个用户的所有文本按时间排序拼接成一份用户文本档案这份档案会在后续的画像生成中被LLM整体读取。2.3 融合层为什么不能直接把原始数据全塞给LLM这是我在架构设计上做得最纠结也最值得说的一点。刚开始我试过一种简单粗暴的方案把用户宽表的所有字段加上所有文本记录拼成一个巨大的JSON然后一次性丢给LLM让它自由发挥生成画像。结果惨不忍睹——Token消耗巨大、响应延迟高、生成结果不稳定而且经常出现幻觉比如明明用户没有买过母婴商品LLM却因为某个上下文片段推断出该用户可能已为人父母。后来我总结出正确的融合方式不是把数据都塞给LLM而是先由前置模块加工成LLM友好的输入。结构化数据经过统计分析后变成一个高度浓缩的画像摘要非结构化数据则通过检索或者总结得到一个观点摘要。LLM拿到的是这两份摘要加上一小部分关键的原始引用而不是海量的原始记录。具体而言我设计了一个 query_rewriter 模块它负责根据当前画像任务比如这次要分析情感还是推断价值观从宽表和文本聚合视图中有选择地提取最相关的信息拼装成上下文。这个方案的核心思想是数据量越大越要靠信息筛选而不是全文搬运来保证结果质量。2.4 数据更新的节奏实时与批量的取舍多源数据有一个容易被忽视的问题数据的时效性不一致。交易数据是秒级产生的客服文本是事件驱动的情感态度则可能随着时间变化。如果所有数据都按同一频率更新要么浪费计算资源要么导致画像滞后。我的方案是分级更新策略。行为类指标活跃、浏览走准实时通道Kafka接入后5分钟刷新一次交易类指标走小时级文本画像标签走天级价值观、生活方式这类稳定性高的标签走周级。这样既控制了成本又能保证高时效性特征不拖后腿。这里有一个经验不要为了追求实时画像而把所有标签都实时化。价值观、消费风格、兴趣偏好这类标签本来就是一个相对稳定的量你实时刷新100次结论也不会变只是白白消耗算力。真正需要实时的是当前意图比如用户正在看什么、准备买什么这个另建一套实时通道来管就好。3. 画像能力拆解情感识别、消费习惯挖掘、价值观推断的实现细节这一节是整套系统的核心部分。标题里列了客户画像、用户行为分析、情感识别、消费习惯挖掘、价值观推断、动态标签生成这几个子能力我逐个讲实现方式和Prompt工程细节。3.1 情感识别比正负二分类多走一步很多团队做情感分析止步于正面/负面二分类顶多再加一个中性。但做用户画像时这种粗粒度的情感远远不够。用户说质量还行和用户说质量惊艳都归类为正面但两者映射到用户心智和复购行为上完全不同。我在系统里用的是六分类的细粒度情感体系认可、期待、不满、失望、愤怒、平静。前两种是正向情感中间两种是负向情感但强度有差异愤怒是强负向需要拉响服务预警平静则是中性但往往意味着低卷入度。Prompt的设计上我要求模型输出JSON格式的结果包含情感类别、情感强度1~10、触发原因、涉及的实体对象。这里贴一下我实际在用的Prompt模板已经做了脱敏和简化你是一个专业的用户情感分析助手。请分析以下用户文本的情感倾向。 要求 1. 从以下类别中选择最匹配的一个认可、期待、不满、失望、愤怒、平静 2. 给出情感强度评分1-10分分数越高代表情感越强烈 3. 用一句话说明触发该情感的具体原因 4. 提取文本中涉及的实体对象如商品、服务、物流、客服等 输出格式严格JSON {sentiment: 类别, intensity: 分数, reason: 原因, entities: [实体1, 实体2]} 用户文本 {text}这个Prompt看起来简单但有几个细节值得注意。第一输出格式限定为JSON这能大幅降低后续解析成本第二要求模型给出触发原因这个原因本身就能作为画像中的证据字段方便后续核查第三实体对象的提取为后续的品类偏好分析做了铺垫。实测效果在人工标注的2000条测试集上六分类的准确率在82%左右强度评分的平均绝对误差约为0.7。相比我之前用BERT微调做三分类的方案准确率提升了大约5个百分点而且泛化能力更好遇到新品类、新表述方式时不会轻易翻车。3.2 消费习惯挖掘从订单数据到行为模式的解释性总结消费习惯挖掘是这类系统里跟业务指标结合最紧的部分。传统做法是统计用户在各品类的消费占比、价格区间分布、购买时段分布然后贴上一堆高价值用户价格敏感型的标签。但这样做出来的标签解释力很弱运营同学看到高价值用户四个字依然不知道该怎么跟用户沟通。我的思路是用LLM来做解释性总结。先让统计模块产出结构化的消费指标——品类偏好Top3、价格带分布、购买时间分布、大促参与度、优惠券使用率、退货率等然后把这些指标以JSON的形式提供给LLM让它生成一段连贯的用户消费习惯描述。以我实际得到的输出为例对于一位用户系统生成的结果是这样的该用户近90天的消费集中在美妆和个护品类客单价处于中高水平200-400元区间对套装类商品偏好明显。用户有明显的价格敏感行为购买决策前通常会对比3-5个同品类商品优惠券使用率高达78%。值得注意的是用户晚22点至24点时段的购买占比超过40%属于典型的夜间决策型消费者。这段话的效率非常高。它不仅是几个标签的堆砌还给出了消费场景的画像和潜在的行动建议——晚间时段推送、重视性价比验证环节这些都是做营销干预时可以直接使用的信息。实现上有几个提速技巧。一是用结构化指标直出文本不要让LLM自己看流水数据否则又贵又慢二是把常见的消费模式总结做成少量样本示例放进Prompt里引导输出风格保持一致三是对近30天无消费记录的用户在Prompt里强制要求标注近期活跃度下降避免模型产出与事实冲突的结论。3.3 价值观推断最有争议也最有价值的模块价值观推断是这套系统里最具智能感的部分也是最容易做砸的部分。为什么这么说因为价值观不像消费行为那样有明确的统计信号它需要从用户的言论、选择、偏好中做归纳和推理出错风险很高。我的实现思路是不做判断只做归纳。具体来说系统不直接输出该用户属于某某类型人群这样的判断性标签而是输出该用户在以下维度上表现出稳定的倾向每一个倾向都附带证据文本。Prompt的引导词大概是这样请基于用户的文本记录归纳该用户在以下几个方面表现出的稳定倾向 1. 对品质与服务的要求层级 2. 对新事物的接受程度 3. 对品牌的态度品牌忠诚 vs 功能导向 4. 生活方式取向效率优先 vs 体验优先 要求 - 只归纳有文本证据支撑的倾向不要推测用户的身份、职业、收入等敏感属性 - 每个倾向标注证据引用原文片段 - 如果没有足够证据请明确输出证据不足这个设计有两点考虑。第一用倾向替代标签在表达上更严谨也更容易被业务方接受第二强制要求证据引用和证据不足的存在就是为了抑制LLM的过度推测倾向。实测初期不做这个约束时模型经常脑补出用户的职业和家庭情况比如从买了一次母婴用品就推断用户是宝妈这显然是危险且不准确的。价值观推断这个模块上线后我最常收到的反馈是它生成的用户描述比传统标签更容易让一线的运营同事产生认同感。因为传统标签只是高活跃“高消费”这类冷冰冰的词而LLM生成的内容更像一个真正理解用户的人写的用户小传。3.4 用户行为分析把行为序列翻译成用户语言用户行为分析我用了另一个思路——把行为序列转成自然语言事件流然后让LLM做模式识别。传统的用户行为分析用序列挖掘算法比如PrefixSpan、FP-Growth找频繁模式但找到的模式往往是浏览A→浏览B→购买C这种可读性很差的结构。我的方案分两步。第一步用一个行为翻译器把原始行为日志转成事件描述比如原生日志{event: detail_view, sku: 12345, category: 手机, duration: 45}翻译后文本用户在22:13分查看了一款手机商品详情页停留45秒第二步把用户一段窗口时间内的所有事件文本交给LLM让它识别行为模式。系统会输出类似这样的分析用户有明确的目标导向型购买行为决策链路集中在对比阶段通常会在3天内完成从浏览到购买的转化但容易受到评价中负面信息的影响而在最后一步放弃。这种分析的价值在于它不只能回答用户做了什么还能回答用户的行为路径说明了什么。这一点是传统序列挖掘很难做到的。实际应用的时候这套行为分析的结果会被用来做流失预警和干预触发比如识别出连续多次放弃结算的用户自动触发客服关怀任务。4. 动态标签生成从静态标签到有生命周期、有证据链的标签用户画像的最终呈现形态是标签。市面上大多数标签系统都是静态的打上去就是打上去了几个月不动。这种静态标签的问题在于用户的兴趣和意图会漂移很多标签等到真正使用时已经过时了。我在这个系统里设计了动态标签生成机制核心是给每个标签加上生命周期和证据链。4.1 标签体系的层级结构与生成逻辑我把标签分成三个层级基础标签、业务标签、推理标签。基础标签直接来自结构化数据比如女性北京30-35岁注册时长大于2年这类标签不需要LLM参与用规则就能处理我保留它们在传统管线里生产。业务标签是运营视角的概念标签比如高潜力转化用户价格敏感型夜间活跃内容创作者偏好这些标签由LLM综合结构化特征和文本特征生成带有一定的业务解释性。推理标签是LLM综合判断后的深层标签比如品质生活导向家庭决策型消费者品牌忠诚度高这类标签不直接依赖某个指标而是通过对多源信息的归纳推理得出。标签生成不是一步到位的。我的系统采用两阶段生成第一阶段LLM基于用户所有的上下文信息生成候选标签列表和证据文本第二阶段一个校验模块对候选标签做合法性检查过滤掉敏感标签、证据不足的标签和与基础事实冲突的标签然后才写入标签库。4.2 标签的置信度、生命周期与自动化更新每个标签在入库时都带着四个字段置信度分数、证据引用、首次生成时间、最后更新时间。置信度由LLM生成时的自评分和规则校验结果共同决定低于阈值的标签只留在候选区不进入正式的用户画像接口。生命周期管理是动态标签的核心。我的策略是行为驱动的标签更新优先时间驱动的标签衰减为辅。具体来说当用户产生新行为时触发相关标签的更新如果某标签长期没有被触发置信度会按时间衰减。衰减系数我调成了平滑线性衰减90天内无激活的标签置信度减半180天无激活的标签自动降级为候选标签等待重新验证。这套机制解决了一个很现实的问题画像系统的标签不再越积越多、越来越脏。我见过很多团队做画像做了两三年标签库膨胀到几万个大量标签互相矛盾实际可用率不到一半。有了生命周期管理之后标签库维持在相对精简的状态每个标签都有存活依据使用方也更容易信任系统输出。4.3 标签解释性设计给业务方一个宁可展示证据的界面标签系统的最后一个拦路虎是业务方的信任问题。运营同学和客服同学天然不信任一个黑盒标签他们会问为什么系统说这个用户是价格敏感型依据是什么我因此在标签管理的输出接口里加入了一个证据展示字段。每个标签输出时都附带上证据链——具体的数据指标或者文本片段引用。业务侧查看的时候可以直接看到依据用户原文再便宜点我就下单了比了好几家了这样的支撑信息。这个改动看起来很小但对系统落地帮助巨大。信任感上来了系统使用率自然就上去了画像数据也才能真正驱动业务的精细化运营。5. 上线之后的坑幻觉控制、成本控制、评估方法论这一节是实战经验的集中展示。再漂亮的架构跑到生产环境都会遇到一堆文档里不会写的问题。我挑几个典型的来讲。5.1 幻觉问题LLM会一本正经地编造用户特征幻觉是LLM应用到画像场景最危险的问题。我遇到过一个典型案例一位用户只买过一次宠物用品LLM在生成标签时写了该用户养了一只柯基犬。这个结论是怎么来的因为用户的某条评价里出现了我家狗子这个口语化表达而训练语料里柯基和狗子的关联度太高模型就自行脑补了品种信息。这类幻觉如果不加控制后果很严重。一是画像失真二是如果业务方拿着错误标签去做营销比如给用户推送狗粮用户根本不需要反而造成体验损伤。我总结了三道防线的控制方案。第一道防线是Prompt层明确要求模型只能基于提供的文本做推断不得补充背景知识第二道防线是证据校验标签的生成必须附带证据引用如果证据无法从原文中定位标签直接丢弃第三道防线是结果审核对生成画像做抽样人工复核统计幻觉率作为监控指标一旦超过阈值就触发告警。这三道防线并不能完全消灭幻觉但能把影响降到可接受的范围。我现在系统里的幻觉率控制在3%以内且大多集中在低风险标签上影响有限。5.2 成本控制Token消耗的优化策略LLM做画像的Token消耗是传统算法不需要考虑的额外成本。一开始我把所有用户的全部文本都塞给模型分析一个月下来账单数字相当惊人。后来做了三个优化成本下降到原来的四分之一。第一把固定不变的内容移到System Prompt里。用户画像的任务说明和输出格式是每次调用都一样的这部分放入System Prompt可以稳定复用不用重复计费到每次的上下文里。第二做文本预筛选。不是所有文本都值得给LLM分析。我先用低成本的关键词匹配和情感得分初筛一遍只把信息密度高、情感强度高的文本喂给LLM。纯寒暄类的客服对话、毫无信息量的评论直接跳过。第三引入缓存层。用LLM生成的画像结果按用户时间窗口做缓存同一个用户在短时间内重复请求画像时直接命中缓存不重新调用模型。画像本身就是低频变动的数据缓存命中率只要做得好收益非常可观。5.3 画像质量的评估方法论最后一个坑是如何评估画像做得好不好。传统标签的评估可以用准确率、覆盖率这些指标但LLM生成的描述性画像没有唯一的标准答案很难做自动化评估。我的做法是构建了两套评估体系。第一套是从业务效果侧的A/B测试把画像结果用于实际的运营策略——比如用画像做个性化Push的文案优化、商品推荐的排序调整——然后对比实验组的点击率、转化率、客单价等业务指标。这是最客观的评估毕竟画像系统的最终价值还是要落到业务指标的提升上。第二套是定期的模型输出人工盲评。把LLM生成的画像和传统算法生成的画像混合在一起让业务侧的同学盲评从准确性丰富度行动指导性三个维度打分。这套评估虽然耗时但能发现很多自动化指标发现不了的问题比如生成内容模板化、过于泛泛而谈、缺乏个性化的现象。目前系统稳定运行了大半年画像的月活调用量在千万级别业务侧的核心转化指标相比使用传统画像系统时提升了约12%。这个提升当然不只是画像系统的功劳但它至少说明一点让LLM参与用户画像分析方向是对的关键是把工程细节做扎实。最后再分享一个我个人操作中的小技巧。很多人用LLM做用户分析习惯一次性把所有任务丢给模型让它既做情感分类又做消费总结又做价值观推断结果每个任务都做得不够好。我的建议是拆分成独立的调用链路每个模块专注一件事模块之间用数据管道串联。虽然调用次数多了、整体延迟变长了但每个环节的质量都更容易保证和迭代——工程上宁要多个小步的确定性也不要一个大步的碰运气。本文还有配套的精品资源点击获取