上次分享了关于知识库切片方案后,收到了很多朋友的反馈和讨论,甚至还发生了一些小插曲,但大家的关注和认可让我更加坚信这个方案的价值。这次,我将延续上次的内容,深入探讨如何将知识库切片方案优化为问答对模式,以及我们在实际落地 RAG (Retrieval Augmented Generation) 过程中遇到的常见难点和具体的解决方案。希望我的经验能帮助大家少走弯路!
一、附件与图片如何存储?告别“污染”问答对
当我们将文档切片转化为问答对后,一个常见的问题是:原始文档中的图片、附件等资料该如何存放?很多人可能没有注意到这个细节。
解决方案: 答案非常简单:在存储问答对到向量数据库时,可以设置一个备注字段来保存这些图片、附件等资料的链接或标识。
为什么不直接存到问答对中?
-
保证回答质量和准确度: 问答对是确保 AI 回答质量的核心。我们的所有设计都应尽量避免“污染”问答对,保证其内容的相对独立性和纯净性。
-
便于后期维护: 将截图、附件等内容与问答对本身分离,后续维护将变得非常便捷。当图片更新时,您只需更新备注字段,而无需改动 AI 已经学习到的问答内容,大大简化了维护流程。
二、巧妙利用大语言模型生成高质量问答对
如何让大语言模型 (LLM) 帮助我们高效生成问答对?这其中有一些小技巧。
基本思路: 首先,明确告诉大语言模型您正在处理的是技术文档,然后引导它根据文档内容生成问答对。

“不传之秘”:
对话成本减半的技巧:您可能看到截图中的对话像是与大语言模型进行了两次交互,但实际上我们只进行了一次!这节省了 50% 的成本。如何做到? 其实很简单,大语言模型的对话历史记录是可以“伪造”的。在截图的例子中,大语言模型回答的“好的,我将在后续任务参考上述文档。请告诉我你的具体任务”是我们自己“伪造”的历史记录,让模型误以为这已经是第二次对话了。而实际上,这才是我们与模型的首次真正交互。
关注 Summary 信息: 请注意模型回答中的 Summary 信息。这是我们故意让大模型创建的。它的作用是帮助大模型在给最终用户回复时,能更好更快地理解和回答问题,提升用户体验。
我们的问答对存储结构(Payload):
一个问答对我们大致保存以下内容

三、我们的技术架构与部署方案
我们的整体方案涵盖了 RAG 的三大核心环节:构建、检索和生成。
技术架构:
-
构建 (ETL): 数据提取、切片、向量化。
-
检索 (Retrieval): 混合检索 + RRF 排序。
-
生成 (Generation): 问答模式 + 思考模式。

部署方案:
我们主要使用了以下数据库:
-
Qdrant 向量数据库
-
MySQL 数据库
