探索 AnythingLLM:借助开源 AI 打造私有化智能知识库
探索如何使用开源项目 AnythingLLM 构建私有化智能知识库。通过 RAG 技术,将文档转化为可检索向量,结合大语言模型实现高效问答,适用于企业与个人开发者。
阅读原文请转到:https://jimmysong.io/blog/building-private-ai-knowledge-base-anythingllm/
随着大语言模型(LLM)的快速发展,将企业内部知识库与 AI 工具结合成为热门解决方案。作为一名技术探索者,我对构建私有知识库充满兴趣,也希望测试 LLM 的能力,尤其是像 Ollama 和千问这类模型。此外,AnythingLLM 是一个开源项目,具有较高的社区关注度,因此我决定对其进行深入调研。
基于 RAG(检索增强生成)技术,AnythingLLM[1] 提供了从数据处理到用户界面的全栈解决方案,支持构建企业内部的智能知识库。其模块化架构和灵活部署方式,使其成为企业和个人开发者进行知识管理和 AI 项目实践的重要工具。
RAG 原理概述
简介
RAG(Retrieval-Augmented Generation) 是一种结合了信息检索和语言模型的技术。它通过从大规模的知识库中检索相关信息,并利用这些信息来指导语言模型生成更准确和深入的答案。这种方法由 Meta AI 研究人员在 2020 年提出,旨在解决大型语言模型在信息滞后、模型幻觉、私有数据匮乏和内容不可追溯等问题。
RAG 就是可以开卷回复的 LLM。其发展历程:Naive RAG 包含索引、检索、生成三步,存在 召回率低、Prompt 拼接问题。Advanced RAG 优化索引与检索,引入 预检索、后检索策略与数据清洗 提升效率。Modular RAG 实现 模块化流水线与端到端训练,具备更高的 灵活性与适应性。
背景与挑战
尽管 LLM 在处理复杂任务方面表现出色,但在以下三个方面存在局限:
• 知识局限性:大模型的训练数据来自公开数据源,无法访问非公开和实时数据。
• 幻觉问题:模型有时会生成错误答案,特别是在缺少特定领域知识时。
• 数据安全性:涉及内部私有数据时,企业面临数据泄露风险。
RAG 技术通过向量检索与生成模型结合,显著提高了数据处理的深度和准确性。
工作原理
RAG 的工作流程包括两个主要阶段:
1. 数据准备阶段
• 将内部私有数据向量化存入数据库,构建检索索引。
2. 用户应用阶段
• 根据用户的 Prompt 检索相关内容,将结果与原 Prompt 组合,生成模型回答。
通过这种方式,RAG 可以搭建团队内部的本地知识库,弥补大模型的知识局限性,解决幻觉和数据隐私问题。然而,RAG 也存在一些主要限制:
• 数据依赖性强:RAG 系统的效果严重依赖于内置知识库的数据质量和覆盖范围。
• 检索准确性受限:检索算法可能因索引构建不完善或查询表达模糊导致相关性降低。
• 模型推理成本高:大型语言模型的推理消耗大量资源,尤其在频繁查询和大规模应用场景中。
• 技术复杂度高:构建和维护 RAG 系统需要强大的数据管理与模型集成能力,涉及嵌入、索引构建和检索优化等多个复杂组件。
• 响应延迟与性能瓶颈:在高负载下,检索与推理过程可能导致响应速度变慢,尤其在硬件性能受限的环境中。
AnythingLLM 简介
AnythingLLM 是 Mintplex Labs Inc. 开发的一款开源 ChatGPT 等效工具,用于在安全的环境中与文档进行交互。它融合了从数据处理到用户界面的所有技术,适用于构建个人或企业私有化的知识库。
核心特点
• 多用户支持和权限管理:支持多个用户和不同权限设置。
• 支持多种文档类型:PDF、TXT、DOCX、JSON 等。
• 内置数据连接器:GitHub、GitLab、YouTube、链接抓取、Confluence 等。
• 多种向量数据库支持:如 LanceDB(默认)、Pinecone、Weaviate 等。
• 灵活的 LLM 集成:支持 OpenAI、Azure OpenAI、Ollama、LM Studio、LocalAI 等。
• 成本节约措施:大文档只需嵌入一次,显著降低成本。
• 开发者 API 支持:便于自定义和扩展。
技术架构
• 收集器(Collector):将本地或在线资源转化为 LLM 可用格式。
• 前端(Frontend):基于 ViteJS 和 React 构建的用户界面。
• 服务器(Server):基于 NodeJS 和 Express 的后端,管理数据库和 LLM 交互。
构建自己的知识库:详细步骤
要在 AnythingLLM 中构建一个私有知识库,可以按照以下步骤操作:
1. 上传文档:将 PDF、TXT、DOCX、JSON 等支持的文档格式上传到系统中。
2. 嵌入向量生成(Embedding):
• 使用配置的嵌入模型(如 OpenAI、Azure OpenAI、LocalAI)将文档转化为向量数据。
• 确保配置正确的嵌入模型以匹配项目需求。
3. 存储到向量数据库:
• 选择适合的向量数据库,如 LanceDB(默认)、Pinecone、Weaviate。
• 配置数据库连接,保证数据安全和高效检索。
4. 查询与回答:
• 用户输入查询,系统将其转化为查询向量。
• 向量数据库检索最匹配的内容,调用大语言模型(如 OpenAI GPT)生成答案。
• 返回最终答案,链接相关文档和参考。
在 Docker 中安装 AnythingLLM
参考:Docker 安装指南[2]
export STORAGE_LOCATION=$HOME/anythingllm && \
mkdir -p $STORAGE_LOCATION && \
touch "$STORAGE_LOCATION/.env" && \
docker run -d \
--cap-add SYS_ADMIN \
--network host \
--add-host=host.docker.internal:host-gateway \
-v ${STORAGE_LOCATION}:/app/server/storage \
-v ${STORAGE_LOCATION}/.env:/app/server/.env \
-e STORAGE_DIR="/app/server/storage" \
mintplexlabs/anythingllm
注意:使用 host network,否则容器中无法与 Ollama 通信。
若要在本机运行 Ollama,可以使用下面的命令:
ollama run qwen2.5:14b --keepalive 0
这将会运行 qwen2.5:14b,你也可以选择其他大模型。
打开浏览器:http://localhost:3001
注意:必须选择要接入的 LLM,可以使用
local
或cloud
Desktop 部署
AnythingLLM 内置的 LLM 引擎支持下载流行的模型如 LLama-3、Phi-3 等,支持 CPU 和 GPU。本地运行适用于试用其基本功能。
参考:Desktop 安装概览[3]
局限性:缺少多用户支持、浏览器插件、用户和 Workspace 管理等功能。
使用体验与问题记录
如果你的电脑性能堪忧的话,强烈不建议你在本地运行大模型。你会遇到各种性能问题,例如下面看到的,在上传文件嵌入到 Workspace 时卡住了。
性能与硬件限制
• 构建向量数据库特别慢:支持的文档格式很多,但在我的 MacBook Pro 2015(16G 内存,无 M 系列芯片)上,构建向量数据库的过程非常耗时。这是因为文档需要被嵌入模型处理成高维向量,并存储到数据库中。该过程涉及复杂的计算和大量内存操作,导致处理一个 7M 的 JSON 数据需要 3 分钟,而嵌入(Embed)到 Workspace 则需十几分钟,且时常失败。
• 高性能需求:由于硬件性能受限,运行本地 LLM 十分吃力。运行 Ollama 尚可,但进行 RAG 操作时性能明显不足。
查询与响应延迟
• 响应慢:在聊天模式下,系统反馈非常慢,通常需要等待几分钟才能得到回复。
常见错误提示与解决方案
• 查询执行失败:遇到错误提示
Failed to execute query stream: Invalid input, No vector column found to match with the query vector dimension: 4096
。• 解决方案:查看官方问题跟踪 [BUG]: Could not respond to message. LanceDBError: No vector column found to create index #1131[4]。
如何改善用户体验
1. 使用商用大模型 API:
• 如果硬件资源有限,可以考虑使用 OpenAI、Azure OpenAI 等商用大模型 API。这些服务在稳定性和性能方面具有优势,尤其适用于大规模文档处理和实时查询。
2. 优化硬件环境:
• 使用带有 GPU 加速的现代硬件,推荐内存不低于 32GB,显卡支持 CUDA 的 GPU(如 NVIDIA RTX 系列)来显著提升向量嵌入和模型推理速度。
3. 调整 AnythingLLM 配置:
• Chat Setting(聊天设置):配置聊天相关参数,包括模型选择、响应超时、查询历史记录存储策略等。
• Agent 设置:根据项目需求启用不同类型的代理,如检索代理、对话代理和任务代理。
• 资源分配与性能优化:在 Docker 或 Kubernetes 部署环境中,设置 CPU、内存和 GPU 加速参数。调整嵌入批处理大小(Batch Size)、线程池大小等性能参数,优化推理与检索性能。
4. 分布式部署与扩展:
• Kubernetes 集群部署:
• 使用 Kubernetes 编排多个 AnythingLLM 实例,确保高可用性和自动扩展能力。
• 部署配置包括 ReplicaSet、Pod 自动缩放(HPA)、负载均衡(Service)、存储卷(PersistentVolumeClaim)等。
• 云服务部署:
• 在云平台上运行托管服务,使用容器服务管理。
• 配置高性能数据库(如 RDS、Firestore),并启用 CDN 加速文件传输。
• 数据库和缓存扩展:
• 使用分布式数据库(如 Redis、Pinecone、Weaviate)提高查询速度。
• 启用数据库主从复制与自动备份,确保数据持久性和高可用性。
5. 升级数据库存储方案:
• 替换默认数据库 LanceDB,考虑使用更高性能的向量数据库如 Pinecone、Weaviate 等,以减少查询延迟。
6. 代码优化与插件扩展:
• 定制插件来适配特定任务,并启用数据缓存机制以减少频繁查询对资源的消耗。
总结与展望
AnythingLLM 是一个功能全面的 RAG 解决方案,适用于企业内部知识库构建。通过结合向量检索与大语言模型,该平台提供了强大的文档问答能力。然而,部署和定制化需要一定的技术投入。未来的改进方向包括增强多数据库支持、更灵活的嵌入模型选择以及提升文档解析能力。
引用链接
[1]
AnythingLLM: https://anythingllm.com/[2]
Docker 安装指南: https://github.com/Mintplex-Labs/anything-llm/blob/master/docker/HOW_TO_USE_DOCKER.md[3]
Desktop 安装概览: https://docs.anythingllm.com/installation-desktop/overview[4]
[BUG]: Could not respond to message. LanceDBError: No vector column found to create index #1131: https://github.com/Mintplex-Labs/anything-llm/issues/1131