1. 把ChatGPT塞进广告采集器之后我到底解决了什么问题先交代一下背景。我们团队一直在维护一套广告投放端的用户行为采集系统通俗说就是“广告采集器”——用户点了哪条广告、在落地页停留多久、有没有完成注册或者下单、广告素材的曝光和点击是否正常这些数据每天有几千万条。过去这套系统主要跑规则引擎规则是运营和技术一起定的比如“点击时间小于300ms判定为无效点击”“落地页跳出率超过80%判定为低质量流量”听着挺合理实际上天天被误判和漏判折磨。无效点击清洗不干净广告主那边对账就会出问题高质量流量被误杀投放效果报表又会失真。后来我们做了一次比较大的改造把ChatGPT接进了采集器的数据处理管线让大模型参与用户行为日志的语义理解和意图判断。这里的“接进采集器”不是让大家在网页上跟机器人聊天而是把大模型当成一个数据处理组件混在原有的日志清洗、事件抽取、流量打分链路里专门用来解决规则引擎搞不定的“语义类判断”。先说结论方向是对的但折腾了不少时间。ChatGPT在广告采集场景里的价值不是“更聪明的规则”而是提供了一种以前很难实现的语义理解能力。比如判断一条用户评论、一个搜索词、一段落地页正文跟广告素材是否相关用规则只能做关键词匹配用ChatGPT可以直接读语义。但反过来说大模型的输出不稳定、时延偏高、成本按token计算如果不做架构上的适配直接把它放在实时采集链路里大概率会把整个数据管道拖垮。这篇文章就围绕这套改造展开把我从选型、管线设计、身份归一、合规脱敏、成本调优到踩坑排查的完整过程写清楚给同样在广告数据、用户行为分析方向做事的朋友一条可以照着走的路径。2. 采集器里需要“理解语义”的三个环节2.1 广告事件日志的构成和现有处理瓶颈广告采集器采集的原始数据大体分三类。第一类是曝光和点击日志这是广告系统最基础的数据记录了素材ID、广告位ID、设备信息、IP、时间戳、会话ID等第二类是转化事件包括注册、加购、下单、付费由广告主前端通过SDK或服务端回传第三类是行为上下文比如用户搜索词、浏览过的商品类目、落地页URL和页面正文摘要、客服会话中的部分文字。规则引擎对前两类数据处理得很好因为字段是结构化的。真正的瓶颈在第三类。用户搜索词是自然语言落地页正文是自然语言广告文案也是自然语言这些东西靠正则和关键词列表只能覆盖很浅的一层。比如一个用户搜索“耐用的户外背包”规则可能只匹配到“背包”但匹配不到“耐用”和“户外”这两个关键属性进一步做流量质量评估和素材相关性判断时就会出现偏差。2.2 ChatGPT介入后的判断方式我们的做法是给三个环节接入ChatGPT搜索词意图解析、广告素材与落地页内容相关性判断、无效流量语义识别。前两个容易理解第三个稍微展开一下。无效流量不只有机器点击很多低质流量是真人但意图极弱比如误触、习惯性随手点、被诱导点击。判断这类流量传统规则看的是行为特征但大模型可以结合落地页语义和用户点击的上下文做综合判断。实现上我们没有直接调ChatGPT的对话接口而是把每一步抽象成一次结构化输出任务。比如搜索词意图解析输入是一段搜索词和广告主的产品类目树输出是JSON里面包含意图分类、购买阶段、关键属性列表。素材与落地页相关性判断输入是广告文案、落地页标题、落地页前1000字正文输出是相关性评分和相关维度解释。2.3 为什么不用更便宜的小模型这是选型阶段被问得最多的问题。我们做广告数据的人都知道有些场景用BERT或者国产开源模型也能做速度更快成本更低。但我们的判断依据是业务复杂度。广告素材和落地页的内容变化极快今天还在推3C数码明天可能换到美妆个护小模型需要一个维护成本很高的训练和迭代流程。ChatGPT的优势是零样本和少样本能力很强给几条示例就能干活迭代只需要改prompt。成本也确实贵但我们在第四部分会讲怎么让它贵得值得。简单说不是所有日志都走大模型只有规则引擎拿不准的低置信度样本才走整体成本是可控的。3. 采集管线的整体设计从原始日志到结构化事件的完整链路3.1 数据链路的分层结构改造后的采集管线分五层。采集层负责接收前端SDK和服务端回传的原始日志缓冲层用Kafka抗住流量洪峰预处理层做字段标准化、IP归属地解析、User-Agent解析和设备指纹计算智能处理层是这次改造的核心大模型在这里介入最后是存储层输出到ClickHouse和对象存储。智能处理层内部又分了三个小步骤。第一步是规则引擎快速过滤能定性的直接出结果不需要惊动大模型。第二步是低置信度样本进入GPT处理队列这个队列带限流、带优先级。第三步是模型输出校验校验不通过的回退到人工规则或直接丢弃。整个过程异步执行原始日志先落一份到对象存储这样即使模型处理出问题也不会丢数据。3.2 Kafka主题设计和消息格式Kafka按业务域建了六个主题raw_click_log、raw_impression_log、raw_conversion_log、user_behavior_context、model_task_queue、model_result_topic。raw_click_log存原始点击日志保留所有字段方便排查。model_task_queue是智能处理层的输入队列生产端把需要GPT判断的任务转换成统一的JSON结构。一个典型的任务长这样{ task_id: task_8f3a2b1c9d4e, task_type: search_intent_parse, biz_context: { campaign_id: CMP-2025-0214, ad_group_id: AG-7781, search_query: 耐用的户外背包 轻量 大容量, product_category_tree: [运动户外背包, 运动户外户外配件], ad_text: 轻量户外背包40L大容量耐磨防水, landing_page_title: 专业户外背包系列-轻量耐用, landing_page_snippet: 采用高强度尼龙面料支持40L扩容适用于登山、徒步、骑行 }, rule_engine_verdict: low_confidence, priority: 5, timestamp: 1739000000000 }有一点很关键给模型的字段不传用户手机号、不传设备IMEI、不传账号ID之外的非必要信息。这是从源头上控制隐私风险而不是等到后面做合规审批时再补救。3.3 模型返回结果的约束设计调用ChatGPT时我们在prompt里强制约束输出格式。用system prompt规定任务背景和角色用few-shot示例给出两个输入输出对最后要求“只输出JSON不要额外说明”。{ intent_class: purchase_intent, purchase_stage: comparison, key_attributes: [轻量, 大容量, 耐用, 户外], relevance_score: 0.87, relevance_reason: 搜索词强调轻量耐用与广告文案高度吻合落地页标题直接匹配, confidence: 0.92 }这里需要提醒一点模型输出的字段值不一定稳定。有两次模型给relevance_score返回了“87分”而不是“0.87”还有人遇到过JSON里多出一个注释字段的情况。所以后面必须接一个schema校验和值域清洗的环节校验不通过就进入重试队列。4. 用户身份关联链路设备ID、Cookie、登录态的归一化处理4.1 广告系统为什么需要做身份归一“追踪用户”这个词在网络语境里听着有点吓人但在广告行业它的真实含义是把同一个用户在不同时间、不同设备上的行为拼成一张完整的路径图。今天下午你在一台手机上点了某电商App的广告晚上又在平板上看了同一个商品详情页广告系统需要知道这两个动作很可能来自同一个人才能控制广告频次、避免重复投放、合理归因转化。业界通常把身份归一分成三个层级。第一层是确定性ID比如登录后的用户ID、手机号、邮箱第二层是半确定性ID比如同一账号体系下的设备Cookie第三层是概率性ID比如设备指纹、IPUser-Agent组合。这套体系原本就在跑这次改造的重点是把大模型引入到身份归一的“模糊匹配”环节辅助判断两个匿名设备是不是同一个真实用户。4.2 基于行为和属性的相似度判断传统做法是算相似度分数比如设备指纹相似度、访问时段重合度、IP切换规律一致性。问题是特征一多规则就很难定义权重。比如A设备和B设备的IP不同但Wi-Fi名称相近、访问时间序列高度一致、浏览的广告素材序列也几乎相同这种情况用固定权重很容易误判。我们改成让ChatGPT对一组行为特征做综合评估。输入一组设备信息和对应的行为摘要输出一个“同一用户置信度”和关键判断依据。但这里有一个很严格的使用边界只有两个匿名ID之间的匹配才会用到模型任何涉及个人敏感信息的判断都不允许进入模型处理链路。一个简化版的输入长这样{ task_type: identity_match, device_a: { device_fp: a3f8c2d1e9b44788, ua: Mozilla/5.0 (iPhone; CPU iPhone 16 Pro Max like Mac OS X), ip_segments: [203.0.113.0/24], active_hours: [9, 10, 21, 22, 23], click_sequence: [ad_1001, ad_1003, ad_1005] }, device_b: { device_fp: b7d1a0e2f3c59021, ua: Mozilla/5.0 (iPhone; CPU iPhone 16 Pro Max like Mac OS X), ip_segments: [198.51.100.0/24], active_hours: [9, 10, 21, 22], click_sequence: [ad_1001, ad_1002, ad_1005] } }模型输出的结果里必须包含理由不只是一个分数。理由的作用是供运营在抽检时快速判断模型是不是“瞎猜”同时也是审计凭证。我们遇到过模型仅凭UA相同就给了0.9以上置信度的情况这正是需要人工抽检和规则兜底的原因。4.3 身份图的构建和存储策略模型判定的结果会落到身份图服务里存储结构用图数据库方便表达“设备A↔设备B可能同人”这种关系。每次新的判断都带着置信度多个证据链汇聚时置信度会动态调整。身份图里不存姓名、手机号这类直接个人身份信息只存匿名化的ID和特征向量。落地时有一个很务实的决策置信度低于0.6的关系不写入身份图只记录到短期缓存里用于当次归因分析。这么做的原因是避免低置信度关系污染长期用户画像导致后续频控和归因越来越偏。5. 数据合规与脱敏机制哪些数据能进模型哪些绝对不能碰5.1 广告数据合规的三个基本红线这个环节必须写在技术设计的最前面而不是等出了事再补。我们在整个管线里划了三道红线。第一原始日志中的直接标识符如手机号、邮箱、身份证号不进入模型任务队列。采集层直接做字段过滤能加密的加密能去掉的去掉。第二文本内容必须经过PII检测才能进入模型输入。用户搜索词、评论、客服会话等自由文本里可能夹带手机号、地址、订单号过一遍PII检测器再决定是否截断。第三模型输出不能用于用户画像的“附加标签”。比如模型判断搜索词带有购买意图这个结论可以用于当次广告召回和频控但不能直接写进用户画像当成永久标签。5.2 PII检测的工程实现我们自研了一套轻量PII检测服务部署在预处理层和智能处理层之间。检测规则涵盖手机号、邮箱、身份证号、银行卡号、精确地址等模式还接了一个自定义词库用来识别广告主提供的敏感特征词。检测到PII后不会直接拒绝整条数据而是做分段掩码处理比如把手机号替换成“138****8000”再判断掩码后的文本是否仍能支持模型完成任务。这里有一个经验PII检测的召回率比精确率重要。宁可误杀一些正常文本宁可让模型处理时少一些上下文信息也不能放真实敏感信息进入模型。误杀导致的效果损失可以通过补充业务字段来缓解但隐私事件导致的影响是不可逆的。5.3 数据保留周期和审计日志采集器改造后我们同步建立了数据保留策略。原始日志保留30天模型输入输出对保留90天身份图关系保留12个月超出周期的数据自动清理。每次模型调用都产生一条审计记录包含任务类型、脱敏方式、模型版本、token用量和处理结果校验状态。这份审计日志面向两类读者内部合规团队做抽检广告主在广告审核时提供处理依据。这块工作看起来不产生直接业务价值但在广告行业这是必须的。如果没法证明你的数据处理链路是合规的客户就不会把数据交给你业务根本跑不起来。6. 成本、延迟和重试策略把大模型调进生产链路的技术账6.1 为什么不能每条日志都实时调ChatGPT最直接的答案是钱和延迟两块都会爆。广告点击日志是高峰值流量双十一这种节点每秒涌入几十万条点击如果每条都走大模型API费用按小时算就是天文数字而且模型接口的P99延迟在3秒以上实时链路完全扛不住。我们的策略是分级处理。规则引擎能给出明确结论的直接出结果大约覆盖70%到80%的流量只有规则引擎置信度低于阈值、或者任务本身属于强语义场景的才进入模型任务队列。这条策略上线后实际走大模型的日志比例降到了总流量的5%左右成本下降了接近一个数量级。6.2 模型分级轻量模型兜底大模型解决难样本进到模型队列的样本我们还要再分一级。先让一个小参数模型跑一遍如果置信度足够高就直接采用信心不足的再交个大模型。这样做切切实实省了钱因为我们做过统计最终真正需要大模型处理的只有模型任务队列的30%左右。举个例子。搜索词“耐用的户外背包”小模型结合关键词词库已经能比较准确地给出意图分类就不需要大模型出场。但搜索词“便宜大碗的包要能装电脑最好防泼水平时通勤和短期出差都能用”这种情况小模型输出结果置信度不高才需要大模型理解完整语义。6.3 异步任务队列和失败重试的细节模型处理全部异步化原始日志先落存储不等待模型结果。消费者服务从Kafka拉任务调用模型接口时设置超时时间为15秒。任务失败分三种情况网络超时、模型返回格式非法、模型返回内容为空。网络超时直接重试最多三次超过三次进死信队列人工处理格式非法走schema校验失败分支重新构造prompt再送一次内容为空直接放弃不影响主链路。还有并发控制。我们给模型接口调用配置了信号量最大并发数平时设置为32高峰期调到64。实测超出这个值之后接口错误率明显上升返回时间也更长不是为了省配额而是为了稳定延迟。6.4 token用量的分账与监控团队内部做了“token消费分账”。每个业务线一个项目代号prompt模板固定部分和动态部分分开统计。模板固定部分即使不被真正使用也算token所以设计prompt时我们把固定说明压到最短示例尽量精简用逗号而不是自然句分隔字段。加了最小化模板优化后单次任务的平均token消耗降低了40%。另外监控面板上除了常规的API错误率还加了“重试率”“schema校验失败率”“大模型推理结果与规则引擎冲突率”三个指标。最后一个指标尤其有用它反映的是模型与原有规则的意见分歧程度。分歧率很高时我们就会抽样本出来人工判断是模型错了还是规则过时了。7. 踩坑实录模型幻觉、字段漂移和并发风暴7.1 幻觉问题模型给无效点击编了一个离谱的理由上线一周后就碰到一次事故。有一条广告点击日志的用户Agent是“python-requests”这个特征在规则引擎里基本可以断定是脚本或爬虫流量但那条日志走了大模型分支。模型在判断理由里写道“用户可能在自动化工具的辅助下进行的操作但也不排除真人通过命令行浏览器访问”最后给了一个0.55的置信度。这就是典型的“模型知道规则但没有内化规则优先级”的情况。我们修复的方式是在prompt里加入“硬性规则提示”——如果输入的UA特征命中已知爬虫特征库直接输出invalid_click并给出标识不需要做语义推测。同时把这个判断在模型之后再用一层规则兜底强制执行。大模型负责语义规则负责事实两者分工明确。7.2 JSON输出不断漂移解决结构不稳定问题第二个坑是模型输出格式的稳定性。ChatGPT在连续多次调用中偶尔会在JSON里加一个额外的“note”字段或者把数字写成字符串。单个任务影响不大但每天跑几十万个任务哪怕只有1%的不稳定输出也会产生几千条需要重试的数据。我们做了三层处理。第一层是在prompt里把输出样例压缩到最短要求严格按样例格式输出。第二层是解析端做宽容解码兼容数字字符串、多余空行、重复字段名等常见问题。第三层是所有低置信度输出自动重试一次换一个输出结构更稳定的参数配置。最终结构稳定性从最初的96%提升到了99.5%以上。7.3 并发超限导致的任务积压高峰期并发调大后反而出现了一批模型调用超时。排查后发现是信号量虽然配了64但底层队列的消费者的心跳超时配置过短导致任务重复提交。修复方式是调整消费者的心跳间隔和会话超时时间同时给同一任务增加幂等键消费端对相同task_id只处理一次。这次事故也推动我们做了一个很受用的设计——把模型任务处理的中间状态全部写进日志里。每个任务从入队、开始调用、成功返回、校验通过、落库五个状态都有记录。出了问题可以直接按task_id追全程不用猜哪一步卡的。7.4 处理结果与规则引擎的冲突另外一个值得展开的问题是模型判断结果与规则引擎结论冲突。系统里存在一部分广告点击规则引擎判定为“无效点击”大模型综合语义上下文后判定为“有效点击”。起初我们选择相信模型后来抽样人工复核发现大模型在这种情况下判断正确的比例并不高原因在于模型看不到规则引擎独有的信号比如该IP段当天已触发多次异常行为规则。后来我们把规则引擎的判定依据和中间特征也拼到模型的输入里让模型在知道规则结论的前提下做语义判断。这么做之后模型与规则的冲突率明显下降也减少了很多不必要的重跑和人工复核。8. 可复用的推进路径和写给同行的话如果要在自己团队里复制这套方案我认为最务实的路径是先小后大先跑通一条链路再做横向扩展。第一步先把采集器现有日志按“结构化字段”和“自然语言字段”分类识别出当前用规则处理效果最差的一类数据。通常建议从搜索词意图解析或广告素材与落地页相关性入手因为这两个场景的业务价值明确结果也好验证。第二步构造一个离线评测集。从历史日志里抽几百条数据由运营按现有标准打标签再让ChatGPT对同一批数据做预测对比一致率。这一步不花多少钱但能真实评估模型在当前业务数据上的效果。第三步再接入生产链路但一开始只接小流量。我们当时是把模型任务的流量控制在总处理量的1%左右跑了一周才逐步放开。这一步是为了观察模型在真实数据上的输出质量、调用时长和异常率比任何离线评测都准。第四步跑通之后再考虑成本优化、并发控制、多模型分级这类进阶工作。最后一段话写给正在犹豫要不要把大模型接进广告数据链路的朋友。这个方向的实际产出不是“更智能”而是“以前做不到的语义判断终于能做到”但代价是引入了新的不稳定性和成本项。不要因为它是大模型就觉得可以解决一切问题它在广告采集器里扮演的角色更像一个“高级语义判断组件”需要规则、schema校验、人工抽检这些老一套工程手段围着它转。我们跑了大半年最稳定的配置是规则引擎做第一道闸小模型处理中等样本大模型专注解决难样本人工抽检保底。这套组合虽然听起来不够“前沿”但在生产环境里是真的能扛住流量的。