先说个真实场景。我做AI产品方向这几年最常被问的一句话是“你平时都研究些什么”问的人可能只是随口寒暄但我每次都会被噎住——因为我的浏览器书签、论文收藏夹、GitHub Star列表、还有聊天记录里翻出来的技术讨论根本没法用一句话说清楚。后来做技术决策的时候也是同样的问题团队要引入一个新框架我翻了几十篇文章发现有人夸它工程化做得好有人骂它文档稀碎还有人用它做了个很有趣但完全跑偏的Demo这些信息揉在一起到底能说明什么我真正想知道的是“关注这个方向的人他们到底在关心什么”。这就是“AI 研究偏好模型”这个项目最初的原型一个能自动从散落信息里提取研究者兴趣偏好、给研究方向打标签、并输出结构化画像的模型。我把它做成了一个可落地的系统输入是一堆文档、话题、关键词或者用户行为数据输出是这个人的技术关注图谱——喜欢什么方向、对什么话题敏感、更偏向算法还是工程、近期关注度在上升还是下降。这篇文章完整拆解这个模型的构建过程从需求拆解、技术选型、数据标注、模型训练到上线部署每一步都有可复现的操作细节也有一些常规文档里不会写的坑。适合谁看如果你是做AI产品经理、算法工程师、技术运营、招聘HR或者你自己就是一个需要定期追踪领域动态的研究者这篇内容应该能给你一个可以直接参考的框架。不需要你有非常深的算法底子我会把必要的原理用白话拆开讲清楚。1. 整体设计这不是一个简单的“文本分类器”1.1 研究偏好到底是个什么东西我最开始的想法特别朴素把“AI 研究偏好”当成一个文本多标签分类问题来处理——给一段文字打上“大模型”“多模态”“AI编程”之类的标签完事了。但真正动手之后发现这个思路是有问题的。“研究偏好”本质上不是一个“点”而是一个“结构”。一个人对AI领域的研究偏好起码包括四个维度方向标签偏好落在哪个子领域比如大模型训练、AI Infra、多模态、AI Agent、AI编程工具、AI安全、AI测试等。关注热度近期在某个方向上的信息摄入量是上升还是下降以及绝对频次如何。方法偏好更喜欢偏理论推导的内容还是工程落地类内容还是产业应用类内容。同样是关注AI Agent有的人看的是ReAct论文有的人刷的是LangChain源码还有人在看Agent的产品交互设计。内容来源偏好偏好看论文、看技术博客、看产品评测还是看产业分析。这四个维度加起来才能形成一个相对完整的“偏好画像”。只做方向标签充其量是个“话题分类器”不是“偏好模型”。1.2 技术路线选型为什么选择了“规则初筛 模型分类 画像聚合”三层架构明确了目标之后接下来就要选技术路线。我对比过三条方案纯规则方案用关键词词典做匹配简单快速但覆盖度有限AI领域的词变化太快今天还在说Prompt Engineering明天大家都在聊Agent Memory词典很快就会过时。纯端到端大模型方案把所有文本扔给大模型让它直接输出画像。效果确实好但成本高、响应慢而且这个是To B或者团队内部服务不是个人玩具需要考虑服务稳定性和可解释性。研究偏好结果出来之后业务方肯定会问“为什么给我推这个方向的内容”你得能解释清楚。规则初筛 模型分类 画像聚合先用规则做粗召回和清洗再用模型打标签和做语义相似度匹配最后用聚合逻辑把零散标签收敛成用户级的偏好画像。这个方案的好处是每一层都能独立调试也方便定位问题。处理速度可控且每一层的产出都能可视化方便业务方理解。我最终选了第三条方案。三层架构看下来会多一层开发和维护成本但换来的是可解释性、可控性和长期可维护性。对“研究偏好模型”这种需要持续跟踪新技术热词的系统来说这个取舍是值得的。1.3 画像分层的底层逻辑再来细化一下画像的形态。我把用户的“AI研究偏好”拆成了三层信息单元层、标签层、画像层。信息单元层是最底层的输入一条论文摘要、一篇文章、一段对话、一个项目Readme都可以是一个信息单元。标签层是对每个信息单元做多标签分类输出一组带权重的技术主题标签。画像层是在一段时间窗口内聚合某个研究对象人、团队或机构的所有标签形成带时间维度的偏好统计。为什么要这么分因为偏好是有时间属性的。你上个月在疯狂研究AI Infra这个月开始转向AI应用开发如果你的画像系统只输出一个静态标签“AI Infra”那这个系统就是失真的。所以画像层的输出必须以“周”或“月”为粒度做切片计算出每个方向标签的热度趋势。这个设计和做用户画像的经典方法一脉相承但研究对象从“消费者”换成了“AI技术研究者”标签体系也完全不同。后面我会详细说这个标签体系是怎么设计的。2. 核心细节标签体系与特征工程2.1 标签体系设计AI领域独特的知识结构问题做“AI研究偏好模型”最核心、也最容易被低估的工作是标签体系Taxonomy的设计。AI领域的技术树和普通领域很不一样它不是一个树状结构而是一个网状结构这个特性直接决定了标签体系不能像传统的层级分类那样搞。我举个例子AB测试在AI领域有两个完全不同的含义在传统互联网语境下是产品功能对比实验在强化学习语境下是算法评估手段同样是“Fine-tuning”这个词NLP研究者、CV研究者、AI Infra工程师看到的完全是不同的问题域。如果标签体系不做语义消歧偏好模型输出的画像就是一团浆糊。我设计的标签体系分三层方向域这是大方向包括机器学习基础、深度学习、NLP、CV、多模态、大模型、AI Agent、AI编程、AI Infra、AI安全、AI应用、AI产品化、AI交叉学科等。技术点域每个方向下面有更加细粒度的技术点比如“大模型”下面有“预训练”“微调”“RLHF/DPO”“量化”“推理加速”“上下文工程”“模型评估”等。场景域描述研究场景是偏学术、偏工业还是偏产品比如“论文复现”“工程框架选型”“产品功能研发”“行业趋势追踪”。在具体实现上我没有把三层做成严格的分类树而是做成了三个独立的标签平面让它们自由组合。一个信息单元可能同时打上“大模型”“量化”“推理加速”“工程落地”四个标签这样表达的信息远比一个四级分类树更准确。2.2 特征标注用“小规模人工标注 主动学习”做冷启动没有标注数据任何监督模型都跑不起来。多标签分类模型的效果有80%以上取决于训练数据的质量而不是模型结构多先进。我一开始也想着能不能用大模型自动生成标注数据省掉人工打标。试了一轮发现问题很大——大模型对AI领域内部的细粒度区分把握得不够好比如“AI Agent”和“自动化”在字面上很接近但研究关注点完全不一样把“AI编程”标成“软件开发”在普通场景下没问题但在偏好模型里就是误导。研究偏好模型的用户本来就是专家标签错一个他们对系统信任度会立刻下降。所以冷启动阶段我老老实实做人工标注。策略是这样先拿3000条数据找领域内的几个人工标注员包括我自己做多标签标注每人标一遍然后算交叉一致性。一致性高的标签保留一致性低的标签集中讨论把标注规范细化。用这个种子集训练一个初始分类器让这个分类器去预测一批未标注数据只把预测置信度落在0.4-0.7之间的样本捞出来。这类样本是模型“拿不准”的最有价值拿给标注员复核纠正错误标签后再加入训练集。这个循环迭代三轮标注效率能提升不少。第四轮开始加入大模型辅助标注但不是让它直接给标签而是让它做标签建议标注员只需要确认或修改。这样标注速度能快一倍同时质量可受控。2.3 特征工程光有词向量是不够的分类模型一般的套路是先Embedding再接分类头但“研究偏好”这个场景里有几个特殊特征光靠通用Embedding是抓不到的需要额外做特征增强。第一个是领域词特征。AI领域有大量高度细分的专业词汇比如“RAG”“LoRA”“KV Cache”“DPO”“MCP”这些通用预训练模型虽然见过这些词但未必理解它们在领域内的相对位置关系。我维护了一份不断更新的AI词表用词表命中情况作为一个特征通道直接拼接到模型输入中。词表更新是每周做一次来源是arXiv新论文高频词、GitHub趋势项目简述、以及头部AI技术社区的热搜词。第二个是结构特征。不同来源的信息单元结构价值完全不同。论文摘要里的Methods和Results段落权重应该高于IntroductionGitHub项目里的Topics字段权重应该高于README中的宣传性描述对话记录里用户主动提到的技术名词权重远高于系统回复里的。这个结构特征不是从文本里挖出来的而是从前端采集逻辑里带过来的属于“元数据特征”。第三个是时间衰减特征。研究偏好模型必须回答“最近在关注什么”而不是“过去关注过什么”。我给每条信息单元按照产生时间设置一个时间衰减系数近7天的数据权重为130天前的数据权重衰减到0.690天前的权重衰减到0.3。聚合画像的时候不是简单计数而是按时间衰减加权。3. 实操过程从数据清洗到偏好画像3.1 数据来源与清洗管道我的数据来源主要有四类arXiv论文元数据title, abstract, subjects、技术社区的热门文章与讨论标题、正文、话题标签、GitHub趋势项目仓库描述、语言、Topics、以及内部工具记录的对话与搜索日志。这四类数据格式差异很大必须统一清洗。清洗管道分为四步每一步都有讲究去重。同一篇论文可能在arXiv、Paper Digest、Twitter讨论里出现多次我用标题统一化后的MD5作为去重键。注意统一化要把英文字母全小写、去掉特殊符号、过滤掉诸如“A Survey of”“Towards”这类前缀。段落归一化。论文摘要的换行符、博客里的HTML标签、GitHub README里的Markdown标记全部转成纯文本。这里容易踩坑的是把代码块内容也塞进正文里清洗代码特征和自然语言特征完全不同混在一起会污染分类结果。我的处理方式是识别出代码块后单独保留一份“代码特征”但不同时进入正文分类通道。关键词抽取。每条信息单元用规则加实体识别模型抽取出候选关键词作为分类特征的补充。规则部分我维护了一份AI领域核心实体词典比如框架名、模型名、算法名模型部分用了一个轻量级的序列标注模型来识别词典中还没有收录的新词。语言归一化。中英文混合的内容很常见我不做机器翻译而是把中英文表达映射到同一套标签体系里。方法是对英文关键词做同义词扩展对中文关键词做等价映射比如大规模语言模型和Large Language Model默认映射到同一个标签。3.2 分类模型的训练与迭代分类模型我采用的是“多任务学习”的结构一个底座模型同时输出三个预测头方向域标签、技术点域标签、场景域标签。三个任务共享底层的语义表示层训练时一起更新参数。这个做法的优势有两个一是三个任务互为正则能减少单个标签空间的稀疏性带来的过拟合问题二是在推理时只需要一次前向计算就能拿到三层标签响应速度更快。底座模型我在BERT和更轻量的EfficientText之间做了实验对比。结论是如果训练数据只有几千条EfficientText的效果和BERT差距不大但速度是BERT的几十倍。不过数据量上了两万以后BERT的优势就很明显了。我的项目数据量正好在快速增长期所以最终留的是BERT族模型用的是中文场景下表现比较稳的哈工大讯飞版BERT-wwm-ext。训练时的几个关键细节值得说损失函数没有直接用标准多标签的Binary Cross Entropy而是给每个标签加了难例权重。那些容易混淆的标签对比如“AI推理”和“AI训练”在训练时会把错误预测的惩罚调高。标签共现信息很宝贵。AI Agent和工具调用经常一起出现我在模型输出后加了一个共现纠偏层用训练集统计好的标签共现矩阵将置信度低但和同组高置信标签共现频率很高的标签拉高置信度。模型上线后我保留了一个“预测失败样本池”每周人工看一次预测置信度低于0.4的样本判断是标注错误、新概念还是模型能力不足。新概念就进词表标注错误就修正训练集模型能力不足就补充同类型的数据做增量训练。3.3 画像聚合从信息单元到用户偏好分类模型输出的是一个又一个信息单元的标签画像聚合是要把这些标签归并到一个研究对象名下。这里有个关键问题谁是研究对象我设计了三类研究对象个人研究者、技术团队/机构、以及一个特殊对象——某个前沿主题本身比如“多模态大模型”这个主题的关注者群体画像。前两类对象是“实体画像”第三类是“主题画像”。实体画像比较容易理解就是把这个人相关的所有信息单元都打上标签再做时间加权聚合。主题画像有意思一些它是反向操作先选定一个主题把和这个主题相关的所有信息单元找出来再看关注这些信息单元的人除了这个主题还关注什么。画像输出的核心数据表是一个“时间-标签-权重”三维结构。以周为单位切片每一周有一个标签权重向量记录这个人当周在“大模型”“多模态”“AI编程”等方向上的加权关注度。画像可视化的时候我会用它来画一个热力图或者堆叠面积图一眼就能看出关注度迁移过程。4. 工程化落地接口设计、性能优化与幻觉兜底4.1 服务架构与接口设计整个系统不是一个大单体而是拆成了采集源适配器、信息清洗管道、分类推理服务、画像聚合引擎、画像查询API五个模块模块间通过内部消息队列解耦。对外提供的API主要有三个异步提交任务接口接收一批原始文本或文档链接返回一个任务ID处理完成后通过回调通知结果。这个接口解决的是批量数据处理场景。实时分类接口单条文本实时打标签延迟要求小于300ms为在线场景设计比如用户在编辑器里选中一段文字系统立刻返回相关研究方向标签。画像查询接口输入研究对象ID返回一个时间范围内的偏好画像数据支持按方向域、技术点域、时间粒度做过滤。设计上有个容易被忽略但很重要的点——画像查询接口返回的原始标签和权重是给开发人员看的业务方通常需要的是“可读的结论”。所以API返回结构里除了结构化数据我还会附带一段由模板生成的自然语言摘要比如“该研究对象近30天重点关注AI Agent方向关注度上升趋势明显同时在AI编程方向保持稳定关注”。这段摘要的措辞不是给机器看的是给人看的。4.2 性能优化缓存与批量推理偏好模型这种服务的性能瓶颈不在模型本身而在数据管道和特征提取。我之前以为推理是瓶颈压测之后发现Embedding和图谱特征计算才是大头。ES做检索、图数据库做关系查询这些常规优化不多说了这里说三个具体的优化点Embedding缓存。同一句话不会只在一条信息单元里出现标题可能复用摘要可能复用。我用句子级MD5作为缓存key命中缓存就能省掉一次Embedding计算。实测下来缓存命中率稳定在40%以上峰值时段甚至能到60%。分类推理的动态Batch。GPU推理只有凑够Batch才不会浪费显存。我把实时分类接口改成“先攒50ms或攒满32条再推理”的模式单条延迟只增加了不到50ms但GPU利用率从18%提升到了70%以上。画像聚合的预聚合机制。画像查询接口如果每次请求都从头扫描信息单元再聚合数据量大了必然卡死。我改成每10分钟做一次预聚合把增量数据写入聚合结果表查询时只需要做“读聚合结果 读增量”两步响应时间稳定在100ms以内。这一整套优化做完以后单机8核16G内存的条件下每天可以处理10万条信息单元的增量和几百个画像查询请求对大多数团队来说完全够用。4.3 不要忽略的AI幻觉与合规兜底研究偏好模型的一大风险是“自作聪明”。分类模型在遇到看不明白的文本时很容易强行塞一个标签进去这时候用户的画像就被污染了。我遇到过最典型的案例一篇讲“AI在材料科学中的应用”的论文摘要分类模型强行打上了“AI基础理论”的标签理由可能是摘要里出现了“model”和“training”。从文本分类角度看这个结果没错但从研究偏好角度看完全错误——这位研究者的关注点明明是交叉学科应用不是基础理论。这类错误对偏好画像的污染远比漏标严重。应对方案有两个层面。第一层是模型层面加一个unknown类以及置信度阈值策略。所有标签的预测置信度低于0.5的信息单元不进入画像聚合进入待人工复核队列。这个措施会把大约8%的边缘内容挡在画像之外但换来了画像整体的可信度。第二层是语义一致性校验抽取出来的关键词集合和标签集合做语义相似度比对如果关键词是“材料基因”“晶体结构”但标签是“大模型训练”基本可以断定是错标。安全合规方面也要提一嘴。研究偏好模型加工的是人的行为数据属于高度敏感的个人信息必须遵循最小化采集原则不去采集与AI研究无关的行为数据画像结果做匿名化处理不直接关联真实身份对外输出概览趋势不输出个体明细。这个不是额外的加分项而是底线要求缺失了底线项目的商业价值再高也站不住。5. 模型评测怎么判断偏好模型做得好不好5.1 评测维度准确率之外的东西对偏好模型的评测不能只看标签分类的F1分数。F1只能说明“这一条文本标签打得对不对”但偏好模型真正的价值是“画像画得准不准”。我用了四个评测维度标签准确率信息单元级的多标签分类准确率用F1衡量关注点在方向域和技术点域。画像稳定性同一个研究对象在短期内比如一周内连续两次查询画像是稳定一致还是剧烈抖动。如果一个人昨天显示偏好AI Infra今天就变成偏好多模态而这段时间并没有新的研究行为说明系统不稳定。我用画像向量之间的余弦相似度来衡量稳定性要求同一个人在相隔一天内的画像相似度不低于0.85。画像区分度不同研究对象之间的画像差异应该足够大。如果所有人的画像都长一个样那这个模型没有信息量。我用画像向量集合的熵来衡量区分度熵值过低说明标签聚合逻辑过于粗放。趋势可解释性画像显示某个标签热度上升时系统里必须有足够的底层信息单元做支撑。换句话说可解释性要求你随时能“下钻”到支撑证据而不是只给一个结论。这个维度很难量化但非常重要。5.2 经典踩坑画像被“洗流量”和“冷启动”问题开发过程中踩过一个大坑必须拿出来提醒各位不是所有文本都值得进入画像计算。我一开始把用户所有相关的文本全丢进管道里算标签结果某研究者的画像硬生生被“AI绘画”刷屏了。排查后发现原因是他参与维护的一个开源项目经常有人提关于文生图功能的Issue大量Issue文本被采集进来了但这些内容本质上不是他的研究偏好而是他作为维护者的客服工作量。这个问题实际上是“数据噪音”和“研究偏好”之间的经典矛盾。我最后的解决方案是在信息单元进入管道之前加了一个“意图门”区分主动产出和被动接收。主动产出的内容写的论文、开的Issue、提交的代码、发表的技术观点权重设为1.0被动接收的内容别人他的讨论、订阅的新闻摘要权重降为0.3且不计入活跃偏好。对于社区类数据引入了互动加权。只转发了但没有任何评论的内容权重低参与讨论、提出修改建议、贡献代码的权重高。另一个常见问题是冷启动。一个新研究对象进来没有任何历史数据画像是空的。我的做法是允许研究对象绑定一些种子属性比如他的职位是算法工程师系统的画像启动默认值会和“算法工程师人群画像”对齐再随着个人数据的积累逐步个性化。这样可以在一开始就能给出一定程度的偏好推荐虽然不够精准但比完全空白要好得多。6. 常见问题排查与备查清单6.1 上线后容易遇到的典型问题这里直接给一个我整理的排查速查表你照着看就行问题现象可能原因排查方案画像是空的数据采集没跑到检查采集源的授权范围和任务调度是否正常看信息单元表中相应来源是否有增量记录画像标签全部偏向“大模型”标签体系出现偏置大模型方向样本大量过采样检查标签体系的类别分布做类别重加权或对低频方向做数据增强画像变化波动剧烈聚合窗口太短或者噪音信息太多把时间聚合窗口从周粒度拉长到双周粒度检查“意图门”规则是否生效同一条文本反复改变标签模型输出不稳定或者使用了不同的模型版本固定模型版本在推理层加入结果缓存同一文本hash命中直接返回历史结果新概念识别不出来词表和训练数据中没覆盖把典型的“未识别样本”捞出来人工标注后加入增量训练集并同步更新领域词表画像查询接口超时聚合结果表失效或者增量计算过慢检查预聚合任务是否正常运行查询接口的时序逻辑是否退化成了全量扫描多标签分类总是漏掉次要标签训练数据的标签共现信息没利用好检查共现纠偏层的置信度提升幅度可调高共现矩阵的权重或补充共现对训练数据6.2 判断模型退化的三个定时任务系统上线之后不是一劳永逸的AI领域一个月会冒出大量新方向新玩法研究偏好的标签体系如果不更新画像很快就失真。我设了三个定时任务来防止模型退化每周一跑一次“新词发现”任务对比本周新增文本和现有词表的覆盖差异把高频出现的未登录词捞出来由人工判断是否加入领域词表。每两周跑一次“标签漂移检测”对比近两周分类结果的标签分布和长期基线的分布差异。如果某个标签的比例突然大幅上升先查是不是有热点事件造成的真实变化再看是不是模型被某些新表达方式迷惑了。每月评估一次增量训练效果用固定测试集跑一遍分类F1对比。允许有小幅波动但如果F1下降超过1.5个百分点必须排查原因——大部分时候都是训练数据分布和线上数据分布不一致造成的。这三个任务自动化程度很高跑的时长也不长但对系统长期健康的影响非常大。7. 版本迭代方向从“研究偏好”到“研究趋势”7.1 短中期加入群体趋势预测单人的研究偏好画像跑通之后我下一步要做的是群体研究趋势预测。简单说就是在完成我们团队或某个群体的个体画像之后再向上聚合成“团队画像”和“方向画像”并尝试预测未来1-3个月内哪些方向会升温。具体做法是给每个技术标签构建一个时间序列用经典的时间序列预测方法先做差分平稳化再做ARIMA或者Prophet预测未来几周的热度变化同时结合“早期研究者雷达”——识别出那些最早开始关注一个新方向的人如果这批人同时开始转向某个标签大概率这个方向要火了。7.2 长期研究偏好的“可解释迁移”个人更看好的长期方向是把AI领域的偏好模型迁移到其他专业领域。研究偏好的底层机制是相通的——数据清洗、多标签分类、实体画像、时间加权聚合、趋势预测这套方法搬到生物医药、半导体、新能源这些同样知识密集、技术迭代快的行业只需要换掉标签体系和领域词表整体架构几乎可以原封不动复用。这也是这套架构没有和某个具体业务深度绑定的原因。最后分享一个经验的话做一个偏好模型真正值钱的地方并不在模型本身而是对领域的理解——决定用什么标签、怎么定义研究对象、如何区分噪音与信号、如何让画像可解释。这些判断模型给不了你只有深入业务的人能给到。AI研究偏好模型这个方向我今天把自己踩过的坑和趟出来的路都写出来了。如果你正在做类似的事情可以照着这套思路试一遍。团队内部有自己积累的数据可以先从标签体系设计和种子标注做起模型反而是最简单的一部分。真正难的是持续运营、持续纠偏、持续理解你的用户。
AI研究偏好模型构建实战：从标签体系到画像聚合
先说个真实场景。我做AI产品方向这几年最常被问的一句话是“你平时都研究些什么”问的人可能只是随口寒暄但我每次都会被噎住——因为我的浏览器书签、论文收藏夹、GitHub Star列表、还有聊天记录里翻出来的技术讨论根本没法用一句话说清楚。后来做技术决策的时候也是同样的问题团队要引入一个新框架我翻了几十篇文章发现有人夸它工程化做得好有人骂它文档稀碎还有人用它做了个很有趣但完全跑偏的Demo这些信息揉在一起到底能说明什么我真正想知道的是“关注这个方向的人他们到底在关心什么”。这就是“AI 研究偏好模型”这个项目最初的原型一个能自动从散落信息里提取研究者兴趣偏好、给研究方向打标签、并输出结构化画像的模型。我把它做成了一个可落地的系统输入是一堆文档、话题、关键词或者用户行为数据输出是这个人的技术关注图谱——喜欢什么方向、对什么话题敏感、更偏向算法还是工程、近期关注度在上升还是下降。这篇文章完整拆解这个模型的构建过程从需求拆解、技术选型、数据标注、模型训练到上线部署每一步都有可复现的操作细节也有一些常规文档里不会写的坑。适合谁看如果你是做AI产品经理、算法工程师、技术运营、招聘HR或者你自己就是一个需要定期追踪领域动态的研究者这篇内容应该能给你一个可以直接参考的框架。不需要你有非常深的算法底子我会把必要的原理用白话拆开讲清楚。1. 整体设计这不是一个简单的“文本分类器”1.1 研究偏好到底是个什么东西我最开始的想法特别朴素把“AI 研究偏好”当成一个文本多标签分类问题来处理——给一段文字打上“大模型”“多模态”“AI编程”之类的标签完事了。但真正动手之后发现这个思路是有问题的。“研究偏好”本质上不是一个“点”而是一个“结构”。一个人对AI领域的研究偏好起码包括四个维度方向标签偏好落在哪个子领域比如大模型训练、AI Infra、多模态、AI Agent、AI编程工具、AI安全、AI测试等。关注热度近期在某个方向上的信息摄入量是上升还是下降以及绝对频次如何。方法偏好更喜欢偏理论推导的内容还是工程落地类内容还是产业应用类内容。同样是关注AI Agent有的人看的是ReAct论文有的人刷的是LangChain源码还有人在看Agent的产品交互设计。内容来源偏好偏好看论文、看技术博客、看产品评测还是看产业分析。这四个维度加起来才能形成一个相对完整的“偏好画像”。只做方向标签充其量是个“话题分类器”不是“偏好模型”。1.2 技术路线选型为什么选择了“规则初筛 模型分类 画像聚合”三层架构明确了目标之后接下来就要选技术路线。我对比过三条方案纯规则方案用关键词词典做匹配简单快速但覆盖度有限AI领域的词变化太快今天还在说Prompt Engineering明天大家都在聊Agent Memory词典很快就会过时。纯端到端大模型方案把所有文本扔给大模型让它直接输出画像。效果确实好但成本高、响应慢而且这个是To B或者团队内部服务不是个人玩具需要考虑服务稳定性和可解释性。研究偏好结果出来之后业务方肯定会问“为什么给我推这个方向的内容”你得能解释清楚。规则初筛 模型分类 画像聚合先用规则做粗召回和清洗再用模型打标签和做语义相似度匹配最后用聚合逻辑把零散标签收敛成用户级的偏好画像。这个方案的好处是每一层都能独立调试也方便定位问题。处理速度可控且每一层的产出都能可视化方便业务方理解。我最终选了第三条方案。三层架构看下来会多一层开发和维护成本但换来的是可解释性、可控性和长期可维护性。对“研究偏好模型”这种需要持续跟踪新技术热词的系统来说这个取舍是值得的。1.3 画像分层的底层逻辑再来细化一下画像的形态。我把用户的“AI研究偏好”拆成了三层信息单元层、标签层、画像层。信息单元层是最底层的输入一条论文摘要、一篇文章、一段对话、一个项目Readme都可以是一个信息单元。标签层是对每个信息单元做多标签分类输出一组带权重的技术主题标签。画像层是在一段时间窗口内聚合某个研究对象人、团队或机构的所有标签形成带时间维度的偏好统计。为什么要这么分因为偏好是有时间属性的。你上个月在疯狂研究AI Infra这个月开始转向AI应用开发如果你的画像系统只输出一个静态标签“AI Infra”那这个系统就是失真的。所以画像层的输出必须以“周”或“月”为粒度做切片计算出每个方向标签的热度趋势。这个设计和做用户画像的经典方法一脉相承但研究对象从“消费者”换成了“AI技术研究者”标签体系也完全不同。后面我会详细说这个标签体系是怎么设计的。2. 核心细节标签体系与特征工程2.1 标签体系设计AI领域独特的知识结构问题做“AI研究偏好模型”最核心、也最容易被低估的工作是标签体系Taxonomy的设计。AI领域的技术树和普通领域很不一样它不是一个树状结构而是一个网状结构这个特性直接决定了标签体系不能像传统的层级分类那样搞。我举个例子AB测试在AI领域有两个完全不同的含义在传统互联网语境下是产品功能对比实验在强化学习语境下是算法评估手段同样是“Fine-tuning”这个词NLP研究者、CV研究者、AI Infra工程师看到的完全是不同的问题域。如果标签体系不做语义消歧偏好模型输出的画像就是一团浆糊。我设计的标签体系分三层方向域这是大方向包括机器学习基础、深度学习、NLP、CV、多模态、大模型、AI Agent、AI编程、AI Infra、AI安全、AI应用、AI产品化、AI交叉学科等。技术点域每个方向下面有更加细粒度的技术点比如“大模型”下面有“预训练”“微调”“RLHF/DPO”“量化”“推理加速”“上下文工程”“模型评估”等。场景域描述研究场景是偏学术、偏工业还是偏产品比如“论文复现”“工程框架选型”“产品功能研发”“行业趋势追踪”。在具体实现上我没有把三层做成严格的分类树而是做成了三个独立的标签平面让它们自由组合。一个信息单元可能同时打上“大模型”“量化”“推理加速”“工程落地”四个标签这样表达的信息远比一个四级分类树更准确。2.2 特征标注用“小规模人工标注 主动学习”做冷启动没有标注数据任何监督模型都跑不起来。多标签分类模型的效果有80%以上取决于训练数据的质量而不是模型结构多先进。我一开始也想着能不能用大模型自动生成标注数据省掉人工打标。试了一轮发现问题很大——大模型对AI领域内部的细粒度区分把握得不够好比如“AI Agent”和“自动化”在字面上很接近但研究关注点完全不一样把“AI编程”标成“软件开发”在普通场景下没问题但在偏好模型里就是误导。研究偏好模型的用户本来就是专家标签错一个他们对系统信任度会立刻下降。所以冷启动阶段我老老实实做人工标注。策略是这样先拿3000条数据找领域内的几个人工标注员包括我自己做多标签标注每人标一遍然后算交叉一致性。一致性高的标签保留一致性低的标签集中讨论把标注规范细化。用这个种子集训练一个初始分类器让这个分类器去预测一批未标注数据只把预测置信度落在0.4-0.7之间的样本捞出来。这类样本是模型“拿不准”的最有价值拿给标注员复核纠正错误标签后再加入训练集。这个循环迭代三轮标注效率能提升不少。第四轮开始加入大模型辅助标注但不是让它直接给标签而是让它做标签建议标注员只需要确认或修改。这样标注速度能快一倍同时质量可受控。2.3 特征工程光有词向量是不够的分类模型一般的套路是先Embedding再接分类头但“研究偏好”这个场景里有几个特殊特征光靠通用Embedding是抓不到的需要额外做特征增强。第一个是领域词特征。AI领域有大量高度细分的专业词汇比如“RAG”“LoRA”“KV Cache”“DPO”“MCP”这些通用预训练模型虽然见过这些词但未必理解它们在领域内的相对位置关系。我维护了一份不断更新的AI词表用词表命中情况作为一个特征通道直接拼接到模型输入中。词表更新是每周做一次来源是arXiv新论文高频词、GitHub趋势项目简述、以及头部AI技术社区的热搜词。第二个是结构特征。不同来源的信息单元结构价值完全不同。论文摘要里的Methods和Results段落权重应该高于IntroductionGitHub项目里的Topics字段权重应该高于README中的宣传性描述对话记录里用户主动提到的技术名词权重远高于系统回复里的。这个结构特征不是从文本里挖出来的而是从前端采集逻辑里带过来的属于“元数据特征”。第三个是时间衰减特征。研究偏好模型必须回答“最近在关注什么”而不是“过去关注过什么”。我给每条信息单元按照产生时间设置一个时间衰减系数近7天的数据权重为130天前的数据权重衰减到0.690天前的权重衰减到0.3。聚合画像的时候不是简单计数而是按时间衰减加权。3. 实操过程从数据清洗到偏好画像3.1 数据来源与清洗管道我的数据来源主要有四类arXiv论文元数据title, abstract, subjects、技术社区的热门文章与讨论标题、正文、话题标签、GitHub趋势项目仓库描述、语言、Topics、以及内部工具记录的对话与搜索日志。这四类数据格式差异很大必须统一清洗。清洗管道分为四步每一步都有讲究去重。同一篇论文可能在arXiv、Paper Digest、Twitter讨论里出现多次我用标题统一化后的MD5作为去重键。注意统一化要把英文字母全小写、去掉特殊符号、过滤掉诸如“A Survey of”“Towards”这类前缀。段落归一化。论文摘要的换行符、博客里的HTML标签、GitHub README里的Markdown标记全部转成纯文本。这里容易踩坑的是把代码块内容也塞进正文里清洗代码特征和自然语言特征完全不同混在一起会污染分类结果。我的处理方式是识别出代码块后单独保留一份“代码特征”但不同时进入正文分类通道。关键词抽取。每条信息单元用规则加实体识别模型抽取出候选关键词作为分类特征的补充。规则部分我维护了一份AI领域核心实体词典比如框架名、模型名、算法名模型部分用了一个轻量级的序列标注模型来识别词典中还没有收录的新词。语言归一化。中英文混合的内容很常见我不做机器翻译而是把中英文表达映射到同一套标签体系里。方法是对英文关键词做同义词扩展对中文关键词做等价映射比如大规模语言模型和Large Language Model默认映射到同一个标签。3.2 分类模型的训练与迭代分类模型我采用的是“多任务学习”的结构一个底座模型同时输出三个预测头方向域标签、技术点域标签、场景域标签。三个任务共享底层的语义表示层训练时一起更新参数。这个做法的优势有两个一是三个任务互为正则能减少单个标签空间的稀疏性带来的过拟合问题二是在推理时只需要一次前向计算就能拿到三层标签响应速度更快。底座模型我在BERT和更轻量的EfficientText之间做了实验对比。结论是如果训练数据只有几千条EfficientText的效果和BERT差距不大但速度是BERT的几十倍。不过数据量上了两万以后BERT的优势就很明显了。我的项目数据量正好在快速增长期所以最终留的是BERT族模型用的是中文场景下表现比较稳的哈工大讯飞版BERT-wwm-ext。训练时的几个关键细节值得说损失函数没有直接用标准多标签的Binary Cross Entropy而是给每个标签加了难例权重。那些容易混淆的标签对比如“AI推理”和“AI训练”在训练时会把错误预测的惩罚调高。标签共现信息很宝贵。AI Agent和工具调用经常一起出现我在模型输出后加了一个共现纠偏层用训练集统计好的标签共现矩阵将置信度低但和同组高置信标签共现频率很高的标签拉高置信度。模型上线后我保留了一个“预测失败样本池”每周人工看一次预测置信度低于0.4的样本判断是标注错误、新概念还是模型能力不足。新概念就进词表标注错误就修正训练集模型能力不足就补充同类型的数据做增量训练。3.3 画像聚合从信息单元到用户偏好分类模型输出的是一个又一个信息单元的标签画像聚合是要把这些标签归并到一个研究对象名下。这里有个关键问题谁是研究对象我设计了三类研究对象个人研究者、技术团队/机构、以及一个特殊对象——某个前沿主题本身比如“多模态大模型”这个主题的关注者群体画像。前两类对象是“实体画像”第三类是“主题画像”。实体画像比较容易理解就是把这个人相关的所有信息单元都打上标签再做时间加权聚合。主题画像有意思一些它是反向操作先选定一个主题把和这个主题相关的所有信息单元找出来再看关注这些信息单元的人除了这个主题还关注什么。画像输出的核心数据表是一个“时间-标签-权重”三维结构。以周为单位切片每一周有一个标签权重向量记录这个人当周在“大模型”“多模态”“AI编程”等方向上的加权关注度。画像可视化的时候我会用它来画一个热力图或者堆叠面积图一眼就能看出关注度迁移过程。4. 工程化落地接口设计、性能优化与幻觉兜底4.1 服务架构与接口设计整个系统不是一个大单体而是拆成了采集源适配器、信息清洗管道、分类推理服务、画像聚合引擎、画像查询API五个模块模块间通过内部消息队列解耦。对外提供的API主要有三个异步提交任务接口接收一批原始文本或文档链接返回一个任务ID处理完成后通过回调通知结果。这个接口解决的是批量数据处理场景。实时分类接口单条文本实时打标签延迟要求小于300ms为在线场景设计比如用户在编辑器里选中一段文字系统立刻返回相关研究方向标签。画像查询接口输入研究对象ID返回一个时间范围内的偏好画像数据支持按方向域、技术点域、时间粒度做过滤。设计上有个容易被忽略但很重要的点——画像查询接口返回的原始标签和权重是给开发人员看的业务方通常需要的是“可读的结论”。所以API返回结构里除了结构化数据我还会附带一段由模板生成的自然语言摘要比如“该研究对象近30天重点关注AI Agent方向关注度上升趋势明显同时在AI编程方向保持稳定关注”。这段摘要的措辞不是给机器看的是给人看的。4.2 性能优化缓存与批量推理偏好模型这种服务的性能瓶颈不在模型本身而在数据管道和特征提取。我之前以为推理是瓶颈压测之后发现Embedding和图谱特征计算才是大头。ES做检索、图数据库做关系查询这些常规优化不多说了这里说三个具体的优化点Embedding缓存。同一句话不会只在一条信息单元里出现标题可能复用摘要可能复用。我用句子级MD5作为缓存key命中缓存就能省掉一次Embedding计算。实测下来缓存命中率稳定在40%以上峰值时段甚至能到60%。分类推理的动态Batch。GPU推理只有凑够Batch才不会浪费显存。我把实时分类接口改成“先攒50ms或攒满32条再推理”的模式单条延迟只增加了不到50ms但GPU利用率从18%提升到了70%以上。画像聚合的预聚合机制。画像查询接口如果每次请求都从头扫描信息单元再聚合数据量大了必然卡死。我改成每10分钟做一次预聚合把增量数据写入聚合结果表查询时只需要做“读聚合结果 读增量”两步响应时间稳定在100ms以内。这一整套优化做完以后单机8核16G内存的条件下每天可以处理10万条信息单元的增量和几百个画像查询请求对大多数团队来说完全够用。4.3 不要忽略的AI幻觉与合规兜底研究偏好模型的一大风险是“自作聪明”。分类模型在遇到看不明白的文本时很容易强行塞一个标签进去这时候用户的画像就被污染了。我遇到过最典型的案例一篇讲“AI在材料科学中的应用”的论文摘要分类模型强行打上了“AI基础理论”的标签理由可能是摘要里出现了“model”和“training”。从文本分类角度看这个结果没错但从研究偏好角度看完全错误——这位研究者的关注点明明是交叉学科应用不是基础理论。这类错误对偏好画像的污染远比漏标严重。应对方案有两个层面。第一层是模型层面加一个unknown类以及置信度阈值策略。所有标签的预测置信度低于0.5的信息单元不进入画像聚合进入待人工复核队列。这个措施会把大约8%的边缘内容挡在画像之外但换来了画像整体的可信度。第二层是语义一致性校验抽取出来的关键词集合和标签集合做语义相似度比对如果关键词是“材料基因”“晶体结构”但标签是“大模型训练”基本可以断定是错标。安全合规方面也要提一嘴。研究偏好模型加工的是人的行为数据属于高度敏感的个人信息必须遵循最小化采集原则不去采集与AI研究无关的行为数据画像结果做匿名化处理不直接关联真实身份对外输出概览趋势不输出个体明细。这个不是额外的加分项而是底线要求缺失了底线项目的商业价值再高也站不住。5. 模型评测怎么判断偏好模型做得好不好5.1 评测维度准确率之外的东西对偏好模型的评测不能只看标签分类的F1分数。F1只能说明“这一条文本标签打得对不对”但偏好模型真正的价值是“画像画得准不准”。我用了四个评测维度标签准确率信息单元级的多标签分类准确率用F1衡量关注点在方向域和技术点域。画像稳定性同一个研究对象在短期内比如一周内连续两次查询画像是稳定一致还是剧烈抖动。如果一个人昨天显示偏好AI Infra今天就变成偏好多模态而这段时间并没有新的研究行为说明系统不稳定。我用画像向量之间的余弦相似度来衡量稳定性要求同一个人在相隔一天内的画像相似度不低于0.85。画像区分度不同研究对象之间的画像差异应该足够大。如果所有人的画像都长一个样那这个模型没有信息量。我用画像向量集合的熵来衡量区分度熵值过低说明标签聚合逻辑过于粗放。趋势可解释性画像显示某个标签热度上升时系统里必须有足够的底层信息单元做支撑。换句话说可解释性要求你随时能“下钻”到支撑证据而不是只给一个结论。这个维度很难量化但非常重要。5.2 经典踩坑画像被“洗流量”和“冷启动”问题开发过程中踩过一个大坑必须拿出来提醒各位不是所有文本都值得进入画像计算。我一开始把用户所有相关的文本全丢进管道里算标签结果某研究者的画像硬生生被“AI绘画”刷屏了。排查后发现原因是他参与维护的一个开源项目经常有人提关于文生图功能的Issue大量Issue文本被采集进来了但这些内容本质上不是他的研究偏好而是他作为维护者的客服工作量。这个问题实际上是“数据噪音”和“研究偏好”之间的经典矛盾。我最后的解决方案是在信息单元进入管道之前加了一个“意图门”区分主动产出和被动接收。主动产出的内容写的论文、开的Issue、提交的代码、发表的技术观点权重设为1.0被动接收的内容别人他的讨论、订阅的新闻摘要权重降为0.3且不计入活跃偏好。对于社区类数据引入了互动加权。只转发了但没有任何评论的内容权重低参与讨论、提出修改建议、贡献代码的权重高。另一个常见问题是冷启动。一个新研究对象进来没有任何历史数据画像是空的。我的做法是允许研究对象绑定一些种子属性比如他的职位是算法工程师系统的画像启动默认值会和“算法工程师人群画像”对齐再随着个人数据的积累逐步个性化。这样可以在一开始就能给出一定程度的偏好推荐虽然不够精准但比完全空白要好得多。6. 常见问题排查与备查清单6.1 上线后容易遇到的典型问题这里直接给一个我整理的排查速查表你照着看就行问题现象可能原因排查方案画像是空的数据采集没跑到检查采集源的授权范围和任务调度是否正常看信息单元表中相应来源是否有增量记录画像标签全部偏向“大模型”标签体系出现偏置大模型方向样本大量过采样检查标签体系的类别分布做类别重加权或对低频方向做数据增强画像变化波动剧烈聚合窗口太短或者噪音信息太多把时间聚合窗口从周粒度拉长到双周粒度检查“意图门”规则是否生效同一条文本反复改变标签模型输出不稳定或者使用了不同的模型版本固定模型版本在推理层加入结果缓存同一文本hash命中直接返回历史结果新概念识别不出来词表和训练数据中没覆盖把典型的“未识别样本”捞出来人工标注后加入增量训练集并同步更新领域词表画像查询接口超时聚合结果表失效或者增量计算过慢检查预聚合任务是否正常运行查询接口的时序逻辑是否退化成了全量扫描多标签分类总是漏掉次要标签训练数据的标签共现信息没利用好检查共现纠偏层的置信度提升幅度可调高共现矩阵的权重或补充共现对训练数据6.2 判断模型退化的三个定时任务系统上线之后不是一劳永逸的AI领域一个月会冒出大量新方向新玩法研究偏好的标签体系如果不更新画像很快就失真。我设了三个定时任务来防止模型退化每周一跑一次“新词发现”任务对比本周新增文本和现有词表的覆盖差异把高频出现的未登录词捞出来由人工判断是否加入领域词表。每两周跑一次“标签漂移检测”对比近两周分类结果的标签分布和长期基线的分布差异。如果某个标签的比例突然大幅上升先查是不是有热点事件造成的真实变化再看是不是模型被某些新表达方式迷惑了。每月评估一次增量训练效果用固定测试集跑一遍分类F1对比。允许有小幅波动但如果F1下降超过1.5个百分点必须排查原因——大部分时候都是训练数据分布和线上数据分布不一致造成的。这三个任务自动化程度很高跑的时长也不长但对系统长期健康的影响非常大。7. 版本迭代方向从“研究偏好”到“研究趋势”7.1 短中期加入群体趋势预测单人的研究偏好画像跑通之后我下一步要做的是群体研究趋势预测。简单说就是在完成我们团队或某个群体的个体画像之后再向上聚合成“团队画像”和“方向画像”并尝试预测未来1-3个月内哪些方向会升温。具体做法是给每个技术标签构建一个时间序列用经典的时间序列预测方法先做差分平稳化再做ARIMA或者Prophet预测未来几周的热度变化同时结合“早期研究者雷达”——识别出那些最早开始关注一个新方向的人如果这批人同时开始转向某个标签大概率这个方向要火了。7.2 长期研究偏好的“可解释迁移”个人更看好的长期方向是把AI领域的偏好模型迁移到其他专业领域。研究偏好的底层机制是相通的——数据清洗、多标签分类、实体画像、时间加权聚合、趋势预测这套方法搬到生物医药、半导体、新能源这些同样知识密集、技术迭代快的行业只需要换掉标签体系和领域词表整体架构几乎可以原封不动复用。这也是这套架构没有和某个具体业务深度绑定的原因。最后分享一个经验的话做一个偏好模型真正值钱的地方并不在模型本身而是对领域的理解——决定用什么标签、怎么定义研究对象、如何区分噪音与信号、如何让画像可解释。这些判断模型给不了你只有深入业务的人能给到。AI研究偏好模型这个方向我今天把自己踩过的坑和趟出来的路都写出来了。如果你正在做类似的事情可以照着这套思路试一遍。团队内部有自己积累的数据可以先从标签体系设计和种子标注做起模型反而是最简单的一部分。真正难的是持续运营、持续纠偏、持续理解你的用户。
