AnythingLLM RAG 知识库管理

它在解决什么问题

AnythingLLM Desktop 的 RAG 链路用起来有不少具体的坑：往工作区里逐个拖文件太慢且容易出错；内置 LLM 推理能力一般，碰到复杂问题就力不从心；升级或更换 embedding 模型后，知识库直接报 LanceError / Arrow dimension 错误；重启后 API 返回 403；改了 chunk_size 却毫无效果。这个技能就是围绕这些日常问题组织的。

核心能力与关键步骤

技能覆盖 AnythingLLM Desktop RAG 的完整生命周期，提供三个脚本化的构建块：

• scripts/bulk_import.py — 并发上传 + 触发 embedding
• scripts/lancedb_search.py — 绕过 LLM 直接查询 LanceDB 向量
• references/ — 部署、调参与排障的详细文档

底层架构很清晰：SQLite（anythingllm.db）存放工作区元数据和系统设置；LanceDB 每个工作区对应一张 .lance 表，表名就是 workspace slug；embedding 模型走 Ollama 或云 API，同一工作区内输出维度必须保持不变。

三条工作流按需取用：

1. 准备工作区 — 创建 workspace，把 chatMode 设为 chat 走快速 RAG（设成 automatic 会触发慢速 agent 模式），并核对 embedding 维度。
2. 批量导入 — 上传和触发 embedding 两步缺一不可。本地建议 10–15 并发、batch 20–50、延迟 2–3s（>1MB 文件用 5s）。导入后用 API 统计文档数、检查 backend-*.log 中的 LanceError，再用 lancedb_search.py 抽样验证。
3. 直查向量 + Agent 推理 — 内置 LLM 成为瓶颈时，用 Ollama 对查询做 embedding，直接搜 .lance 表，把片段交给 Agent 平台做推理；复杂问题跑 2–3 个角度的查询再合并结果。

适用边界与注意点

几个容易踩的坑，排障时务必对照 references/ 里的条目：

• 维度不匹配：更换 embedding 模型后旧向量全部作废，需要备份、通过 /system/update-env 设置 EmbeddingOutputDimensions、重启、删除旧 .lance 表后重新导入。
• 403：通常是重启后 API key 变了，去 Settings 里取新的。
• chunk_size 不生效：要直接改 SQLite 的 system_settings，而不是走 env API。
• 找不到表：多半是 slug 记错了，用 SQLite 查询确认正确的表名。

检索打分规则为 score = 1 - distance/2，一般把 >0.7 视为高相关；且搜索用的 embedding 模型必须与入库时一致，否则召回结果没有意义。