当前位置：首页 > news >正文

开源RAG助手HuixiangDou：群聊场景下的智能文档问答部署与优化

news 2026/5/2 8:34:25

1. 项目概述与核心价值

如果你正在寻找一个能帮你搞定技术文档问答、又能无缝接入微信群聊，并且对硬件要求还特别“亲民”的开源助手，那么 HuixiangDou（以下简称“茴香豆”）绝对值得你花时间研究一下。我最初接触它，是因为团队内部的技术支持群消息太多，很多重复的、基于文档的问题淹没了真正重要的讨论。我们需要一个能“聪明”地识别问题、精准回答，但又不会刷屏的机器人。市面上很多基于大语言模型（LLM）的聊天机器人要么部署复杂，要么在群聊场景下像个“话痨”，而茴香豆的设计哲学恰好击中了这些痛点。

简单来说，茴香豆是一个基于大语言模型的专业领域知识助手。它的核心目标不是陪你闲聊，而是充当一个高效的“知识库守门员”和“答疑专家”。你可以把它理解为一个高度定制化的 RAG（检索增强生成）系统，但它做了大量针对实际应用场景的优化。最让我印象深刻的是它的“三段式”处理管道：预处理、拒答和响应。这个设计让它在嘈杂的群聊环境中，能像一位经验丰富的技术支持工程师一样，只在被确切问到且自己“懂行”的时候才发言，避免了无意义的刷屏和“一本正经地胡说八道”。

它的优势非常明确：第一，针对群聊场景做了深度优化，通过算法判断是否应该回答，这在技术社区、公司内部支持群里简直是刚需；第二，部署友好，提供了从纯CPU到10G显存GPU的多档配置，甚至还有完整的Web、Android和源码方案，意味着你可以从个人学习一直用到商业部署；第三，功能全面，支持多种文件格式（PDF、Word、Markdown等）、多种检索方式（稠密检索、知识图谱、代码检索等）以及多种集成渠道（微信、飞书、Web API）。最近发布的 HuixiangDou2 更是引入了 GraphRAG，在植物科学领域的应用甚至登上了《Cell》子刊，证明了其在垂直领域的强大潜力。

2. 核心设计思路与架构拆解

2.1 为什么是“三段式”管道？

很多初涉RAG的开发者容易陷入一个误区：认为只要把文档塞进向量数据库，然后让LLM根据检索结果生成答案就行了。但在真实的、尤其是群聊这种开放域场景下，这会带来两个严重问题：1）答非所问：用户可能只是在闲聊，或者问了一个知识库之外的问题，机器人却强行从文档中找些似是而非的内容来回答，显得很蠢。2）消息泛滥：机器人对每个问题都响应，很快就会被群主“踢出群聊”。

茴香豆的“预处理-拒答-响应”三段式管道，就是为了系统性地解决这些问题。

预处理阶段：这不仅仅是简单的文本切分。它会对你提供的知识库文档进行深度解析，包括提取文本、处理表格、图片中的文字（OCR），并进行指代消解。比如，文档中可能写“该产品（指代A）的特性是...”，预处理会尝试将“该产品”明确关联到“A”，使得后续检索更准确。同时，它会根据问题和知识库内容，动态计算一个“拒答阈值”。
拒答阶段：这是茴香豆的“大脑皮层”，负责判断当前问题是否值得回答。它会计算用户问题与知识库的相关性，以及问题是否属于预设的“好问题”（应回答）或“坏问题”（应拒绝）模式。只有相关性高，且不属于明确拒答范畴的问题，才会进入下一阶段。这个阈值是可调的，你可以根据机器人的“高冷”或“热情”程度来调整。
响应阶段：经过前两轮筛选，到达这里的问题基本确定是知识库范围内的。此时，系统会采用混合检索策略（如稠密向量检索+关键词检索+知识图谱），从知识库中找出最相关的片段，并组织成提示词（Prompt）提交给LLM，生成最终的回答。它还会附上答案的来源引用，增加可信度。

这个设计思路的核心是先判断，后回答，把有限的LLM计算资源用在刀刃上，同时极大地提升了在真实场景中的可用性和用户体验。

2.2 混合检索策略：不仅仅是向量搜索

单一的向量检索在面对专业术语、代码片段或复杂概念关系时，可能会力不从心。茴香豆集成了多种检索方式，你可以根据需求组合使用：

