2026.3.6
讲一下召回重排策略
- 召回重排是推荐系统和搜索系统中常见的一种两阶段排序架构。
第一阶段是 召回（Recall），主要是从海量数据中快速筛选出一批可能相关的候选集合，比如从上百万条数据中召回 Top100。召回更关注的是 速度和覆盖率，常用的方法包括 向量召回M25关键词召回、以及混合召回。
第二阶段是 重排（Rerank），会对召回得到的候选集合进行更精细的排序。因为候选数量已经比较少，所以可以使用更复杂的模型，比如 Cross-Encoder 或深度排序模型，计算 query 和 document 的相关度，然后重新排序，选出最终的 TopK 结果。
这种架构的好处是 既保证检索速度，又提高结果的准确性，在推荐系统、搜索引擎以及 RAG 检索增强生成中都非常常见。
怎么增加召回率
多路召回，比如同时使用 向量召回和关键词召回（BM25），然后合并结果，这样可以提升覆盖率。
增加召回数量，例如把 Top20 提高到 Top50 或 Top100，再通过后续的重排模型筛选。
优化查询和数据处理，比如进行 Query Rewrite、同义词扩展、分词优化，提高匹配概率。
优化向量模型和向量库参数，例如使用更好的 embedding 模型或调整向量检索参数。
文档切分（chunking）优化，让知识粒度更细，提高匹配概率。
知识库切片方式有哪些方式，你是用的什么切片方式，为什么
常见的知识库切片方式包括 固定长度切片、滑动窗口切片、语义切片和层级切片。在我的项目中主要采用 固定长度加滑动窗口的方式，但是 FAQ 类型知识库，可以直接Q + A 作为一个 chunk，因为这种方式实现简单，同时可以避免上下文被截断，提高检索召回率。
chunk切太小或太大会有什么问题？
- 保证语义完整，如果 chunk 太小可能会破坏句子或段落语义。
- 提高检索精度，如果 chunk 太大可能包含多个主题，导致向量表示不够聚焦。
- 控制 LLM 的上下文长度，因为 RAG 会把多个 chunk 拼接到 prompt 中，chunk 过大会导致 token 消耗过高。
项目之间是怎么通信的
在我的项目中，主要采用 HTTP API 的方式进行服务之间通信。
比如在 AI Agent 架构中，Go 主要负责业务逻辑和接口层，而 Python 服务主要负责 AI 相关能力，例如意图识别和 RAG 检索。Go 服务会通过 HTTP 请求调用 Python AI 服务，获取识别结果或者生成内容。
这样做的好处是 实现简单、语言无关、方便部署和调试。同时如果后期系统规模扩大，也可以逐步升级为 gRPC 或通过消息队列实现异步处理。