我是AI时代的无业游民我游荡在现实与意念之间当广告采集器成为大模型的眼睛跨站上下文注入的架构与代价背景与痛点过去一年一个微妙的变化在浏览器与对话式 AI 之间发生你在电商站点浏览过的商品、在技术论坛停留过的页面、在新闻站滚动过的段落正以某种广告采集的名义被汇聚进对话模型的上下文里。用户打开 ChatGPT 提问时它给出的回答已经不只是基于你刚刚输入的那句话而是叠加了一层来自其他站点的行为画像。这件事的技术本质并不神秘跨站追踪早已存在广告技术栈里的像素、SDK、Cookie 同步、fingerprint 采集已经跑了很多年。真正的新问题是——当这些信号不再只用于投放广告而是作为大模型的检索上下文进入推理链路时系统的边界、延迟、隐私与失效模式全部变了。不解决的代价很直接。对开发者而言如果你在做 RAG、Agent 或任何带外部上下文的产品你会遇到三个真实故障其一上下文污染。跨站采集来的数据噪声极高用户三小时前点开的一个无关页面可能让模型在回答当前问题时跑偏。其二延迟不可控。广告采集链路通常是异步、最终一致的当它被接入同步推理请求时P99 延迟会被这条旁路拖垮。其三合规与信任。一旦用户感知到自己的浏览行为被用于对话产品信任度会断崖式下跌且面临 GDPR、CCPA 以及国内《个人信息保护法》下的合规风险。所以真正要回答的问题不是能不能做而是我们该用什么架构把跨站信号安全、可控、可解释地注入到模型上下文里方案设计思路与选型核心思路是把采集与注入解耦成两条独立链路中间用一个可审计的上下文仓库做缓冲。采集侧沿用广告技术栈的成熟能力像素、SDK、事件上报注入侧则完全由我们控制走检索增强RAG的路径而不是把原始行为流直接塞进 prompt。选型上有三个关键决策决策一推送 vs 拉取。采集侧推送webhook / 消息队列实时性好但会把噪声和突发流量直接打到推理侧拉取推理时按需查询延迟高一点但可以做过滤、聚合、限流。我们选择拉取为主、推送为辅——低频高价值事件如加入购物车走推送预热高频低价值事件如页面滚动只在拉取时聚合。决策二原始事件 vs 画像摘要。把原始事件列表塞进上下文token 消耗巨大且噪声高。我们选择在仓库侧做离线聚合生成画像摘要推理时只取摘要。代价是时效性下降分钟级但换来 token 成本下降一个数量级。决策三隐式注入 vs 显式引用。隐式注入模型自动使用体验顺滑但不可解释、难合规显式引用用户可见本次回答参考了你的浏览记录体验略重但可审计。我们选择显式引用为默认隐式注入需用户显式授权。明确放弃的方案我们放弃了在浏览器端直接把跨站数据拼进 prompt的写法。看起来能跑但线上会炸一是客户端可被篡改注入内容不可信二是无法做服务端限流和审计三是 token 预算完全失控。也放弃了全量事件实时入 prompt原因是延迟与成本都不可接受。维度推送实时注入拉取画像摘要选定客户端拼接延迟低中低成本高低中可审计差好极差合规风险高可控高核心实现上下文仓库的数据模型仓库不存原始事件流而是存按用户时间窗聚合的画像分片每个分片带来源域、置信度、TTL。这样做的原因是让注入侧可以做细粒度取舍。fromdataclassesimportdataclass,fieldfromtypingimportLiteraldataclassclassProfileShard:user_id:strsource_domain:strtopic:str# 聚合后的主题标签confidence:float# 0~1来自采集侧的置信度last_seen:int# epoch 秒ttl:int3600# 过期时间默认 1 小时sensitivity:Literal[low,mid,high]lowraw_ref:str|NoneNone# 指向原始事件的引用按需展开defis_fresh(self,now:int)-bool:returnnow-self.last_seenself.ttl关键点是sensitivity与ttl高敏感分片如医疗、金融相关域默认不进入推理上下文即使被拉取也会在注入前被过滤。这是看起来能跑、线上会炸的典型点——很多实现只做相关性排序忘了敏感度分级。注入侧的检索与预算控制注入不是把所有分片拼起来而是按当前 query 做相关性检索并在 token 预算内做贪心选择。我们用轻量 embedding 做召回再用规则做重排。defbuild_context(query_vec,shards,now,token_budget800):candidates[sforsinshardsifs.is_fresh(now)ands.sensitivity!high]# 召回向量相似度scored[(s,cosine(query_vec,embed(s.topic)))forsincandidates]# 重排置信度 * 新鲜度衰减scored.sort(keylambdax:x[1]*x[0].confidence*decay(x[0],now),reverseTrue)picked,used[],0forshard,scoreinscored:costestimate_tokens(shard.topic)ifusedcosttoken_budget:breakpicked.append(shard)usedcostreturnpickeddecay是时间衰减函数通常用指数衰减。这里放弃按分数阈值截断的写法因为阈值在不同用户间不稳定改用预算驱动的贪心保证 token 上限硬约束。引用与审计每次注入都要落审计日志记录哪些分片被使用、来源域、时间。这既是合规要求也是线上排障的依据。deflog_injection(user_id,picked,request_id):audit{request_id:request_id,user_id:user_id,shards:[{domain:s.source_domain,topic:s.topic,confidence:s.confidence}forsinpicked],}audit_sink.write(audit)# 异步写入不阻塞推理注意审计写入必须异步否则又会把延迟拖回同步链路。效果验证验证分三层离线层构造 1 万条带标注的 query对比无跨站上下文与有跨站上下文的回答相关性用 LLM-as-judge 打分。预期相关性提升但方差增大需观察噪声是否可控。延迟层压测 P50/P99。拉取链路必须设超时如 80ms超时即降级为无跨站上下文绝不阻塞主推理。这是可复现的注入一个 200ms 延迟的 mock 仓库验证 P99 不劣化。合规层抽样审计日志确认高敏感分片从未进入上下文确认用户可查询和删除自己的画像分片。这一步不能省否则上线即埋雷。复现步骤部署仓库 mock → 灌入合成事件 → 发起带 query 的推理请求 → 检查返回的引用列表与审计日志是否一致。边界与演进局限画像摘要是分钟级聚合对刚刚发生的强时效场景不适用跨站信号的置信度依赖采集侧质量采集侧被污染时注入侧无法自救显式引用会牺牲部分体验顺滑度。不适用场景强实时交互如实时协作、高敏感行业医疗、金融默认应关闭跨站注入或只允许用户显式授权的白名单域。下一步优化一是引入用户可控的域白名单/黑名单把控制权交还用户二是把注入决策从规则重排升级为学习式排序用点击/采纳信号做反馈三是探索联邦式画像让原始数据不出域只交换聚合摘要从架构上降低合规压力。回到最初的问题跨站信号进入大模型上下文本身不是技术难题难的是在延迟、成本、合规、体验四者之间找到可运营的平衡点。把采集与注入解耦、用画像摘要替代原始事件、用预算驱动替代阈值截断、用显式引用替代隐式注入——这四条决策构成了当前阶段最稳的工程答案。它们不是终点但至少能让你的系统在线上活下来。