RAG与LLM原理及实践（13）--- hybrid async search 使用及源码分析
目录
背景
源码分析
主逻辑
SearchFuture
base父类 Future
done
result
done VS result 区别
hybrid 异步调用应用层代码写法
应用层代码写法
执行结果分析
背景
milvus hybrid search 确实效果还不错，但是有的场景，比如我们在分布式系统中由于需要较高的query 准确率，我们将TSO 相关的参数包括 guarantee_time, graceful_time 等设置比较长，而且 data consistency 有可能不是 Strong，nprobs 有可能也比较大，又比如说 ef 设置比较大，HNSW或者说是 ANN search 算法本身可能也比较耗时，整体来说，search 整体可能较慢。再者如果我们需要处理的请求很多，或者说client端希望这个时候还能做点其他事情，比如我们正在录入新的 data，需要milvus 同步，又或者是做一些与我们主应用相关的其他事情。当然你可以使用 thread pool 的方式来解决这个query pending的问题，为每一个query 去设置一个 thread，用时间片+thread轮询的方式来做管理。设计上这样做问题不大，但是如果query 非常多，且client task loading 比较重，这样就不合适了，需要借助更高效的实现方式来完成，最好能借助 event io 或者其他更好的机制来实现。但是单独实现这个逻辑是比较费劲的。因为它需要client端与server 端配合改动。如果说只是改动client 端，我想问题可能比较简单，但是如果需要改动到 server 端，就比较麻烦了，虽说 milvus 本身开源，但是你如果不了解所有代码的原理及实作方式，还有如何进行二次编译，可能很难达到效果。官方给出的 hybrid_search 是可以支撑我们以async 的方式进行 hybrid searc