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 走源码。
这样能同时改善双方的体验：
-
作者不需要在 API 文档和维护上投入太多精力，毕竟没有复杂抽象
-
用户理解起来也没有难度，所见即所得，只需要关注算法细节本身
因此 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 文件，还需支持更多格式。