Langchain-Chatchat用药指南查询：患者安全用药科普平台

在医院药房窗口前，一位老年患者反复询问护士：“这个药饭前吃还是饭后吃？会不会和我正在吃的降压药冲突？”类似场景每天都在上演。面对厚重的药品说明书、晦涩的专业术语，以及有限的药师资源，患者的用药困惑往往得不到及时解答。更令人担忧的是，一些人转而求助于公共AI助手或搜索引擎——输入“阿司匹林能和布洛芬一起吃吗”，得到的回答可能来自未经验证的网络内容，甚至被用于模型训练。

这正是当前医疗信息传递中的典型困境：知识权威但难获取，服务迫切但缺人力，数据敏感却常外泄。有没有一种方式，既能利用大模型的语言理解能力，又能确保回答基于真实文档、全程不离本地？

答案是肯定的。近年来，随着 RAG（检索增强生成）技术与本地化部署方案的成熟，像 Langchain-Chatchat 这样的开源系统正为高合规性行业提供全新的解题思路。它不是一个简单的聊天机器人，而是一套完整的私有知识服务体系，尤其适用于构建“患者用药指南查询”这类对准确性与隐私要求极高的应用场景。

我们不妨从一个实际案例切入：假设某三甲医院希望为门诊患者提供自助式用药咨询服务。他们拥有大量官方发布的《处方药说明书》《临床诊疗指南》PDF 文件，内容权威但查阅不便。传统做法是安排药师轮值答疑，效率低且成本高；若采用通用大模型，则存在幻觉风险和数据泄露隐患。

Langchain-Chatchat 的出现改变了这一局面。它的核心逻辑很清晰：让大模型只负责“说话”，不让它“编故事”。所有回答都必须基于预先导入的真实文档片段。整个流程可以拆解为两个阶段——“准备”和“问答”。

在“准备”阶段，系统会扫描指定目录下的 PDF、Word 等文件，使用如 pdfplumber 或 pymupdf 工具提取文本，并进行清洗（去除页眉页脚、广告语等干扰项）。接着，通过 RecursiveCharacterTextSplitter 将长文档切分为 500~800 字符的小块，既避免超出模型上下文限制，又尽可能保留语义完整性。每个文本块随后被送入中文嵌入模型（如 text2vec-base-chinese 或 m3e-base），转化为高维向量并存入 FAISS 向量数据库。这个过程就像给每一段专业知识贴上“语义标签”，以便后续快速匹配。

当患者开始提问时，系统进入“问答”阶段。用户问题同样被编码为向量，在 FAISS 中执行近似最近邻搜索，找出 Top-K（通常为3）最相关的知识片段。这些片段与原始问题拼接成 Prompt，传入本地部署的大语言模型（如 ChatGLM3-6B 或 Qwen-7B）。模型的任务不再是凭空生成答案，而是根据提供的上下文进行归纳总结。最终输出不仅包含回答，还会标注来源页码或文档名称，实现“有据可查”。

这种架构本质上是一种“双保险”机制：
一方面，向量检索确保了答案的知识边界——模型只能看到数据库中存在的内容；
另一方面，本地运行杜绝了数据出境风险——无论是患者的提问记录，还是医院内部的用药规范，始终停留在内网服务器中。

from langchain_community.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import HuggingFaceEmbeddings
from langchain.vectorstores import FAISS
from langchain.chains import RetrievalQA
from langchain.llms import HuggingFaceHub

# 1. 加载用药说明书PDF
loader = PyPDFLoader("metformin_pi.pdf")
pages = loader.load()

# 2. 分割文本为小块
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
docs = splitter.split_documents(pages)

# 3. 使用本地Hugging Face模型生成嵌入
embeddings = HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2")

# 4. 构建本地向量数据库
db = FAISS.from_documents(docs, embeddings)

# 5. 创建检索器
retriever = db.as_retriever(search_kwargs={"k": 3})

# 6. 初始化本地LLM（例如ChatGLM3）
llm = HuggingFaceHub(
    repo_id="THUDM/chatglm3-6b",
    model_kwargs={"temperature": 0.2, "max_new_tokens": 512},
    huggingfacehub_api_token="your_token"
)

# 7. 构建检索增强问答链
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=retriever,
    return_source_documents=True
)

