RAG 还是 Lucene：私有化部署客服系统的 AI 知识库架构选型

大家好，我是升讯威在线客服与营销系统的作者。几年来我一直致力于开发这款安全、稳定、可靠，并且轻量级可私有化部署的客服系统，在这几年前，陆续收获了许多用户。对一个程序员来说，能够看到自己的产品被用户在生产环境投入商用，既让我欣慰，也是我动力的来源。

时间来到2026年，今年对我来说也许会是转折的一年，因为经过了前几年的努力与试错，特别是去年接近一年的突击（可以看我网站上的更新日志，去年的更新量超过了前几年的总和），我现在有足够的信心说这款产品达到了高可用，企业级的水平。在这个过程中我要特别感谢一些用户的信任与支持（精神上与物质上的双重支持，谢谢你们）。

在2026年，我给自己立了一个新的目标，通过一系列文章来介绍和回顾我开发这款客服系统的过程。一方面是让自己从疲惫的编程工作中走出来，回到社区，重新练习自己的写作和沟通技能，另一方面我希望通过分享与沟通，能够找到志同道合的朋友。

在这一系列的文章中，我不会使用 AI 来协助写作，也不会长编大论介绍一些基础知识。我会把精力放在自己遇到的问题和面对这些问题时的思考上，说明自己在面对这些问题时如何权衡与取舍，如何达成自己的关键目标（开发一款安全、稳定、可靠、轻量级、可私有化部署的客服系统）。所以这些文章可能篇幅不会很长，甚至文笔不会太好，请您见谅。

如果您对我的这款产品感兴趣，可以看一看我的网站：https://kf.shengxunwei.com。

---

在本篇中，我将介绍为客服系统开发 AI 智能客服时，对于"知识库"这一核心功能的架构选型和思考过程，以及如何实现它。

引言

在 AI 浪潮的席卷下，没有一款客服软件能够忽视它，为客服系统增加 AI 客服功能已经不是一个可选项，而是必须要做的事情。让客服系统具备 AI 客服的能力，通常有以下几种方式：

1. 完全使用 AI 平台的云服务。把用户的知识库上传到 AI 平台，当访客在聊天窗口提出问题时，调用 AI 平台的接口实现智能客服功能。

2. 搭建 私有化 AI 平台，如 Dify，然后通过接口调用的方式，让客服系统与之互通。

Dify是一个开源的大语言模型（LLM）应用开发平台，旨在简化和加速生成式AI应用的创建和部署，为开发者提供了一个用户友好的界面和一系列强大的工具，使他们能够快速搭建生产级的AI应用。

3. 完全内置 AI 能力，需要自行实现知识库的向量化与检索（RAG），并内置对开源模型的直接调用能力。

对于第 1 个选择，完全使用 AI 平台云服务的方案，最轻量级，最容易实现，但是与 100% 私有化部署，数据 100% 可控（保存在本地）冲突。对于数据敏感型团队无法接受，例如政府、金融、保险等用户。

而第 2 个选择，搭建 Dify ，对于大量的小规模团队来说，太重。大量的小规模团队，小型企业没有 IT 专家，要部署上线这样一套复杂的系统，门槛实在太高，并且需要带 GPU 的服务器进行模型推理。

而第 3 个选择，完全内置 AI 能力，除了开发代价较大之外，同样也会极大的增加小规模团队的部署难度。需要额外部署数据库组件支持，同样这也需要带 GPU 的服务器来实现模型推理。这样的门槛还是太高了。

我的现状与目标

回到我自己的目标：开发一款安全、稳定、可靠、轻量级、可私有化部署的客服系统。

这里我特别标出了"轻量级"这一点。因为在这几年的开发中，我接触到大量的小团队，甚至只有几个人，甚至只有一个人的团队。可能只是想在现有的企业网站或者 APP 中加入一个简单的客服功能，让他们能够与潜在的客户进行基本的沟通，更好的把握订单而已。当他们看到复杂的系统说明和术语时，基本就会被直接劝退。他们需要的就是简单、简单、足够简单。

特别是这样的小团队在私有化部署时，很多时候他们无法承担较高的服务器成本和带宽成本，我遇到过一些小团队，直接在现有的网站 WEB 服务器上部署客服系统的，或者在云服务商大促时购买一台特价 2vCPU 4GB 内存上部署的，这些用户是绝大部分。（不过这不代表他们对客服系统的稳定性和安全性有容忍度）。

