京东零售技术

AI Agent

RAG 2.0 在 RAG 1.0 的基础上，进行了三大改进：

向量多路召回
- 场景：部分有用的内容，相关度不够，无法召回。
- 剖析：向量召回的分数与相关内容密度强相关，理论上密度越高，相关分值越高。同理，文档内容越短时相关内容密度也就越高。
- 方案：构建知识的向量时，对同一份知识，构建“概述”和“内容”两份向量。“概述”内容短，密度更高，更容易有高相关性。
ES 检索
- 场景：同义词、专用词无法很好处理。
- 方案：新增一路 ES 检索，通过自定义分词器中的同义词、专用词、禁用词的方式，来实现部分内容的召回。比如，同义词设置：智能计划 ⇒ 智能出价计划（解决用户习惯的问题）、购物触点 ⇒ 推荐广告京挑客 ⇒ 京东联盟（解决产品线升级改名的问题）..
重排序
- 场景：上述选取后，召回的知识可能存在不相关性，需要再筛选。
- 方案：引入 ReRank 模型，在知识召回后，调用算法侧部署的 ReRank 服务，对知识进行重排序，过滤无关知识。

Agent搭建平台|640

Agent 引擎的取舍 —— 是否使用 Langchain？若模型需要使用 JSON 形式，但是使用 Langchain 会 Json → Pydantic → Json，增加耗时。因此最终选择使用原声 Python，只针对特定的工具采用 Langchain 形式。

整体上，设计了一套工作流调度器，并将所有节点实现了组件化。收到请求后会初始化一个工作流调度器，调度器根据时机来操作每个节点的执行。

不清楚这里是线程池去执行的各个节点的逻辑还是一个线程去处理一个工作流的任务。

发生背景：

由于可能出现大 Key 或者热点 Key 问题，所以服务增加了本地 JVM 缓存，5 分钟失效后再去 Redis 查询。
缓存击穿(JVM 到 Redis 的缓存击穿) ：活动缓存只写入到 Redis 中，本地缓存是空的，当活动上限后，同时有大量请求访问 Redis。
网络带宽瓶颈：大热 Key 大小为 1.5M，京东 Redis 对单分片对网络带宽进行限流为 200M，导致热 Key 最多支持 133 次的并发。再加上缓存击穿，导致 Redis 线程进入阻塞状态，以至于所有业务服务器都无法查询 Redis 成功，最终缓存雪崩。

解决方案：

大 key 治理：更换缓存对象序列化方法，由原来的 JSON 序列化调整为 Protostuff 序列化方式。治理效果：缓存对象大小由 1.5M 减少到了 0.5M。
使用压缩算法：在存储缓存对象时，再使用压缩算法（如 gzip）对数据进行压缩,注意设置压缩阈值，超过一定阈值后再进行压缩，以减少占用的内存空间和网络传输的数据量。压缩效果：500k 压缩到了 17k。
缓存回源优化：本地缓存 miss 后回源查询 Redis 增加线程锁，减少回源 Redis 并发数量。
监控和优化 Redis 配置：定期监控 Redis 网络传输情况，根据实际情况调整 Redis 的限流配置，以确保 Redis 的稳定运行。

其他思考：是否应该增加一个缓存预热功能，当大促来临之前的一段时间内，服务在随机时间后访问 Redis 将必要的缓存加载到 JVM 中？

背景：将 MongoDB 数据切换到 MySQL、ES 中。

方案：

增量数据先写 MongoDB 再写 MySQL，以 MongoDB 写入成功为准，写 MySQL 失败，MQ 异步补偿。

上线前的数据校验：

增量数据比对：双写数据完成后发送 MQ，消息里面查询新库，老库的数据进行实时比对，不一致数据记录不一致字段，关键字业务报警，写入日志文件，导出分析。
存量数据比对：遍历全量老库数据，与新库查出数据，转换成相同对象对比数据一致性，异常数据写入日志文件分析。
重放流量：通过重放线上流量来加快对比速度。
灰度读切流：读切流，按照供应商和采销白名单+百分比来切流。切流时，由于需要根据 pin 对流量分散，但是不在同一线程内，使用 threadlocal 对商户信息进行设置和读取。
灰度写切流：
- 首先验证写新库没问题，相当于对新加代码进行灰度，如果有问题进行回切。
- 当验证写新库没问题，需要补齐数据库数据
- 当数据补齐后转换为主写新库
- 后续如果读写新库都没问题可以彻底下线旧库存