稠密检索（Dense Retrieval）：这是主流方案，使用如 BGE、BCEmbedding 等模型将文本转换为向量，通过计算余弦相似度找到语义最接近的文档块。适合处理自然语言描述的概念性问题。
稀疏检索（Sparse Retrieval）/ 倒排索引：特别适用于代码检索。代码的语法结构性强，关键词（如函数名、API）比语义更重要。倒排索引能快速定位包含特定关键词的代码片段，效率很高。
知识图谱检索（GraphRAG）：这是 HuixiangDou2 的亮点。它不再将文档视为孤立的片段，而是尝试构建实体（概念、术语）之间的关系图。当用户提问时，系统可以从图谱中检索出与问题实体相关联的一整片知识网络，从而生成更具逻辑性和连贯性的答案，尤其适合知识结构严谨的领域（如医药、法律、植物学）。
图像与文本多模态检索：如果你开启了多模态配置，茴香豆可以处理包含图片的文档。它能提取图片中的文字信息，并与文本内容一起建立索引，实现“图文联合检索”。

在实际配置中，你可以在config.ini里指定使用的检索器。例如，对于技术文档，我通常会启用稠密检索+倒排索引（用于代码）；如果文档中概念关联性强，则会考虑加入知识图谱。

2.3 硬件配置的弹性设计

茴香豆另一个务实的设计是对硬件资源的弹性适配。它没有要求你必须有一张顶级显卡，而是提供了清晰的配置阶梯：

CPU 版（0 GPU）：完全依赖云端LLM API（如 SiliconCloud）。本地只运行检索模型（可选用CPU友好的小模型）和业务逻辑。适合初学者体验或作为轻量级服务。
标准版（约 2GB GPU）：在本地运行一个7B参数左右的量化版LLM（如 Qwen2.5-7B-Instruct-GPTQ-Int4），同时运行检索模型。这是性价比最高的生产级配置，响应速度快，成本可控。
多模态版（约 10GB GPU）：在标准版基础上，增加运行多模态嵌入模型（如 BGE-M3），以支持图像内容的处理和检索。适合知识库中包含大量图表、截图的场景。

这种设计让你可以根据自己的硬件条件和功能需求，像搭积木一样选择合适的部署方案，避免了资源浪费或性能瓶颈。

3. 从零开始部署与实操指南

下面，我将以最常用的“标准版”（本地2G显存部署）为例，带你完整走一遍部署、建库、测试的流程。我会穿插我踩过的一些坑和优化技巧。

3.1 环境准备与依赖安装

首先，你需要一个 Linux 环境（Ubuntu 20.04/22.04 为宜），一张至少有 6GB 显存的 NVIDIA 显卡（给2G的LLM和系统留出余量）。

# 1. 克隆仓库 git clone https://github.com/InternLM/HuixiangDou.git cd HuixiangDou # 2. 安装系统依赖（用于解析Word、PDF等格式） sudo apt update sudo apt install -y python3-dev libxml2-dev libxslt1-dev antiword unrtf poppler-utils pstotext tesseract-ocr flac ffmpeg lame libmad0 libsox-fmt-mp3 sox libjpeg-dev swig libpulse-dev

注意：tesseract-ocr是OCR引擎，如果知识库没有图片，可以暂时不装，但建议装上以备不时之需。安装过程可能会比较耗时。

接下来是Python环境。我强烈建议使用 Conda 创建一个独立环境，避免包冲突。

# 3. 创建并激活Conda环境（以Python 3.10为例） conda create -n huixiangdou python=3.10 -y conda activate huixiangdou # 4. 安装Python依赖 pip install -r requirements.txt

这里有个关键点：requirements.txt里包含了faiss-gpu。如果你的 CUDA 版本较新（如12.x），可能会安装失败。如果遇到问题，可以尝试指定版本或从源码编译。一个更稳妥的方法是使用faiss-cpu，但检索速度会慢一些。对于标准版，GPU版的Faiss能显著加速向量检索。

3.2 构建你的第一个知识库

茴香豆默认用一些小说文档做示例。我们首先复现这个例子，确保流程跑通。

# 1. 创建知识库文档目录和特征存储目录 mkdir repodir workdir # 2. 复制示例文档到知识库目录 cp -rf resource/data/* repodir/ # 3. 构建知识库特征 python3 -m huixiangdou.services.store

执行第三步后，你会看到详细的处理日志。这个命令会：

