RAG 进阶：一个 ctrl-c 就能拿走的图文检索框架

HuixiangDou 是群聊场景的 LLM 知识助手。群里人多口杂，机器人显然不应该答复所有消息，它的设计规则为：

• 无关内容不吭声——拒答

• 明确该答的，直接回复——检索

• 不能违反核心价值观——可靠

https://github.com/InternLM/HuixiangDou

(觉得好用，欢迎点亮 star)

在上一篇文章中，我们介绍如何用知识图谱提升稠密检索能力，本文分享 HuixiangDou 在图文检索中的软件设计考量。

软件设计

目前 GitHub 上已经有很多知名 RAG 框架：

• Langchain：以 langchain-core 和 langchain-community 为主，提供了海量 LLM 应用样例

• GraphRAG：基于多轮 LLM，从原始文本构建不同层次知识图谱

• Ragflow：提供了一套完整的 RAG 工作流程，适用于不同规模的企业及个人

HuixiangDou 聚焦在群聊场景，除了能提供业务数据上的精度报告外，在实现层面没有历史包袱，因此更简单有效。

鼓励用户拿走代码

不仅仅是 pip install 再调 API，HuixiangDou 假设用户也喜欢直接 copy 走源码。

这样能同时改善双方的体验：

1. 作者不需要在 API 文档和维护上投入太多精力，毕竟没有复杂抽象

2. 用户理解起来也没有难度，所见即所得，只需要关注算法细节本身

因此 HuixiangDou 源码有三个核心目录：

• primitive。一些基础设计，如多模态 query、切分方法 splitter 、特征读写 faiss 等

• service。RAG 需要的 pipeline 逻辑，如网络搜索、混合知识图谱做拒答等

• frontend。群聊软件（如飞书、微信等）的接入方法

相对于 langchain ，HuixiangDou 的设计更贴合每个模块原本的功能，例如：

• 切分后的结构是 Chunk 而非 Document

• 特征是否归一化、使用哪种距离函数，取决于 embedder 模型的设计。这并非 faiss 存储的职责

• Query 对图片/语音更友好，不需要塞进尴尬的 metadata 里

如果用户希望构建自己的 RAG 应用，既不希望引入庞大依赖又不想自己写，ctrl-c 拿走 primitive 目录即可。HuixiangDou 还提供了单元测试和精度报告，保证拿走的都是可靠的。

图文混合检索

如果有 10G 显存，HuixiangDou 目前可用 Visualized-BGE 提取图片特征，图片和文字的特征放入同一个 faiss 库中，等待后续检索。

特征库构建过程和纯文本模态完全相同：

python3 -m huixiangdou.service.feature_store --config_path config-multimodal.ini

然后用以下命令，运行一个简单的 gradio WebUI：

python3 tests/test_query_gradio.py --config_path config-multimodal.ini

提交问题和图片，可以检索图片所属文档，并作答：

运行需注意：

• 手动下载 eva-clip 权重到 bge-m3 模型目录。Visualized-BGE 模型本质是对齐图片和文字的语义

• 要安装 HuixiangDou 的 requirements-multimodal.txt和 FlagEmbedding main 分支，我们做了些小修复

得益于 primitive 的简洁设计，HuixiangDou 在默认情况下，仍然是仅需 1.5G 显存的 BCE 纯文本模型。我们已对齐了实现多模态前后的业务精度。

总结

本文分享了 HuixiangDou 在实现图片混合检索过程中，在设计层面的考量，我们更鼓励用户拿走代码。

在图文检索方面，目前只支持 markdown 文件，还需支持更多格式。