MariaDB Vector 和 RAG 在 foss-north 2025 大会上

我很高兴能被接受参加并演讲“利用自己的数据通过 RAG 使 AI 透明化”，地点是瑞典哥德堡举行的 foss-north 2025 大会。4月14日在查尔姆斯理工大学，我向满座的听众分享了如何使用 MariaDB Vector 进行 AI RAG，开场介绍了一个利用 GenAI 规模化编辑 Wikipedia 的用例。

使用 RAG 改进 Wikipedia

我分享了一个用例，来自于我为非营利组织 Projekt Fredrika 使用 GenAI 规模化编辑 Wikipedia 的经验。规模化编辑 Wikipedia 的一个瓶颈是找到所有可以用某个来源改进的相关 Wikipedia 页面。RAG 既可以帮助将来源与合适的 Wikipedia 文章匹配，也可以生成包含来源引用的 AI 改进内容——这对于 Wikipedia 的任何新增内容都是一个关键要求。总而言之，这对 RAG 来说是一个合适的挑战。

使用 MariaDB Vector 进行 RAG

接下来，我讲解了使用 MariaDB Vector 进行 RAG 的技术细节。我解释了将向量与数据存储在同一数据库中，而不是使用专门的向量数据库的好处。

我将简要回顾一下步骤——更多详情请参阅在您的 MariaDB 数据上尝试使用 MariaDB Vector 进行 RAG！。

在准备阶段，将源文本切分成合适的文本片段，即“块”（chunks）。这些块通过一个嵌入模型转换成向量，并插入到 MariaDB Vector 中。
在运行时，第一步是将用户文本提示词向量化，并进行向量搜索以找到与回答问题最相关的块信息。第二步是在一个提示词中结合问题和上下文块，并将其交给一个大型语言模型（Large Language Model）来生成问题的实际答案——只使用已获取的相关块。

听众提问

我很好奇我的听众。举手示意表明，他们普遍技术娴熟，但对 AI 技术不太熟悉。在数据库方面，他们熟悉 MySQL、Postgres，对 MariaDB 稍逊，而对专门的向量存储则几乎完全不熟悉。只有少数人之前尝试过 RAG，或更复杂的 LLM 提示词——对于前来学习这个主题的人来说，这也许是意料之中的。

听众提出了两个问题，我想在这篇博客中重新阐述一下：

块化（chunkification）的最佳策略是什么？这取决于材料。如果您在许多短文档中进行搜索，对文档的标题或引言进行向量化可能就足以找到您需要的文档。在其他情况下，您可能希望将文档分解成更小的块，以便在其中找到合适的章节、页面、段落甚至句子。您需要尝试几种方法，看看哪种最适合您的用例。
MariaDB 使用最近邻搜索——那其他方法（如 BM25）呢？ BM25 是一种用于搜索引擎的页面排名方法，目前不在 MariaDB 的路线图中。MariaDB 使得将向量搜索与基本 SQL 过滤相结合成为可能，这对于 RAG 解决方案非常有利。其他搜索选项可能包括例如结合向量和关键词搜索的混合搜索。

关于 foss-north 大会

MariaDB 关于 Vector 和 RAG 的演讲之前是 Red Hat 关于 AI 微调的研讨会，并与该研讨会相辅相成——这是根据您的需求调整生成式 AI 的另一种方法。

foss-north 大会由 cURL 的创建者、来自瑞典的 Daniel Stenberg 开场，他谈论了开源的总体情况。他提出了诸如开源的流行度、项目的维护、开源贡献者平均年龄的上升、在动荡世界中对项目独立性的担忧以及在开源开发中使用 AI 等问题——由于潜在的负面影响，他对此并不热衷，不过作为一个乐观主义者，我认为它的好处将大于缺点。