所以前面提到的第 2 个和第 3 个方案，可以排除了，除非我放弃大量的小规模用户，这是不可能的。

看起来剩下的选择只有第 1 种了：完全使用 AI 平台云服务的方案。

但是 AI 客服功能不仅仅是调用 AI 模型进行聊天，AI 客服的诉求是让 AI 根据用户自己的知识库与访客进行交流，例如："如何下订单？订单几天送达？" 等等。

这中间要有一个"知识库"作为桥梁，如果完全使用 AI 平台云服务，务必要求用户将所有知识库文档上传到公有云服务平台，这对于许多用户来说，也是无法接受的，现今信息安全的理念已经深入人心了，特别是政府、金融、保险等等领域，数据上云也等于直接再见。

所以这里产生了另一个前提条件：知识库必须 100% 位于用户的本地数据库。

一个最可行的折中方案是：当访客使用 AI 客服功能时，先检索本地数据库中的知识库内容，然后构建提示词，调用 AI 平台的能力。这与方案 1 不同的时，我会直接调用 DeepSeek、豆包，甚至 Gemini、GPT 而不是把知识库托管在某个公司的平台上。

管理本地知识库

那么这个方案的核心就是：如何构建和管理本地知识库。

通过向量数据库管理是最好的选择，但我在前文中提到了一个制约条件，私有化部署时必须足够轻量级，不能增加用户部署的负担。

此时我的方案已经初步构思为：本地数据库 + 全文索引 + 召回 Top N + 构建提示词。

全文索引的成熟方案很多：

1. Elasticsearch。行业事实标准，分布式架构，天然支持大规模集群、分片和副本。

2. OpenSearch。AWS 因为不满 Elastic 公司的协议变更，从 Elasticsearch 分支出来的开源版本。

3. Solr。老牌选择，在精准分词、传统文本检索上仍然有优势，但分布式扩展性逊色于 ES。除非是老项目维护，现在新项目极少首选。

4. 其它：Meilisearch（Rust编写）、Typesense（C++编写）...

回想我在公司参与项目工作的时候，基本都是直接上 Elasticsearch 了，那时候参与的项目，有一个大的甲方，有一个几百万的合同，有非常宽松的服务器环境和成熟的运维团队。

但是现在，这些我都没有了。我要服务的小规模团队，完全无法在私有化部署时搞一个 Elasticsearch 这样的重火力武器。

那怎么解决这个困境呢？再次回到我的现状，我的大部分用户都是小团队，对于 AI 知识库的管理来说，有一个显著的特点，就是知识库的规模同样比较小，如果你和他们说你的方案能在毫秒之间检索数万篇，几十GB的知识库文档，他们会觉得和你根本不是一路人。

小规模团队的知识库文档数量通常仅仅只有数十篇，数百篇的已经很少了。总结一下目前的条件和需求：

1. 数据必须 100% 本地化，使用 本地数据库 + 全文索引 + 召回 Top N + 构建提示词 方案，将提示词发送到 AI 模型，如 DeepSeek、豆包，甚至 Gemini、GPT。

2. 必须轻量级，不能增加任何私有化部署负担。能够实现数百篇知识库文档的检索已完全足够。

最终只剩下一个成熟选择：Lucene。

它无需安装部署任何独立服务，零依赖，可以直接集成到服务端主程序中，用户在私有化部署时无任何感知。

实际上，Lucene 并不弱，对于 100 万至 1000 万篇文档，在这个范围内，查询延迟通常在 10-50ms。 用来服务小规模用户的数十篇数百篇文档，其实非常非常非常轻松。

结尾

关于 Lucene 怎么使用，这样的优秀文章太多太多了，我并不打算在此献丑了。

正如我在开篇中所说的，我会在这一系列文章中，把精力放在自己遇到的问题和面对这些问题时的思考上，说明自己在面对这些问题时如何权衡与取舍，如何达成自己的关键目标（开发一款安全、稳定、可靠、轻量级、可私有化部署的客服系统）。

我希望这一系列文章更像是记录一个独立开发者的心路历程。谢谢您的关注和支持 😃