用Python/ChromaDB/Gemini搭建轻量级RAG实战

dev.to · AI#RAG#向量数据库#Python

Editor brief · 编辑速览

以数据结构PDF为测试文档，详解RAG pipeline各阶段原理：语义分块、embedding、向量化检索、生成。强调理解为何这样做而非仅会拼接。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

大语言模型的表现令人印象深刻，但它们有一个盲点：只能根据训练时学到的内容来回答问题。

如果向它提问关于某个特定 PDF、公司内部手册或专业教科书的问题，它可能会猜测、泛化，或者直接承认不知道。

检索增强生成（RAG）通过赋予 LLM 在回答前先查阅资料的能力来弥补这一缺陷——把闭卷考试变成开卷考试。

在 Valentius Kryptix 实习期间，我构建了一个轻量级 RAG 系统来验证这个想法，以一份《数据结构与算法》PDF 作为测试文档。

我不想把 RAG 当作一个黑盒子来使用，而是希望理解流程中每个阶段存在的原因——不仅仅是把它们连接起来。

🔍 核心洞察：检索只有在"相关性"被语义化定义而非字面定义时才能生效。

对"队列操作"进行关键词搜索可能会失败，因为文档可能用"入队和出队函数"来表述同样的概念。

这就是嵌入（embeddings）的用武之地。系统使用 Sentence Transformers 库的 all-MiniLM-L6-v2 模型，将文档和用户的问题都转换成向量，这些向量捕捉的是含义而非措辞本身。

将这些向量存储在 ChromaDB 中，使得即使词语不完全匹配，也能找到概念上相关的内容。

这个项目最有启发性的部分并非流程本身，而是比较模型在有检索和无检索时的行为表现。

「队列上有哪些操作？」

不带 RAG 时，Gemini 根据通用的训练知识作答——精神上正确，但与实际参考材料脱节。

带 RAG 时，同样的问题返回了基于特定文档的答案，正确地呈现了：

• Enqueue • Dequeue • Peek/Front • Rear • isFull • isEmpty

这种并排对比以一种阅读 RAG 相关资料永远无法达到的方式，让检索的价值变得直观可感。

💡 更大的启示：RAG 系统实际上是两种截然不同技术之间的桥梁——一种擅长查找信息的向量数据库，另一种擅长解释信息的语言模型。

单独使用时，文档问答哪个都做不好；合在一起，则能互补彼此的弱点。

这篇文章是对这一设计洞察的简短反思。完整构建——包括完整的五步工作流、代码和实现细节——详见原文。

如需进一步操作，你可以考虑屏蔽此人或举报滥用行为