大型网站空间费用,个人网站里在哪点击模版,英语外贸网站建设,个域名的网站建设方案书过去 9 年里#xff0c;HelloGitHub 月刊累计收录了 3000 多个开源项目。然而#xff0c;随着项目数量的增加#xff0c;不少用户反馈#xff1a;“搜索功能不好用#xff0c;找不到想要的项目#xff01;” 这让我意识到#xff0c;仅仅收录项目是不够的#xff0c;还… 过去 9 年里HelloGitHub 月刊累计收录了 3000 多个开源项目。然而随着项目数量的增加不少用户反馈“搜索功能不好用找不到想要的项目” 这让我意识到仅仅收录项目是不够的还需要通过更智能的方式帮助用户找到心仪的开源项目。于是我开始探索如何通过 RAG 技术解决这个问题。 检索增强生成(RAG)是赋予生成式人工智能模型信息检索能力的技术。 RAG 技术我早有耳闻但却一直不知道该从哪里入手。虽然现在有不少容易上手的 RAG 低代码平台但我不想只停留在“会用”的层面更希望了解它的实现细节否则不敢在生产环境中用。不过要让我直接用 LangChain 和 Ollama 从零搭建一个 RAG 系统还真有点心里没底。 还好最近 OceanBase 搞事情在 4.3.3 版本里支持了向量检索功能更贴心的是还专门为像我这样对 RAG 感兴趣的新手准备了一个用 Python 搭建 RAG 聊天机器人的实战教程。 GitHub 地址github.com/oceanbase/oceanbase 光看永远只是纸上谈兵所以我干脆上手把玩了一番。 接下来我将分享如何基于该项目打造一款 HelloGitHub 开源社区的聊天机器人内容包括实现过程、细节优化以及对 RAG 技术的理解与未来展望。 一、介绍 OceanBase 开源的 RAG 聊天机器人能够通过自然对话更精准地回答与 OceanBase 文档相关的问题。 该项目是基于 langchain、langchain-oceanbase 和 streamlit 构建处理流程是先将 OceanBase 数据库的文档通过 Embedding 模型转化为向量数据并存储在 OceanBase 数据库中。当用户提问时系统会用相同的模型将问题转化为向量然后通过向量检索找到相关的文档内容再将这些文档作为上下文提交给大语言模型从而生成更精准的回答。 在线体验oceanbase.com/obi 体验后我感觉效果还不错于是就萌生了一个想法能不能把 OceanBase 的文档换成 HelloGitHub 月刊的 Markdown 文件灌进系统里这样不就摇身一变成为 HelloGitHub 专属的聊天机器人了吗说干就干 二、安装运行 在开始改造之前首先需要把项目跑起来。安装运行的步骤在 OceanBase 提供的实战教程中已经很详细了这里不再过多介绍。运行步骤如下 执行 embed_docs.py 脚本将文档内容向量化后存储到 OB启动项目 streamlit run --server.runOnSave false chat_ui.py 启动成功将自动跳转至此界面 建议 Python 版本管理运行需要 Python 3.9建议使用 pyenv 管理项目的 Python 版本。查看数据库不论是通过 Docker 部署 OceanBase 还是使用 OB Cloud都建议在本地通过 GUI 工具查看数据库有助于开发和调试。 运行 embed_docs.py 脚本后查看数据库中的表你会发现这些字段 document存储原始的文档内容embedding存储文档向量化后的数据metadata记录文档的名称、路径以及切分后的标题等信息 其中 embedding 列是一个类似数组形式的数据这个就是通过 Embedding 模型将文档片段转化为向量数据的结果。这些向量数据能够捕捉文本的语义信息使计算机能够更好地理解文本的含义从而实现类似语义搜索的功能计算距离为后续问题与文档内容的匹配提供基础。 三、动手改造 这个项目除了支持 LLMs API还可以切换为本地的 Ollama API 使用只需修改 .env 配置文件即可完成调整 # 使用支持 embed API 的模型
OLLAMA_URLlocalhost:11434/api/embed
OLLAMA_TOKEN
OLLAMA_MODELall-minilm 注意在调用第三方付费 API 时一定要注意使用量建议仅导入部分文档用于测试或用本地 LLM 调试逻辑避免不必要的花费。 3.1 导入 HelloGitHub 月刊 通过 embed_docs.py 脚本将 HelloGitHub 月刊内容向量化并导入到 OceanBase 数据库命令如下 python embed_docs.py --doc_base /HelloGitHub/content --table_name hg 参数说明 doc_baseHelloGitHub 内容目录table_name脚本会自动创建该表并将数据存储到表中。 但是运行后我查看数据库时发现 document 字段中包含了许多无意义的内容例如格式符号或无关信息 面对这些噪声数据我编写了一个脚本清洗 HelloGitHub 月刊文件中无关的格式符号和冗余内容并重新导入数据库。 3.2 启动服务 在启动服务时需要通过环境变量 TABLE_NAME 指定要使用的表。命令如下 TABLE_NAMEhg2 streamlit run --server.runOnSave false chat_ui.py 我试了一下回答的效果并不理想 经过测试我分析问答效果不好的原因可能包括以下几点 向量化效果所选用的模型 all-minilm 仅有 384 维度可以尝试更大的 Embedding 模型数据清理虽然清理了一部分无用内容但可能还有一些噪声数据未处理完全文档完整性HelloGitHub 的内容结构是否适合问答模型需要进一步分析提示词需要完善提示词设计补充更多上下文 四、优化问答效果 我开始对 RAG 有些感觉了所以准备切换到付费但效果更好的通义千问 text-embedding-v3 模型1024 维度进行调试。 4.1 数据优化 为提升问答效果我决定进一步优化 document 的构造方式。具体思路是将 HelloGitHub 网站中的表导入至 OceanBase 数据库并基于这些表的数据构建更干净和精准的内容。这样可以最大程度地确保项目数据的全面性同时减少无关内容的干扰提升向量检索相关性。 导入表到 OceanBase OceanBase 和 MySQL 高度兼容因此我直接用 Navicat 将 HelloGitHub 的数据表结构和内容从 MySQL 无缝迁移到了 OceanBase。然后我写了一个 embed_sql.py 脚本通过直接查询相关表的数据进而生成更精简的内容document同时补充元数据metadata并存储到数据库。核心代码如下 # 构建内容document
content f{row.get(name, 未知)}{row.get(title, 未知标题)}。{row.get(summary, 暂无概要)}# 构建元数据metadata
metadata {repository_name: row.get(name, N/A), # 仓库名称repository_url: row.get(url, N/A), # 仓库链接description: row.get(summary, N/A), # 项目描述category_name: row.get(category_name, N/A), # 类别名称language: row.get(primary_lang, N/A), # 主要编程语言chunk_title: row.get(name, N/A), enhanced_title: f内容 - {row.get(category_name, N/A)} - {row.get(name, N/A)}...
}# 将内容和元数据添加到文档对象
docs.append(Document(page_contentcontent.strip(), metadatametadata))
# 存储到数据库
vs.add_documents(docs,ids[str(uuid.uuid4()) for _ in range(len(docs))],
) 经过多轮调试和对比我发现 document 数据越精简向量检索效果越好随后将完整的数据集存入 OceanBase 数据库的 hg5 表。 python embed_sql.py --table_name hg5 --limit4000
args Namespace(table_namehg5, batch_size4, limit4000, echoFalse)
Using RemoteOpenAI
Processing: 100%|███████████████████████████████████████████████████████████████████████▉| 3356/3357 [09:3300:00, 5.85row/s] 至此基于数据库表构造的 document 数据已经非常干净了。 4.2 提示词优化 在优化完数据后我开始思考如何优化提示词并对 LLM 的回答进行引导和强化。以下是针对 LLM 提示词优化的方向 明确背景和任务在提示词中设定问答的背景并限制问题的范围例如确保问题只涉及开源项目或 HelloGitHub 的内容。丰富上下文将 metadata元数据 和 document项目描述同时提供给大模型让 LLM 有更多上下文来生成精确回答。高质量示例提供高质量的回答示例统一输出格式。约束逻辑明确要求 LLM 不得虚构答案。如无法回答问题需清楚指出知识盲点并合理提供方向性建议。 4.3 处理流程优化 在优化向量检索和回答的流程方面我做了以下改进 扩大检索范围向量检索默认只返回前 10 条最高相似度的内容。我将其扩展至 20 条为 LLM 提供更多上下文选择。判断相关性使用提示词指导 LLM 在输出答案前先判断问题是否与 HelloGitHub 或开源项目相关避免生成无关回答。提炼回答基于用户输入分析意图后选出最相关的 5 个项目并结合元数据生成更贴合用户需求的回答。 4.4 效果展示 除了上面的优化我还进一步简化了页面、删除用不到的代码最终呈现效果如下 回答效果对比 通过切换至通义千问 text-embedding-v3 模型同时优化数据、提示词策略和问答流程让这套 RAG 系统的回答质量有了明显提升但我打算自己盘一盘再上线。所以先放出源码感兴趣的小伙伴可以作为参考 GitHub 地址github.com/521xueweihan/ai-workshop-2024 五、最后 在构建 HelloGitHub 的 RAG 聊天机器人过程中回答效果一直不好让我一度产生了放弃的念头。但当我通过查询表里的数据构造 document并使用维度更大的 Embeding 模型后回答效果直线提升才让我重新看到了希望。 这段经历也让我开始认真思考优化 RAG 的关键是什么我的答案是 数据检索。如今许多企业希望借助 AI 技术赋能已有服务RAG 则是一种门槛较低的通用解决方案。在这一过程中数据质量决定了基础高质量数据往往是从海量数据提纯而来。检索则是确保内容能够被快速且准确提取的关键。否则不管提示词再怎么优化也无法检索到有价值的内容就无法实现增强的效果。 另外我认为在未来的 RAG 应用中除了向量数据数据库还需要具备一些关键能力来确保检索和生成的高效性。例如支持关系型数据和向量数据的混合搜索不仅能处理结构化和非结构化数据还能有效减少 RAG 模型中的“幻觉”问题从而让生成的答案更准确、更有根据。图搜索知识图谱同样很重要它为 RAG 提供复杂推理所需的背景信息提升生成质量。此外RAG 应用在许多场景中需要频繁更新和同步数据因此数据库还需支持实时查询、低延迟响应、事务处理和高可用性这些是确保 RAG 高效运行的基础。 OceanBase 的分布式架构优势让它在面对海量数据时依然游刃有余。而新引入的向量存储和检索能力使得我们能够通过 SQL 轻松获取最“干净”的数据并在同一个数据库内完成向量化操作。OceanBase 未来可期 GitHub 地址github.com/oceanbase/oceanbase 开源不易感谢 Star✨ 最后为坚持读完本文的读者送上一波特别福利留言即可参与我们将在 2025.1.1 随机抽取 5 位留言的读者每人一套由 OceanBase 提供的限量版「章鱼猫」乐高小玩具如上图。快来评论区分享你对 OceanBase 的使用体验或心得吧 - END - 关注「HelloGitHub」第一时间收到更新