解析repodir下的所有文档（支持 .md, .pdf, .docx, .txt 等）。
将文本切分成块（chunks），默认策略可能不适合你的文档，后面会讲调整。
使用指定的嵌入模型（在config.ini中配置）将文本块转换为向量。
计算正例（resource/good_questions.json）和反例（resource/bad_questions.json）与知识库的相似度，动态确定一个“拒答阈值”，并更新到config.ini中的reject_throttle。
将所有向量和元数据保存到workdir目录。

实操心得：

repodir里的文档结构可以是扁平的，也可以包含子文件夹。系统会递归读取。
处理大量文档时，这一步可能较慢。可以在config.ini的[feature_store]部分调整batch_size和chunk_size来优化。
good_questions.json和bad_questions.json是调优机器人口吻的关键。初始化后，一定要根据你的知识库内容，填充一些典型的应答和拒答问题样例。这能帮助系统更好地学习“什么该管，什么不该管”。

3.3 配置与启动大语言模型（LLM）

这是核心环节。茴香豆支持多种LLM后端，这里演示两种最常用的：本地 vLLM 部署和云端 API（以 Kimi 为例）。

方案一：使用本地 vLLM 部署（推荐，延迟低，可控）

首先，下载一个合适的量化模型。以 Qwen2.5-7B-Instruct 的 GPTQ 量化版为例（显存占用约5-6G，但vLLM服务后，茴香豆客户端配置2G即可）。

# 使用 vLLM 启动模型服务 vllm serve Qwen/Qwen2.5-7B-Instruct-GPTQ-Int4 --served-model-name qwen-local --api-key token-abc123 --port 8000

然后，修改config.ini中的 LLM 配置部分：

[llm.server] remote_type = "vllm" # 指定使用 vLLM 后端 remote_api_key = "token-abc123" # 与启动命令中的 --api-key 一致 remote_llm_model = "qwen-local" # 与 --served-model-name 一致 remote_api_base = "http://localhost:8000/v1" # vLLM 的 OpenAI 兼容接口地址

方案二：使用云端 API（方便，无需显卡）

以 Kimi 为例，你需要先去其官网申请 API Key。

[llm.server] remote_type = "kimi" # 或 "deepseek", "step" 等 remote_api_key = "你的-kimi-api-key" remote_llm_model = "auto" # 通常填 auto 即可，或指定具体模型名

配置要点：

config.ini里有很多被注释的配置示例，你只需要取消注释你想要的那一种，并填写正确的api_key。
remote_type必须与支持列表中的名称严格一致。
如果使用本地模型，确保remote_api_base指向正确的地址和端口。vLLM 默认提供 OpenAI 兼容的/v1接口。

3.4 运行测试与基础调优

配置好后，就可以进行测试了。

# 运行命令行交互测试 python3 -m huixiangdou.main

程序启动后，会加载模型和知识库，然后进入交互界面。你可以输入问题测试。例如，基于示例的“百草园”文档，问“百草园里有什么？”，它会从文档中检索并生成答案。问“今天天气怎么样？”，它应该显示“Init state”或类似信息，表示触发了拒答。

如何让机器人更“聪明”或更“高冷”？

调整拒答阈值 (reject_throttle)：在config.ini的[feature_store]部分。这个值在运行services.store后会自动计算。如果你觉得机器人太爱答话（回答了无关问题），可以适当调高这个值（如从0.3调到0.5）。如果太沉默（该答的没答），可以调低。建议每次调整幅度为0.05，然后通过good_questions.json和bad_questions.json里的问题来测试效果。
优化知识库文档：确保repodir下的文档是干净、相关的。无关的内容（如版权声明、广告）会被索引，可能导致错误召回。文档结构尽量清晰，Markdown 格式最佳。
丰富正反例：持续维护good_questions.json和bad_questions.json。这是教机器人“守规矩”最直接的方式。问题可以多样化，覆盖知识库的核心内容和常见的无关问法。

3.5 启用 Web 界面与 API 服务

命令行测试没问题后，可以启动更友好的 Web 界面或 API 服务。

# 启动 Gradio Web UI (默认端口 7860) python3 -m huixiangdou.gradio_ui # 启动 HTTP API 服务器 (默认端口 23333) python3 -m huixiangdou.api_server

启动 API 服务器后，你就可以通过 HTTP 请求来调用茴香豆了：

