上次分享了关于知识库切片方案后，收到了很多朋友的反馈和讨论，甚至还发生了一些小插曲，但大家的关注和认可让我更加坚信这个方案的价值。这次，我将延续上次的内容，深入探讨如何将知识库切片方案优化为问答对模式，以及我们在实际落地 RAG (Retrieval Augmented Generation) 过程中遇到的常见难点和具体的解决方案。希望我的经验能帮助大家少走弯路！
一、附件与图片如何存储？告别“污染”问答对
当我们将文档切片转化为问答对后，一个常见的问题是：原始文档中的图片、附件等资料该如何存放？很多人可能没有注意到这个细节。
解决方案： 答案非常简单：在存储问答对到向量数据库时，可以设置一个备注字段来保存这些图片、附件等资料的链接或标识。
为什么不直接存到问答对中？
保证回答质量和准确度： 问答对是确保 AI 回答质量的核心。我们的所有设计都应尽量避免“污染”问答对，保证其内容的相对独立性和纯净性。
便于后期维护： 将截图、附件等内容与问答对本身分离，后续维护将变得非常便捷。当图片更新时，您只需更新备注字段，而无需改动 AI 已经学习到的问答内容，大大简化了维护流程。
二、巧妙利用大语言模型生成高质量问答对
如何让大语言模型 (LLM) 帮助我们高效生成问答对？这其中有一些小技巧。
基本思路： 首先，明确告诉大语言模型您正在处理的是技术文档，然后引导它根据文档内容生成问答对。
“不传之秘”：
对话成本减半的技巧：您可能看到截图中的对话像是与大语言模型进行了两次交互，但实际上我们只进行了一次！这节省了 50% 的成本。如何做到？ 其实很简单，大语言模型的对话历史记录是可以“伪造”的。在截图的例子中，大语言模型回答的“好的，我将在后续任务参考上述文档。请告诉我你的具体任务”是我们自己“伪造”的历史记录，让模型误以为这已经是第二次对话了。而实际上，这才是我们与模型的首次真正交互。
关注 Summary 信息： 请注意模型回答中的 Summary 信息。这是我们故意让大模型创建的。它的作用是帮助大模型在给最终用户回复时，能更好更快地理解和回答问题，提升用户体验。
我们的问答对存储结构（Payload）：
一个问答对我们大致保存以下内容
三、我们的技术架构与部署方案
我们的整体方案涵盖了 RAG 的三大核心环节：构建、检索和生成。
技术架构：
构建 (ETL)： 数据提取、切片、向量化。
检索 (Retrieval)： 混合检索 + RRF 排序。
生成 (Generation)： 问答模式 + 思考模式。
部署方案：
我们主要使用了以下数据库：
Qdrant 向量数据库
MySQL 数据库
