[BUG]: division by zero panic in lance-encoding during RAG queries

快速结论：该报错出现在 AnythingLLM 对工作区文档执行非 Agent 的 RAG 检索时，后端因依赖的 lance-encoding 0.22.0 做向量归一化未检查零长度向量而触发 divide by zero panic。排查方向是确认触发路径是否落到非 Agent RAG 检索，以及能否升级到包含修复的 lance-encoding 版本。

适用环境：Issue 确认的环境包括：Docker（远程机器）部署的 AnythingLLM；AnythingLLM Desktop v1.19.0、Windows 10 Pro 22H2（19045.6456）、捆绑 Node v20.18.0（作为第二条数据点）；Embedder 分别为 Local（LanceDB / lance-encoding 0.22.0）与 native（Xenova/all-MiniLM-L6-v2）；Vector DB 为 LanceDB（默认）；LLM 为 DeepSeek deepseek-flash / deepseek-reasoner（第二条数据点）。

最快修复方案：暂无确认的一步修复方案。Issue 中确认的修复来自 LanceDB 侧，lance-encoding 在 0.23.0 版本实现修复；AnythingLLM 当前构建捆绑 0.22.0，需等待项目方升级依赖的补丁发布。

注意事项：Issue 未给出可在用户侧直接执行的临时绕过方案；第二条数据点症状不同（后端进程静默退出、无 JS 堆栈与 Node 崩溃报告），是否与同一 panic 同源尚未确认，只能作为“可能原因”参考。Issue 关闭时间不代表修复已进入你所使用的发行版，升级前需确认对应版本捆绑的 lance-encoding 版本。

问题场景

用户向工作区添加文档后，用提示词触发 RAG 检索（非 Agent 的 chat / query 模式）时，anythingllm 容器后端崩溃。docker 部署场景下日志明确显示 tokio 运行线程在 lance-encoding 0.22.0 中 panic；Desktop 场景下则表现为发送任意消息后 HTTP 200 开始流式输出，随后 3001 端口停止监听、UI 报网络错误，最后一条日志固定为 [NativeEmbedder] Embedded Chunk Group 1 of 1。

报错原文

[192.168.1.106] thread 'tokio-runtime-worker' panicked at /home/build_user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lance-encoding-0.22.0/src/data.rs:425:9:
[192.168.1.106] attempt to divide by zero
[192.168.1.106] thread 'tokio-runtime-worker' panicked at /home/build_user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lance-encoding-0.22.0/src/decoder.rs:1489:65:
[192.168.1.106] called `Result::unwrap()` on an `Err` value: JoinError::Panic(Id(158), "attempt to divide by zero", ...)

原因分析

最可能的原因：lance-encoding 0.22.0 的归一化逻辑在执行除法前未检查零长度向量，当查询向量为空或格式不规范时发生除零 panic，进而导致后端请求失败。该缺陷已记录在 LanceDB 上游 Issue #3026，修复 PR 为 #3613，并在 lance-encoding 0.23.0 中实现。AnythingLLM 当前构建捆绑 0.22.0，因此仍会触发。

Desktop 数据点的静默退出表现为原生中止，无 JS 堆栈、无 stderr、无 Node 崩溃报告，且同文档在 Agent 模式下、直接查询 LanceDB 表时均未复现，因此“可能原因”是发生在查询向量生成之后的非 Agent RAG 路径；能否与同一 panic 对应，Issue 中未最终确认。

环境排查

确认 AnythingLLM 的部署形态（Docker 远程 / Desktop）及具体版本，Desktop 数据点为 v1.19.0。
确认捆绑的 lance-encoding 版本是否为 0.22.0；0.23.0 才包含修复。
确认 Vector DB 是否为 LanceDB（默认），以及 Embedder 类型（Local / native Xenova/all-MiniLM-L6-v2）。
Windows 场景确认系统版本（数据点为 Windows 10 Pro 22H2 19045.6456）及捆绑 Node 版本（v20.18.0）。
确认触发模式：非 Agent 的 chat / query 模式是否报错，Agent 模式是否正常，用于缩小路径范围。
确认容器日志中是否出现 lance-encoding-0.22.0 路径与 attempt to divide by zero 字样。

解决步骤

先定位触发路径：记录发生崩溃时的对话模式（chat / query / Agent）、是否含文档，并对照容器日志确认是否存在 lance-encoding-0.22.0 的 panic 栈。这是 Issue 中用于区分两类症状的依据。
确认当前 AnythingLLM 版本所捆绑的 lance-encoding 版本；若仍为 0.22.0，则该构建依旧存在此崩溃条件，需要等待或升级包含 lance-encoding 0.23.0 修复的 AnythingLLM 版本。
可优先尝试：在排障期间将同一批文档改用 Agent 模式（@agent）对话，Issue 数据点显示该路径未导致后端崩溃；这属于规避而非修复，仅供参考。
可优先尝试：暂时减少或调整问题文档，观察是否仅与特定文档组合相关；Issue 中重置向量库并全量重新嵌入 23 篇文档未能解决问题，说明重建索引不是有效修复。
Issue 维护者已确认会打补丁，但未公布具体版本号与发布时间；升级前请核对发行说明或镜像中的依赖版本，确认已包含 lance-encoding 0.23.0 或更高版本后再验证。

验证方法

在包含修复的版本上，重新加载包含原问题文档的工作区，用此前触发崩溃的提示词执行非 Agent RAG 检索：请求应正常返回并给出流式回答，容器日志不再出现 lance-encoding 的 attempt to divide by zero panic；Desktop 场景下 3001 端口应保持监听，不再出现流式响应中途 network error。