# 测试同步接口 curl -X POST http://127.0.0.1:23333/huixiangdou_inference \ -H "Content-Type: application/json" \ -d '{"text": "如何安装MMPose？", "image": ""}' # 测试流式接口（答案会分块返回） curl -X POST http://127.0.0.1:23333/huixiangdou_stream \ -H "Content-Type: application/json" \ -d '{"text": "百草园的景色如何？", "image": ""}'

这为后续集成到飞书、微信等平台打下了基础。API 的输入输出是结构化的 JSON，非常便于二次开发。

4. 高级功能与集成实战

4.1 接入微信群聊（Android 无障碍模式）

这是茴香豆的一大特色。它通过 Android 的“无障碍服务”模拟点击和读取屏幕，来实现与微信的交互。注意：此方式仅用于学习和测试，用于大量、自动化的消息处理可能违反微信使用条款。

准备一部 Android 手机：开启开发者选项和 USB 调试。将手机通过 USB 连接电脑。
安装 Android 工具：在项目android目录下，提供了编译好的 APK 或源码。你需要将huixiangdou.apk安装到手机。
配置无障碍服务：在手机设置->无障碍服务中，找到并开启“茴香豆”服务。
运行连接脚本：在电脑上，运行python3 -m android（具体脚本可能在不同分支，请查阅docs/zh/doc_add_wechat_accessibility.md）。脚本会通过 ADB 与手机上的服务通信。
配置监听群：在脚本或配置文件中，指定需要监听的微信群名称。当这些群出现新消息时，手机会将消息内容通过 ADB 传回电脑端的茴香豆服务处理，生成答案后再传回手机，由无障碍服务模拟点击“发送”。

踩坑记录：

权限问题：确保电脑 ADB 有权限访问手机。有时需要手机弹窗点击“允许”。
屏幕锁：流程运行期间，最好保持手机屏幕常亮且解锁，否则无障碍服务可能失效。
消息过滤：一定要在茴香豆的配置里设置好good_questions和bad_questions，并合理调整拒答阈值。否则机器人可能在群里疯狂刷屏，后果很严重。
性能：此方式依赖于 ADB 传输和屏幕解析，延迟较高（通常几秒到十几秒），且占用手机资源。仅适合轻量级、对实时性要求不高的场景。

4.2 接入飞书群聊（官方机器人方式）

对于企业环境，接入飞书是更稳定、合规的选择。茴香豆支持飞书机器人的接收和发送。

创建飞书机器人：在飞书开放平台创建一个自定义机器人，获取app_id和app_secret。
配置事件订阅：在机器人配置页面，设置“消息与事件”的请求地址，指向你部署的茴香豆 API 服务器的/feishu端点（例如http://your-server:23333/feishu）。飞书会向这个地址发送群消息事件。
修改茴香豆配置：在config.ini中，找到[lark]部分，填入你的app_id和app_secret，并配置需要响应的群聊名称或ID。
启动服务：重启huixiangdou.api_server。当指定飞书群有消息时，飞书服务器会将事件推送给你的 API，茴香豆处理后再通过飞书机器人接口将答案发回群内。

这种方式稳定、延迟低，是企业内部知识助手的最佳实践之一。详细步骤见项目文档中的doc_add_lark_group.md。

4.3 使用多模态检索（图片+文本）

如果你的知识库包含大量带有说明文字的截图、图表，启用多模态检索能极大提升答案准确性。

硬件准备：确保有至少 10GB 的 GPU 显存。

安装额外依赖：

pip install -r requirements/multimodal.txt

下载多模态模型权重：需要手动下载 BGE-M3 模型的视觉权重文件Visualized_m3.pth，并将其放入从 Hugging Face 下载的BAAI/bge-m3模型目录中。
修改配置：使用config-multimodal.ini作为基础配置，或将其中的关键参数合并到你的配置中。主要是修改嵌入模型路径：
```
embedding_model_path = "BAAI/bge-m3" reranker_model_path = "BAAI/bge-reranker-v2-minicpm-layerwise"
```
重建知识库：由于模型换了，需要重新运行python3 -m huixiangdou.services.store来生成包含视觉特征的新索引。
测试：运行python3 tests/test_query_gradio.py会启动一个测试界面，你可以同时上传图片和输入文字进行查询。

这个功能对于软件操作手册、产品图册等文档的问答效果提升非常明显。

5. 生产环境部署与性能优化

