Langchain-Chatchat Prometheus指标采集问答系统

Langchain-Chatchat Prometheus指标采集问答系统

在企业知识管理日益智能化的今天，如何让员工快速获取散落在PDF、Word和内部文档中的信息，同时确保敏感数据不外泄？这已成为金融、医疗、政务等行业面临的共性挑战。传统的搜索引擎无法理解语义，而公有云AI服务又存在合规风险——正是在这种背景下，“本地化+可监控”的智能问答系统逐渐成为刚需。

Langchain-Chatchat 正是为解决这一矛盾而生的开源方案。它不仅能让大模型读懂你的私有文档，还能通过集成 Prometheus 实现全过程可观测，真正做到了“既安全，又可控”。这套组合拳背后的技术逻辑究竟是怎样的？我们不妨从一个实际场景切入：当用户在Web界面输入“年假怎么申请？”时，系统内部到底发生了什么？

整个流程始于文档的解析与向量化。用户上传的企业制度文件（如PDF或DOCX）首先被加载器提取成纯文本。这里用到的是PyPDF2或python-docx这类专用解析工具，它们能有效去除页眉页脚等干扰内容。随后，文本按语义边界切分为200~500字符的片段（chunk），每个片段再经由本地部署的嵌入模型（如BGE或text2vec）转换为高维向量。这些向量最终存入 FAISS 或 Chroma 等向量数据库，形成可检索的知识索引。

from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS # 1. 加载PDF文档 loader = PyPDFLoader("company_policy.pdf") pages = loader.load() # 2. 文本分块 text_splitter = RecursiveCharacterTextSplitter(chunk_size=300, chunk_overlap=50) docs = text_splitter.split_documents(pages) # 3. 初始化本地嵌入模型 embedding_model = HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh-v1.5") # 4. 构建向量数据库 vectorstore = FAISS.from_documents(docs, embedding_model) # 5. 相似性检索示例 query = "年假如何申请？" retrieved_docs = vectorstore.similarity_search(query, k=2) for i, doc in enumerate(retrieved_docs): print(f"【片段{i+1}】\n{doc.page_content}\n")

当问题提交后，系统会将查询语句同样编码为向量，并在向量空间中进行近似最近邻搜索（ANN），找出最相关的几个文档片段。这些片段作为上下文拼接到提示词中，送入本地运行的大语言模型（如ChatGLM3或Qwen）生成自然语言回答。整个过程无需联网，所有计算均发生在内网服务器上，从根本上杜绝了数据泄露的可能性。

但仅仅“能答”还不够。在真实生产环境中，运维人员更关心的是：“这个回答花了多久？”、“最近是不是请求变多了？”、“有没有出现异常错误？”——这就引出了系统的另一大核心能力：可观测性。

为此，Langchain-Chatchat 的后端服务通常基于 FastAPI 或 Flask 构建，并通过prometheus_client库暴露/metrics接口。Prometheus 定期拉取这些指标，记录下每一次请求的耗时、总数和状态。比如下面这段代码就定义了两个关键指标：

from prometheus_client import Counter, Histogram, generate_latest, REGISTRY from flask import Flask, Response import time # 定义指标 REQUEST_COUNT = Counter( 'chatbot_requests_total', 'Total number of chatbot requests', ['method', 'endpoint'] ) REQUEST_DURATION = Histogram( 'chatbot_request_duration_seconds', 'Chatbot request latency', ['endpoint'], buckets=(0.1, 0.5, 1.0, 2.0, 5.0) ) app = Flask(__name__) @app.route("/query", methods=["POST"]) def query(): REQUEST_COUNT.labels(method="POST", endpoint="/query").inc() with REQUEST_DURATION.labels(endpoint="/query").time(): # 模拟问答处理逻辑 time.sleep(0.8) # 替换为真实LLM调用 return {"answer": "这是一个测试回答。"} @app.route("/metrics") def metrics(): return Response(generate_latest(REGISTRY), mimetype="text/plain") if __name__ == "__main__": app.run(port=8000)

