AI企业知识库

背景

我们有时希望，让AI能在特定的知识领域上回答问题，避免AI天马行空。

可能的方案

据了解，有下列三种方案。

一、训练模型：
用特定的数据，对模型进行训练，相当于让模型学习所有数据。

二、指定文档：
把问题相关的文档整份传给LLM，让LLM理解所有文档内容，并且回答问题。

三、RAG+LLM：
把问题相关的文档先通过嵌入模型拆解成文本块并转化成向量，存入向量库。
然后再把用户的问题通过嵌入模型解析成向量，到向量库检索相关度高的文本块，例如检索出5个文本块，然后把这5个文本块传递给LLM，让LLM理解这些文本块范围内的信息，然后再回答。

方案对比：

方案一 效果应是最好的，因为它是真的学习起来了，相当于刻进记忆里了。
但是硬件要求高，需要的专业度也高。

方案二 效果也不错，只要相关的文档给的对，他就能回答得比较靠谱。
但是需要给对的文档，其实结合rag找到相关文档，把相关文档完整丢进去是比较好的。

方案三 效果一般，但是现有知识库产品基本上都是这种模式。
缺点是给定资料的范围更小了，更加依赖检索的准确性。

RAG+LLM

由于这种模式产品比较多，且成熟，上手入门比较快，所以主要看这个方案。

原理

先引入阿里云的一个图：

从上图

其实企业知识库主要理解成两个部分：

知识入库、相关问答

一、知识入库

通过把【知识源 】传递给【嵌入模型】，把知识分解成多个文本块，并且每个块向量化，再存入【向量数据库】

二、问答

通过把【问题】传递给【嵌入模型】，把问题向量化，然后去【向量数据库】检索，找到匹配度较高的文本块，然后作为【相关信息上下文】提交给【LLM】，LLM理解完上下文后，对问题进行回答。

部署

部署方案又有挺多种的，其中部署相关的几大块分为：

知识库产品、LLM、嵌入模型(embedding)、向量数据库

知识库产品

知识库产品就是提供个交互界面，进行知识文档上传、管理、发起对话，它就是用来协调LLM、嵌入模型、向量数据库共同协作，完成整个知识库应用层面的事情。

知识库产品可以分为：

客户端程序、web网页

安装客户端程序的有 cherrystudio、chatbox、lm studio 等。

通过web页面访问的有 open-webui、anythingLLm、dify 等。

大模型

LLM 和 嵌入模型其实都是大模型，只是大家方向不一样而已。

一般知识库产品在配置这些大模型的时候，常见的有两种，
一种是通过AI服务平台，一种是通过 OLLAMA。
通过AI 服务平台的时候，一般都是配置下平台的基地址、APIKey、模型名。
通过OLLAMA的时候，一般都是配置 ollama 的运行地址、模型名。

关于选型：
LLM方面，例如deepseek-r1，建议直接用 AI 服务平台的，用最好的模型，有更好的体验。当然有能力可以自行通过 ollama 部署，32B及以上的蒸馏模型效果会靠谱一点。
嵌入模型方面，这个比较讲究。因为我们大部分是中文知识，所以这个模型一定是要针对中文效果好的才行。截止2025-02-08了解，个人比较有意的模型包括：

阿里云：dashscope text-embedding-v3（阿里云百炼模型）
摩卡 m3e-base
北京智源 bge-large-zh-v1.5 腾讯云推荐

huggingface嵌入模型中文处理排名。
1小布 xiaobu-embedding-v2
2腾讯 conan-embedding-v1
3通义千问 gte-Qwen2-7B-instruct
7北京智源 BGE-Multilingual-Gemma2
13 阿里达摩院 gte-large-zh

这些模型都还可以。

注意：huggingface上的模型大部分都不能直接拿到 ollama 上用，所以要做给小转换（另外介绍），然后才能在 ollama 上运行。

向量数据库

关于选型，向量数据库个人感觉不是重点，所以也没有仔细去了解。
一般知识库都会指定一种，并内置好的，可以不太理会。