-
我的 RAG 问答系统明明把含有答案的文档块召回来了相关度也不低就老老实实塞进了给大模型的上下文里,可模型偏偏视而不见答不出来,而我把同一个块挪到 prompt 的开头或结尾它立马就答对了,排查很久才搞懂大模型对长上下文里不同位置的信息利用率根本不一样夹在中间的内容最容易被它忽略掉的深度复盘
我做了个基于 RAG 的文档问答:用户提问先从向量库召回若干相关块、拼成上下文塞进 prompt 让大模型基于这些内容回答,整体不错但有一类问题百思不得其解:对某些提问模型回答根据提供的资料无法找到相关信息,可我把召回的块逐个翻出来一看答案明明白白就在其中某一块里、而且那块检索相似度还不低排在召回中游;我确认那个含答案的块确确实实被拼进上下文发给了模型不存在被截断丢掉,模型是拿到了却没看见;我做对…- 0
- 0
-
我给 AI Agent 加了长期记忆,想让它把每次交互都记下来、越用越聪明,结果它什么都往里塞、记忆越堆越多,反而被一堆无关的陈年旧事淹没、判断越来越差的深度复盘
我做了个 AI Agent,为了让它有记性、越用越懂用户,给它加了长期记忆:把每次交互、用户说的每句话、它做过的每件事统统记下来,下次决策时检索出来塞进上下文。我满心期待它像越来越资深的老员工。可现实相反:用得越久它反而越糊涂——回答当前问题时扯出一堆很久以前毫不相干的内容,被早已过时的旧记忆(用户半年前说喜欢 A、后来改喜欢 B 了)带偏给出错误判断,响应越来越慢越来越贵。一查记忆库倒吸凉气:5…- 0
- 0
-
我用 ThreadLocal 存当前登录用户,本以为线程私有绝不会串,结果某个用户偶尔会看到另一个用户的数据,因为在线程池里线程是复用的、用完没清的 ThreadLocal 残留给了下一个请求的深度复盘
我用 ThreadLocal 存当前登录用户(请求进来时 set、后续各层从 ThreadLocal 取,避免层层传参),想当然以为 ThreadLocal 线程私有、每个请求一个线程各存各的绝不会串。结果线上出了最可怕的 bug:偶发地某个用户页面上显示出了另一个用户的数据(订单、隐私),用户身份串了、是严重越权。排查才定位到线程池:Web 服务器用线程池处理请求、线程是复用的(处理完一个请求会…- 0
- 0
-
我给 AI Agent 配了三十多个工具想让它无所不能,结果它反而经常选错工具、在几个功能相近的工具间反复横跳、甚至漏掉该用的那个,工具给得越多任务完成得越差的深度复盘
我做了个 AI Agent,本着能力越全越好,给它配了三十多个工具:查用户、查订单、查库存、发通知、查日志、改配置……而且很多功能相近、命名相似(同时有 query_user、get_user_info、fetch_user_detail 几个差不多的)。我以为工具越多 Agent 越强。可实际跑下来表现不升反降:它经常选错工具、在几个功能相近的工具间反复横跳、有时漏掉本该用的那个、把简单任务绕成…- 0
- 0
-
我给 AI Agent 写了个查数据库的工具,某次它查出了几万行结果原封不动塞进了对话上下文,当场超出 token 上限报错,就算没报错模型也被海量数据淹没得抓不住重点:一次工具返回过大塞爆上下文的深度复盘
我做了个 AI Agent,配了个 query_database(sql) 工具让它查业务数据。平时挺好用,直到某次用户问把所有订单列出来分析一下,Agent 生成了个没加 LIMIT 的查询,工具查出几万行、我原封不动拼成字符串塞回上下文,当场 context length exceeded 报错、对话崩了。我截断到不超限后问题依旧:模型被几千行原始数据淹没、抓不住重点、又慢又贵又含糊。复盘才想…- 0
- 0
-
用户A看到了用户B的信息:ThreadLocal 串号避坑
这是我职业生涯里最惊出一身冷汗的一次线上事故。我们用 ThreadLocal 存当前登录用户的上下文——请求进来时在拦截器里把用户信息塞进 ThreadLocal、后续业务随时取当前是谁,用了很久一直稳稳的。可某天客服收到一个让所有人头皮发麻的投诉:一个用户登录后在自己的页面里看到的却是另一个陌生用户的姓名手机号订单,用户信息串了——这涉及隐私泄露性质极其恶劣。连夜拉日志排查才拼出全貌:Web 服…- 2
- 0
上下文
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×