这里的Counter类型用于累计请求数，适合统计总访问量；而Histogram则记录响应时间的分布情况，帮助识别慢查询。一旦配置完成，Prometheus 就能以固定间隔（默认15秒）主动抓取这些数据，存储到其内置的时间序列数据库中。结合 Grafana，你可以轻松绘制出QPS趋势图、P95延迟曲线甚至错误率告警面板。

这种架构的优势在于轻量且标准。相比Zabbix这类传统监控工具，Prometheus采用Pull模式，服务端无需主动推送数据，降低了系统耦合度。它的数据模型专为时序设计，查询语言 PromQL 强大灵活，例如要查看过去5分钟平均响应时间超过1秒的请求比例，只需一条表达式：

rate(chatbot_request_duration_seconds_sum[5m]) / rate(chatbot_request_duration_seconds_count[5m]) > 1

更重要的是，这套监控机制并非事后补救，而是从工程设计之初就融入其中。你在调试阶段就能发现：到底是向量检索拖慢了整体性能，还是LLM推理本身成了瓶颈？如果是前者，可能需要优化chunk大小或更换索引算法；如果是后者，则应考虑模型量化或增加GPU资源。

典型的部署结构通常是这样的：

+------------------+ +----------------------------+ | 用户终端 |<----->| Web UI (Gradio/Streamlit) | +------------------+ +------------+---------------+ | v +----------------------------+ | FastAPI 后端服务 | | - 处理问答请求 | | - 调用LangChain流水线 | | - 暴露/metrics接口 | +------------+---------------+ | v +--------------------------------------------------+ | 本地运行组件 | | - Embedding Model (e.g., BGE) | | - Vector Store (e.g., FAISS) | | - LLM (e.g., Qwen, ChatGLM3) | +--------------------------------------------------+ | v +--------------------------+ | Prometheus Server | | - 定时抓取/metrics | | - 存储指标 & 执行告警规则 | +------------+-------------+ | v +---------------------+ | Grafana 可视化平台 | | - 展示QPS、延迟、错误率 | +---------------------+

该体系支持 Docker Compose 快速启动，也可纳入 Kubernetes 编排实现自动扩缩容。对于企业而言，这意味着不仅能快速上线，还能长期稳定运行。

当然，在落地过程中也有一些值得注意的经验点。比如chunk size的设定就很讲究：太小会导致上下文断裂，影响答案完整性；太大则容易引入噪声，降低检索精度。建议初始值设为300字符左右，再根据测试反馈微调。再比如嵌入模型的选择，中文场景下优先使用 BGE 或 text2vec 这类专门优化过的模型，避免直接套用英文通用模型导致语义偏差。

另一个常被忽视的问题是向量库持久化。FAISS 默认将索引加载在内存中，服务重启即丢失。因此必须配置定期导出机制，否则每次都要重新建库，极大影响可用性。此外，由于LLM推理资源消耗大，建议加入限流策略（Rate Limiter），防止突发流量导致OOM崩溃。

从更广的视角看，Langchain-Chatchat 配合 Prometheus 的价值远不止于技术实现。它实际上代表了一种“AI工程化”的思维转变——不再把大模型当作黑盒玩具，而是像对待任何关键业务系统一样，去衡量它的稳定性、性能和成本。

目前这套方案已在多个领域落地见效：
- 在企业内部构建知识中枢，替代低效的关键词搜索，实现“一句话查全章”；
- 作为客服辅助系统，帮助坐席实时调取产品手册和历史工单；
- 在教育培训平台中充当个性化学习助手，解答学员疑问；
- 政府机构利用其离线特性，提供政策法规咨询服务而不触碰外网。

未来随着小型化LLM和边缘计算的发展，这类本地智能系统将更加普及。而 Prometheus 所提供的可观测性能力，将成为判断一个AI系统是否“可用、可靠、可管”的重要标尺。

掌握这套组合技能，不仅是搭建一个问答机器人那么简单，更是通向 AI 工程化实践的关键一步。当你的模型不仅能回答问题，还能告诉你“它答得怎么样”，才算真正具备了投入生产的底气。