RAG问答效果不佳方案

经过测试，我分析问答效果欠佳的原因，可能包括以下几点：

1. 向量化效果：所选用的模型 all-minilm 仅有 384 维度，可以尝试更大的 Embedding 模型；

2. 数据清理：虽然清理了一部分无用内容，但可能还有一些噪声数据未处理完全；

3. 文档完整性：HelloGitHub 的内容结构是否适合问答模型需要进一步分析；

4. 提示词：需要完善提示词设计，补充更多上下文；

1、数据优化

为提升问答效果，我决定进一步优化 document 的构造方式。具体思路是：将 HelloGitHub 网站中的表导入至 OceanBase 数据库，并基于这些表的数据，构建更干净和精准的内容。这样可以最大程度地确保项目数据的全面性，同时减少无关内容的干扰，提升向量检索相关性。

导入表到 OceanBase

OceanBase 和 MySQL 高度兼容，因此，我直接用 Navicat 将 HelloGitHub 的数据表结构和内容，从 MySQL 无缝迁移到了 OceanBase。

经过多轮调试和对比，我发现document 数据越精简，向量检索效果越好，随后将完整的数据集存入 OceanBase 数据库的hg5表

2、提示词优化

在优化完数据后，我开始思考如何优化提示词，并对 LLM 的回答进行引导和强化。以下是针对 LLM 提示词优化的方向：

1. 明确背景和任务：在提示词中设定问答的背景并限制问题的范围，例如，确保问题只涉及开源项目或 HelloGitHub 的内容。

2. 丰富上下文：将 metadata（元数据） 和 document（项目描述）同时提供给大模型，让 LLM 有更多上下文来生成精确回答。

3. 高质量示例：提供高质量的回答示例，统一输出格式。

4. 约束逻辑：明确要求 LLM 不得虚构答案。如无法回答问题，需清楚指出知识盲点，并合理提供方向性建议。

3、处理流程优化

在优化向量检索和回答的流程方面，我做了以下改进：

1. 扩大检索范围：向量检索默认只返回前 10 条最高相似度的内容。我将其扩展至 20 条，为 LLM 提供更多上下文选择。

2. 判断相关性：使用提示词指导 LLM 在输出答案前，先判断问题是否与 HelloGitHub 或开源项目相关，避免生成无关回答。

3. 提炼回答：基于用户输入分析意图后，选出最相关的 5 个项目，并结合元数据生成更贴合用户需求的回答。

优化 RAG 的关键是什么？我的答案是数据+检索，数据质量决定了基础，高质量数据往往是从海量数据提纯而来。检索则是确保内容能够被快速且准确提取的关键。否则不管提示词再怎么优化，也无法检索到有价值的内容，就无法实现增强的效果。

在未来的 RAG 应用中，除了向量数据，数据库还需要具备一些关键能力来确保检索和生成的高效性。例如，支持关系型数据和向量数据的混合搜索，不仅能处理结构化和非结构化数据，还能有效减少 RAG 模型中的“幻觉”问题，从而让生成的答案更准确、更有根据。图搜索（知识图谱）同样很重要，它为 RAG 提供复杂推理所需的背景信息，提升生成质量。此外，RAG 应用在许多场景中需要频繁更新和同步数据，因此数据库还需支持实时查询、低延迟响应、事务处理和高可用性，这些是确保 RAG 高效运行的基础。