# 8. 查询示例
query = "二甲双胍每天最多能吃多少？饭前还是饭后服用？"
response = qa_chain.invoke(query)
print(response["result"])

这段代码看似简单，实则涵盖了整个 RAG 流程的关键组件。值得注意的是，虽然示例中调用了 HuggingFaceHub，但在实际医疗部署中，更多采用完全离线的方式加载本地模型路径，进一步切断对外依赖。这也是为什么 Chatchat 项目特别受欢迎的原因之一——它将 LangChain 的复杂配置封装成了可视化的 Web 管理后台。

Chatchat 原名 Langchain-ChatGLM，现已发展为独立的开源生态。其最大优势在于“开箱即用”：无需编写代码，管理员可通过图形界面完成知识库上传、索引重建、模型切换、参数调节等操作。系统基于 FastAPI 提供 RESTful 接口，支持异步任务队列处理大文件解析，前端则兼容 React 或 Streamlit 构建的交互页面。这意味着即使是非技术人员，也能在几小时内搭建起一个功能完整的私有问答机器人。

更为关键的是，Chatchat 实现了全链路本地化。以下是其典型部署架构：

+------------------+       +-----------------------+
|   患者终端        |<----->|   Chatchat Web 前端    |
| (手机/自助机)     | HTTP  | (React + Streamlit)   |
+------------------+       +-----------+-----------+
                                       |
                                       | API 调用
                                       v
                       +-------------------------------+
                       |     Chatchat 后端服务          |
                       | (FastAPI + LangChain Core)    |
                       +-------------------------------+
                                       |
                    +------------------+------------------+
                    |                                     |
                    v                                     v
      +--------------------------+         +----------------------------+
      | 本地向量数据库 (FAISS)     |         | 本地大模型 (ChatGLM3-6B)   |
      | - 存储药品说明书向量化结果 |         | - 接收Prompt并生成回答     |
      +--------------------------+         +----------------------------+
                    ^
                    |
          +---------------------+
          | 文档预处理流水线       |
          | - PDF解析             |
          | - 文本清洗与分块       |
          | - 向量化并存入FAISS    |
          +---------------------+

在这个体系中，每一个环节都可以按需优化。比如，在文本预处理阶段，建议优先使用 pdfplumber 替代默认的 PyPDF2，因为它能更好处理表格和复杂排版；对于中文医疗文本，Embedding 模型应选择专为中文训练的 text2vec 或 m3e 系列，而非英文通用模型，否则会导致语义偏差。

硬件方面，推荐配置如下：
- CPU：至少 8 核以上，用于文档解析与检索调度；
- GPU：NVIDIA T4 / RTX 3090 及以上，显存 ≥ 16GB，支持 INT4 量化推理以降低资源消耗；
- 内存：≥ 32GB RAM；
- 存储：SSD ≥ 1TB，用于存放模型权重与不断增长的知识库。

安全性也不容忽视。生产环境中应启用 JWT 认证保护 API 接口，关闭 Web 界面的调试模式，定期备份原始文档与向量数据库。此外，可开启日志审计功能，追踪每一次查询请求，满足医疗行业的合规审查需求。

对比传统方案，Langchain-Chatchat 的优势一目了然：

这套系统带来的不仅是技术升级，更是服务模式的转变。过去，患者需要主动寻找药师；现在，只需在自助机上打字提问，就能获得标准化、可追溯的答案。这对于提升用药依从性、减少医患沟通误差具有重要意义。

更重要的是，这种模式具备很强的扩展性。除了用药指南查询，还可延伸至慢性病管理提醒、药品不良反应预警、医保报销政策解读等多个子系统。一家药店部署后，甚至可以根据会员档案推送个性化用药建议（仍保持本地计算，不上传个人信息）。

长远来看，Langchain-Chatchat 所代表的“私有知识 + 大模型 + 本地推理”范式，正在成为 AI 落地垂直领域的主流路径。它不再追求“全能型”AI，而是强调“专业级”服务能力。正如一位医院信息科负责人所说：“我们不需要一个知道全世界的机器人，我们需要一个只懂我们医院规则、永远不开小差的助手。”

这样的系统，或许才是人工智能真正服务于人的样子——不炫技，不越界，安静地站在背后，把正确的知识，交给需要的人。