bug: Hybrid search fallback loads entire collections into memory when native hybrid fails

快速结论：这个报错发生在 Open WebUI 的混合检索（Hybrid Search）在大型知识库集合上触发原生检索失败后，系统回退到“全量内存预取 + BM25 重建”路径，导致内存暴涨、进程被 OOM 杀死。优先排查原生混合检索为何失败（例如 include_user_info_headers 相关配置），并临时关闭触发失败的配置项。

适用环境：Open WebUI v0.11.0；pgvector 向量数据库后端；已启用 ENABLE_RAG_HYBRID_SEARCH=true；知识库集合约 69 万条 chunk；容器环境受内存限制。

最快修复方案：暂无确认的一步修复方案。Issue 中维护者建议：先关闭 ENABLE_FORWARD_USER_INFO_HEADERS，跳过导致原生混合检索崩溃的调用路径，从而避免进入有问题的回退逻辑。

注意事项：该方案只是规避触发条件，并未修复回退路径本身的内存膨胀缺陷；对依赖 ENABLE_FORWARD_USER_INFO_HEADERS 的用户可能不适用。

问题场景

在 Open WebUI v0.11.0 中，使用 pgvector 作为向量数据库，且启用了 ENABLE_RAG_HYBRID_SEARCH=true。当用户向包含约 69 万条 chunk 的大规模知识库集合发起聊天请求时，一旦原生混合检索（query_doc_with_native_hybrid_search）因为任一集合抛异常而失败，代码会回退到旧路径：一次性把请求中所有集合的完整内容预取到内存中重建 BM25 检索器。该操作内存占用无上限，导致容器内存急剧攀升，最终被内核 OOM 杀死。一次原本约 1 秒的查询，被放大为多 GB 的内存分配。

报错原文

bug: Hybrid search fallback loads entire collections into memory when native hybrid fails — OOM on large collections
# Trace from the report context:
# - Previously ~1s query against a ~690k-chunk collection (pgvector)
# - After one failed native attempt: memory balloons by GBs
# - On memory-constrained host, the process is OOM-killed
# - Native failure logged at log.debug only — invisible at default log level

原因分析

可能原因如下：

在 backend/open_webui/retrieval/utils.py 中，query_collection_with_hybrid_search / query_doc_with_hybrid_search 先尝试原生混合检索 query_doc_with_native_hybrid_search，如果请求中任意一个集合的原生检索失败，整个请求就会回退到旧路径。
旧回退路径会通过 ASYNC_VECTOR_DB_CLIENT.get(collection_name=...) 预取请求中每个集合的全部内容，在应用进程内构建 BM25 检索器。这种回退是无上限的，集合越大内存消耗越大。
原生检索的失败只以 log.debug 级别记录（默认日志级别下不可见），导致操作员看到的是“正常查询突然变慢、容器内存飙升”，而不知道实际是原生混合检索已失败并触发了回退。
已知一个触发原生失败的具体原因：include_user_info_headers 在聊天路径上会崩溃（见关联 Issue #28678），任何一个集合的临时故障（embedding 波动、reranker 错误等）都会把常规对话变成“内存炸弹”。

环境排查

确认 Open WebUI 版本是否为 v0.11.0。
确认向量数据库后端是否为 pgvector。
确认是否启用了 ENABLE_RAG_HYBRID_SEARCH=true。
确认是否启用了 ENABLE_FORWARD_USER_INFO_HEADERS（若启用，可能会触发原生混合检索崩溃）。
确认知识库集合的规模（chunk 数量级），是否与报告中“几十万级”相符。
观察容器日志：将日志级别调高，确认是否存在 query_doc_with_native_hybrid_search 的异常（默认 debug 级别不可见）。

解决步骤

可优先尝试：临时关闭 ENABLE_FORWARD_USER_INFO_HEADERS。Issue 维护者明确表示，这会跳过导致原生混合检索崩溃的调用，让请求保持在原生路径，避免进入内存膨胀的回退逻辑。
将日志级别从默认调高到 WARNING 或 DEBUG，先确认原生混合检索失败的具体异常信息。
如果失败与 include_user_info_headers 无关，则需根据异常信息定位其他触发点（如 embedding 服务波动、reranker 错误等）。
临时降级方案：Issue 作者提供了一种构建期补丁，做法是把被吞掉的异常日志提升到 WARNING，并把旧的“全量预取回退”替换为调用纯向量检索的 query_collection 路径。这个补丁尚未被上游合并。
如果生产环境不允许修改代码，可以先关闭 ENABLE_RAG_HYBRID_SEARCH，改用纯向量检索，直到上游修复 #28678。

验证方法

确认问题已解决的方法：

关闭 ENABLE_FORWARD_USER_INFO_HEADERS 后，重复发起一个针对大型知识库集合的聊天请求，观察容器内存是否保持稳定，不再出现 GB 级暴涨；查询响应时间应回到原生混合检索的正常水平（如约 1 秒）。
将日志级别调到 WARNING，确认不再出现原生混合检索的静默失败。
如果采用了构建期补丁，验证在原生混合检索人为制造失败时，系统回退到纯向量检索而不是全量内存预取，且进程不被 OOM 杀死。