调LLM失败怎么做的重试和rollback

> Dubbo: 在 doInvoke() 方法中，请求失败时会调用 addFailed() 方法添加定时任务进行重试，默认每隔 5 秒执行一次，总共重试 3 次

命中查询不能用布隆过滤器因为有哈希碰撞，用set保存也不行太大了（实习没注意看存储架构） 用的Roaring64NavigableMap

JAVA 锁，被问N次

Mysql 索引结构

Redis数据结构

IO多路复用，Redis一定是单线程嘛

同时购买同一个商品，库存扣减。用redis管理库存，会不会出现线程A读取库存是5，线程B读取库存也是5，但这个时候其实A已经购买一份了，库存应该是4了，结果会不会是A和B都购买了一份，但是库存还是4

我把判断库存和扣减库存写在一个Lua脚本中，因为Lua脚本在Redis中是原子执行的。不可能存在上述情况，线程A只有扣减成功，线程B才会执行读库存扣库存。如果Redis是集群模式，Redis集群通常采用分片（sharding）方式，将数据分布到多个节点上。每个节点负责一部分槽位（slot）。对于单个键的操作，因为一个键只存在于一个节点上，所以即使是在集群模式下，对单个键的Lua脚本操作也是原子性的。主从的话，在主从架构下，扣减库存的Lua脚本在主节点执行，由于原子性，不会出现超卖。但是，如果主节点宕机且未同步到从节点，会导致扣减操作丢失，从而出现库存不一致（即实际已经扣减，但宕机后库存恢复）这就是其他redis高可用问题了

分布式定时任务广播的原理，啥协议通知到多台机子上？

Rag优化：

1. 混合检索（Hybrid Search）

在实际项目中，我们通常不会只用单一检索方式。 然后加权

1. 稀疏检索（Sparse Retrieval）：比如 BM25、TF-IDF，基于关键词匹配，优点是可解释、快速，但对语义理解差。
2. 密集检索（Dense Retrieval）：比如使用向量模型（如BERT、E5、bge），基于语义相似度，能理解“同义表达”，但有时会引入“语义噪音”。

2. 两阶段检索（Recall + Rerank）

这是很多成熟方案（如Cohere RAG、LangChain RAG Fusion）的标配。

• 阶段一：召回（Recall）用轻量模型（如向量检索）快速筛出top-N候选文档。重点是召回率要高，宁可多，不要漏。
• 阶段二：重排（Rerank）用更强的模型（如Cross-Encoder、bge-reranker）对召回结果重新打分。重点是精确率要高，把噪音干掉。

query查询改写/扩展（Query Rewriting & Expansion）

除了分块，有两个高级优化方向：

• 元数据索引给每个文档加上来源、时间、类别等标签，便于检索器过滤。例如：“只取最近30天的新闻”。
• 图结构检索（GraphRAG）微软近年提出的新方向，把知识库构造成图（Graph），节点是实体、边是关系。 检索时可以沿着语义路径走，找到更有逻辑联系的内容。GraphRAG的优势在于，它能让“知识检索”从孤立片段变成“关系网络”，尤其适合复杂知识问答或企业知识库。

RAG的最大风险之一，是模型“编故事”——也就是幻觉（Hallucination）。

优化手段包括：