[BUG]: Changing Vector Database Setting to “Accuracy Optimized” causes Connection error on second prompt

快速结论：该报错通常出现在 AnythingLLM 桌面端把工作区的向量数据库检索偏好从默认切换为 “Accuracy Optimized”（会启用重排序 reranker）后，第二次提问时流式响应中断并提示网络错误，随后整个应用无响应。优先排查后台日志中 reranker 是否在第二次请求时复用已初始化模块后挂起或崩溃，并确认机器内存与向量数量是否导致重排序压力过大。

适用环境：AnythingLLM Desktop App 1.9.0-r2；向量数据库 LanceDB；Embedder 为 AnythingLLM 内置 all-MiniLM-L6-v2；Chunk size 250、Overlap 20；LLM 使用 LocalAI；工作区运行在 Query Mode；用户报告硬件为 DXG A100 Station 80G。上述为 Issue 中用户自述环境，非官方确认的通用复现环境。

最快修复方案：暂无确认的一步修复方案。该 Issue 以 “needs info / can’t replicate” 关闭，未给出维护者验证过的修复。可优先尝试将工作区 Search Preference 改回默认设置，确认是否恢复可用。

注意事项：重排序（reranking）在大向量量级下计算密集，日志显示仅重排 50 篇文档就耗时约 1300ms，之后第二次请求出现“复用已初始化模块”后无后续日志的情况，疑似挂起或崩溃，但具体根因未被维护者确认。Issue 中出现的 PostgreSQL 连接池 / hnsw.ef_search 说法与用户实际使用的 LanceDB 环境不一致，不应直接照搬。

问题场景

用户在 AnythingLLM Desktop App（1.9.0-r2）中，将工作区 Vector Database 下的 Search Preference 从默认改为 “Accuracy Optimized”，使用 LanceDB、内置 all-MiniLM-L6-v2 embedder 与 LocalAI LLM，并在 Query Mode 下操作。首次提问可正常返回，第二次提问时前端提示流式响应网络错误，随后整个桌面应用无响应（加载指示持续旋转）。

报错原文

Could not respond to message. An error occurred while streaming response. network error

[NativeEmbeddingReranker] Initialized
[NativeEmbeddingReranker] Loading reranker suite...
[NativeEmbeddingReranker] Loaded model Xenova/ms-marco-MiniLM-L-6-v2
[NativeEmbeddingReranker] Loaded tokenizer Xenova/ms-marco-MiniLM-L-6-v2
[NativeEmbeddingReranker] Reranking 50 documents...
[NativeEmbeddingReranker] Reranking 50 documents to top 4 took 1300ms

[NativeEmbeddingReranker] Initialized
[NativeEmbeddingReranker] Reranker suite already fully initialized - reusing.

原因分析

切换到 “Accuracy Optimized” 会启用 NativeEmbeddingReranker 进行重排序。根据用户提供的日志，首次请求完成了模型加载与 50 篇文档重排（top 4），耗时约 1300ms；第二次请求时日志显示“reranker suite already fully initialized – reusing”，随后没有任何后续日志，表现为挂起或崩溃。可能原因包括：重排序在复用已初始化模块时发生内存压力（例如本机同时运行 LocalAI 时内存被挤占），导致进程挂起或崩溃，进而前端收到网络错误。该工作区向量数为 4265。以上为基于日志的推测，Issue 未确认最终根因。

环境排查

确认 AnythingLLM Desktop 版本（报告为 1.9.0-r2）。
确认工作区向量数据库类型与 Search Preference 是否确为 “Accuracy Optimized”。
查看工作区设置中的向量数量（报告为 4265）。
确认 Embedder 模型（all-MiniLM-L6-v2）与 Chunk/Overlap 配置（250/20）。
确认 LLM 后端（LocalAI）是否与 AnythingLLM 运行在同一台机器，并检查内存占用。
确认运行模式为 Query Mode 还是 Chat Mode（报告为 Query Mode）。
获取 backend 与 collector 日志目录中的日志文件用于分析。

解决步骤

将工作区 Vector Database 的 Search Preference 改回默认设置，验证问题是否消失（Issue 中用户确认默认设置下工作正常）。
若需继续使用 “Accuracy Optimized”，先从 AnythingLLM 数据目录的 logs 文件夹提取 backend 与 collector 日志，重点查找第二次请求中 reranker 复用初始化之后的日志是否有异常、中断或崩溃信息。
检查机器内存与资源占用，确认 LocalAI 与 AnythingLLM 同时运行时的内存余量，判断是否存在内存压力导致重排序进程被挤出或挂起。
如本地无法定位，将日志、向量数量、机器规格和复现步骤提交到原始 Issue，供维护者进一步排查（该 Issue 因缺少后端日志曾无法复现）。

验证方法

改回默认 Search Preference 后，连续发送两次及以上提问，确认不再出现 “network error”、应用保持响应；若继续使用 “Accuracy Optimized”，需观察 backend 日志中第二次请求的 reranker 阶段是否完整输出重排耗时与结果日志，且前端无中断与无响应现象。