[Bug]: Embeddings silently not written to lancedb, RAG returns no sources (Desktop 1.16.0, Windows)

快速结论：此报错通常出现在 AnythingLLM Desktop 从旧版本（如 1.7.0）升级到 1.16.0 后，文档解析成功但向量嵌入静默失败，导致 LanceDB 存储为空、RAG 检索不到任何来源。优先检查工作区中的“文档相似度阈值”设置，并尝试开启重排序（Reranking）功能。

适用环境：Windows 11 x64、AnythingLLM Desktop 1.16.0（从 1.7.0 升级）、VECTOR_DB=lancedb、EMBEDDING_ENGINE=native（Xenova/all-MiniLM-L6-v2）。

最快修复方案：暂无确认的一步修复方案。Issue 中维护者给出的首选排查建议是：进入目标工作区的向量数据库设置，将“文档相似度阈值”调整为“无限制”，保存后重新提问测试是否出现引用来源。

注意事项：该方案仅被建议用于排查是否为阈值设置导致 RAG 管道无法找到相关分块，并未在该 Issue 中被用户明确验证为根治方案。同时开启文档重排序（Reranking）也被认为对检索效果有很大帮助，但同样需要实际测试确认。如果调整后仍无引用，则需按官方文档抓取嵌入阶段的日志才能进一步定位。

问题场景

用户在 Windows 11 上将 AnythingLLM Desktop 从 1.7.0 升级到 1.16.0（全新安装），并在工作区中添加 PDF 和 Markdown 文档。文档解析阶段正常，但在嵌入式嵌入阶段，系统静默失败：应用界面报告成功，也触发了 telemetry 的“documents_embedded_in_workspace”事件，但 LanceDB 目录始终为 0 字节，数据库表为空，最终聊天时 RAG 检索不到任何来源。

报错原文

[Bug]: Embeddings silently not written to lancedb, RAG returns no sources (Desktop 1.16.0, Windows)

原因分析

可能原因：这并非典型的嵌入报错（无异常抛出、子进程退出码为 0），而是升级后 LanceDB 写入静默失败。用户环境的 storage 目录是 2024 年 12 月创建的旧数据，升级到 1.16.0 后可能因为数据库目录/元数据结构不兼容或权限问题，导致写入操作被静默吞掉。

另外，维护者指出也可能与“文档相似度阈值”有关——如果阈值设置过高，RAG 管道即使读到向量也无法将查询与文档分块匹配，表现为“检索不到来源”，但这属于检索端而非嵌入端的配置问题，需要区分。

环境排查

确认 AnythingLLM Desktop 安装目录是否覆盖旧版本（示例路径：D:\Users\samfa\AppData\Local\Programs\AnythingLLM）。
检查 storage/lancedb 目录是否存在 .lance 文件，且目录大小是否为 0 字节。
检查数据库中的 document_vectors 和 workspace_documents 表是否为空。
确认嵌入引擎是否为 native（Xenova/all-MiniLM-L6-v2），以及初始化是否成功、是否在 addDocuments 期间抛出异常。
检查工作区的“文档相似度阈值”当前设置值。

解决步骤

打开目标工作区（发生嵌入失败的工作区），进入向量数据库设置页面。
将“Document similarity threshold”（文档相似度阈值）调整为“No restriction”（无限制），保存设置。
向该工作区发起一个新的提问，观察聊天回复中是否出现来源引用（Citations）。
如果仍无任何引用，按官方文档开启 AnythingLLM Debug Mode（Windows），复现一次文档上传和嵌入操作，收集该阶段的后端日志以定位静默失败的真正原因。
可优先尝试在向量数据库设置中开启“重排序”（Reranking），增强检索匹配效果，然后再次测试提问。

验证方法

调整阈值或开启重排序后，向该工作区提问并确认聊天回复是否附带文档来源引用。同时可以重新检查 storage/lancedb 目录是否存在新生成的非空 .lance 文件，以及 document_vectors 表是否开始记录向量数据。若日志中能看到嵌入阶段正在写入且无异常，则说明问题已解决。