当你准备将茴香豆用于正式服务时，需要考虑以下几个关键点。

5.1 部署架构建议

对于轻量级应用，单机部署api_server可能就够了。但对于高并发或高可用的需求，建议采用以下架构：

[客户端] -> [负载均衡器 (Nginx)] -> [多个 HuixiangDou API 实例] -> [共享的向量数据库/知识库存储]

无状态服务：huixiangdou.api_server本身是无状态的。你可以水平部署多个实例，通过 Nginx 进行负载均衡。
共享存储：workdir（向量索引）和repodir（原始文档）应该放在共享存储（如 NFS、云存储）或分布式文件系统中，确保所有实例访问的数据一致。
LLM 服务分离：如果使用本地 LLM（如 vLLM），建议将 vLLM 服务单独部署在一台或多台 GPU 机器上，茴香豆实例通过网络调用。这样 LLM 资源可以独立扩缩容。

5.2 性能调优要点

检索速度：
- 索引类型：Faiss 支持多种索引（如IndexFlatIP,IndexIVFFlat）。对于百万级以下的向量，IndexFlatIP（精确搜索）即可。超过百万，考虑使用IndexIVFFlat（倒排文件，近似搜索）以牺牲少量精度换取大幅速度提升。可以在config.ini的[feature_store]部分配置faiss_index。
- 分块大小 (chunk_size)：默认可能是512字符。对于技术文档，适当调大（如768或1024）可以减少块数量，加快检索速度，但可能降低精度。需要根据文档平均长度和问题类型做权衡。
LLM 响应速度：
- 使用量化模型：如 GPTQ-Int4、AWQ 等，能在几乎不损失精度的情况下大幅减少显存占用和推理时间。
- 启用 vLLM 的 PagedAttention 和前缀缓存：这能极大优化长文本生成和并发请求下的吞吐量。启动 vLLM 时加上--enable-prefix-caching参数。
- 调整生成参数：在config.ini的[llm]部分，可以调整max_tokens（最大生成长度）、temperature（创造性，对于知识问答建议设低，如0.1）来平衡速度和质量。
内存与显存管理：
- 如果运行中出现 OOM（内存不足），首先检查是否是 LLM 模型过大。尝试使用更小的模型或更激进的量化。
- 对于检索部分，如果知识库非常大，Faiss 索引加载到内存会占用较多空间。确保服务器有足够的物理内存。
- 可以考虑使用lmdeploy等工具对 LLM 进行 KV-Cache 量化，进一步降低显存消耗。

5.3 监控与日志

生产环境必须要有监控。茴香豆的 API 服务日志会输出到控制台（或你重定向的文件）。你需要关注：

请求延迟：从接收到请求到返回答案的总时间。拆解为检索时间 + LLM 生成时间。
拒答率：统计被拒绝回答的问题比例，这有助于你调整拒答阈值和优化知识库。
错误率：API 调用失败、模型加载失败等的比例。
资源使用率：CPU、内存、GPU 显存的使用情况。

你可以使用 Prometheus + Grafana 来收集和展示这些指标。需要在茴香豆代码中添加相应的埋点，或者通过部署在容器中，利用 cAdvisor 来监控容器资源。

6. 常见问题排查与解决实录

在实际部署和运行中，你肯定会遇到各种问题。这里记录了几个最具代表性的案例和解决方法。

问题一：运行python3 -m huixiangdou.services.store时，报错ModuleNotFoundError: No module named 'faiss.swigfaiss_avx2'

现象：在构建知识库索引时，Faiss 导入失败。
原因：Faiss 的 Python 包名与内部模块名不一致，或者安装的版本与系统 CPU 指令集不兼容。
解决：
1. 首先定位 faiss 包的实际位置：在 Python 交互环境中执行import faiss; print(faiss.__file__)。
2. 进入该路径的父目录（通常是site-packages/faiss）。
3. 创建一个软链接：ln -s swigfaiss.py swigfaiss_avx2.py。这实际上是让程序在找swigfaiss_avx2模块时，能找到swigfaiss。
4. 如果问题依旧，可能是 Faiss 版本问题。尝试重新安装指定版本的faiss-gpu：pip install faiss-gpu==1.7.2 --no-cache-dir。

问题二：机器人回答所有问题，甚至包括明显无关的闲聊，完全不“拒答”。

现象：拒答机制似乎失效了。
原因：
1. reject_throttle阈值设置过低。
2. good_questions.json和bad_questions.json没有正确配置或未生效。
3. 知识库 (repodir) 中混入了大量通用文本（如小说、新闻），导致任何问题都能匹配到一些低相关性内容，但分数仍超过了阈值。
排查与解决：
1. 首先检查config.ini中的reject_throttle值。标准版初始化后一般在0.3-0.5之间。如果你希望机器人更“高冷”，尝试逐步提高到0.6或0.7。
2. 确保在运行services.store后，这两个 JSON 文件中的示例问题已被用于计算阈值。你可以打开workdir下的某个日志文件，搜索“reject throttle”查看计算出的值。
3. 清理你的知识库。只保留与机器人职能绝对相关的文档。无关的文档是噪声源。
4. 在bad_questions.json中，加入一些典型的闲聊或无关问题，例如“你好”、“在吗”、“讲个笑话”，并重新运行services.store。

问题三：使用本地 vLLM 服务时，茴香豆调用超时或无响应。

现象：茴香豆的 API 服务器日志显示连接 LLM 服务失败或超时。
原因：
1. vLLM 服务未成功启动或崩溃。
2. 网络端口不通或防火墙阻止。
3. config.ini中的remote_api_base配置错误。
4. vLLM 服务负载过高，处理不过来。
排查与解决：
1. 首先确认 vLLM 服务进程是否在运行：ps aux | grep vllm。检查其日志是否有错误。
2. 测试网络连通性：在茴香豆服务器上执行curl http://vllm-server:8000/health（如果 vLLM 服务在另一台机器，替换为正确的 IP 和端口）。应该返回一个 JSON 健康状态。
3. 核对config.ini中的remote_api_base，确保它指向正确的http://地址:端口/v1。尾部的/v1非常重要，因为这是 OpenAI 兼容接口的路径。
4. 监控 vLLM 服务的 GPU 显存使用情况。如果请求队列积压，考虑增加 vLLM 的--max-num-batched-tokens或--gpu-memory-utilization参数，或者部署更多 vLLM 实例。

问题四：知识库更新后，如何增量更新索引？

需求：日常运维中，知识库文档会增删改，不希望每次都全量重建索引（耗时）。
现状：截至我使用的版本，茴香豆的services.store命令默认是全量重建。它不会自动对比差异。
变通方案：
1. 定时全量重建：对于文档量不大（如几千个）的情况，可以设置一个每天的低峰期（如凌晨）进行全量重建。这是最稳妥的方案。
2. 手动管理：将知识库按模块划分，放在不同的子目录。当某个模块更新时，只删除workdir中对应的索引文件（索引文件名通常与源文件路径的哈希有关），然后重新运行services.store。但这种方法需要自己写脚本管理，比较麻烦。
3. 期待特性：增量更新是很多 RAG 系统的痛点。社区版可能在未来版本中支持。目前，全量重建仍是主流做法。在架构设计时，可以将workdir放在临时目录，重建完成后原子性地替换线上服务的索引文件，以实现无缝更新。

问题五：回答不够精准，经常“幻觉”出知识库中没有的内容。

现象：答案看起来合理，但仔细核对发现部分信息是 LLM 自己编造的。
原因：这是 LLM 的固有问题，但在 RAG 中可以缓解。
优化方向：
1. 加强检索：检查检索到的文本块是否真的与问题高度相关。可以尝试：
  - 使用更强大的嵌入模型（如bge-large-zh-v1.5）。
  - 启用重排序（Reranker）模型。茴香豆支持 BGE Reranker，它会对初步检索到的 Top K 个结果进行更精细的排序，将最相关的结果排到最前面。在config.ini中配置reranker_model_path。
  - 尝试混合检索，结合稠密检索和关键词检索的结果。
2. 优化 Prompt：茴香豆生成的 Prompt 模板在huixiangdou/service/llm_client.py等文件中。你可以微调模板，加入更严格的指令，例如“严格根据以下参考信息回答，如果参考信息中没有明确提及，请直接说‘根据现有资料无法回答该问题’”。在config.ini的[llm]部分，可能有prompt_template相关的配置项可以修改。
3. 后处理过滤：在 LLM 生成答案后，可以增加一个校验步骤，判断答案中的关键事实是否都能在检索到的参考片段中找到依据。如果没有，则触发拒答或返回一个保守的答案。这需要一定的开发工作。