Langchain-Chatchat与Thanos长期存储监控数据方案-开发者社区

Langchain-Chatchat 与 Thanos：构建安全智能问答与长期可观测性的融合架构

在企业智能化转型的浪潮中，如何在保障数据隐私的前提下实现知识高效利用，同时确保复杂 AI 系统具备长期可维护性，已成为技术落地的关键挑战。尤其是在金融、医疗、政务等对合规性要求极高的领域，任何将敏感信息上传至公网的行为都可能带来不可逆的风险。

与此同时，随着大语言模型（LLM）逐步进入生产环境，系统的“黑盒”特性也让运维团队面临前所未有的压力——我们不仅需要知道“回答是否正确”，更需要理解“为什么响应变慢了？”、“性能波动是否与某次模型更新有关？”这些问题的答案，依赖于持续、完整且可追溯的监控数据支撑。

正是在这种背景下，Langchain-Chatchat与Thanos 长期存储监控方案的结合，提供了一条兼顾“智能服务”与“智能运维”的可行路径：前者让私有文档在本地完成语义解析与智能问答，后者则为整个系统运行状态建立跨越数月甚至数年的观测窗口。

当知识库不再依赖云端：Langchain-Chatchat 如何重塑企业问答体验

传统基于云 API 的智能客服虽然部署快捷，但其本质是将企业的核心知识资产暴露在外。而 Langchain-Chatchat 正是从这一痛点出发，打造了一个真正意义上的本地化 RAG（检索增强生成）系统。

它的工作流程并不复杂，却极为精巧：

用户上传 PDF、Word 或 TXT 格式的内部制度文件；
系统使用 PyPDFLoader、Docx2txtLoader 等组件提取文本，并通过 RecursiveCharacterTextSplitter 按段落或句子切分，避免跨句断裂；
切片后的文本交由中文优化的嵌入模型（如 BGE-zh）转化为向量，存入 FAISS 或 Chroma 这类轻量级向量数据库；
当用户提问时，问题同样被向量化，在向量空间中搜索最相似的知识片段；
检索结果与原始问题拼接成 Prompt，送入本地运行的大模型（如 ChatGLM3、Llama3）生成自然语言回答。

整个过程无需联网，所有数据始终停留在企业内网之中。更重要的是，由于采用了 RAG 架构，模型的回答有据可依，显著降低了“幻觉”风险——这在处理薪酬政策、合同条款等高敏感内容时尤为重要。

from langchain.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 # 加载并分割文档 loader = PyPDFLoader("company_policy.pdf") pages = loader.load() text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) docs = text_splitter.split_documents(pages) # 向量化与存储 embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh") db = FAISS.from_documents(docs, embeddings) # 接入本地 LLM（建议使用 Ollama 或 vLLM 自托管） llm = HuggingFaceHub( repo_id="THUDM/chatglm3-6b", model_kwargs={"temperature": 0.7, "max_length": 512}, huggingfacehub_api_token="your_token" ) # 构建问答链 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=db.as_retriever(search_kwargs={"k": 3}), return_source_documents=True ) # 执行查询 result = qa_chain({"query": "年假可以分几次休？"}) print("回答:", result["result"])

这段代码看似简单，实则涵盖了 RAG 的全部核心环节。值得注意的是，为了彻底规避数据外泄风险，实际生产环境中应避免使用HuggingFaceHub这类远程调用方式，转而采用 Ollama、Text Generation Inference（TGI）或 vLLM 部署本地模型服务。

此外，项目对中文的支持也颇具匠心。不同于直接套用英文分词器的做法，Langchain-Chatchat 明确选用了适配中文语义的 BGE 模型和分块策略，使得诸如“绩效考核办法”这类长尾关键词也能被准确命中。

监控不能只看“最近15天”：为什么我们需要 Thanos？

当一个 Langchain-Chatchat 实例上线后，初期表现良好，响应迅速。但三个月后，用户开始抱怨“最近总是卡顿”。此时如果仅依赖原生 Prometheus，默认保留策略下历史数据早已被清除，根本无法回溯当时的系统负载情况。

这就是典型的“运维盲区”——没有长期数据，就谈不上根因分析。

Thanos 的出现，正是为了解决 Prometheus 在持久化方面的先天不足。它不像 Cortex 或 Mimir 那样完全重构存储层，而是采用一种“渐进式扩展”的思路：通过 Sidecar 模式附加在现有 Prometheus 实例上，将其时间序列数据定期上传至对象存储（如 MinIO、S3），从而实现近乎无限的数据保留能力。

其架构设计极具工程智慧：

Sidecar负责监听 Prometheus 的 TSDB 数据目录，每两小时打包一次 block 并上传；
Store Gateway从对象存储中读取历史数据块，供查询组件访问；
Query Layer提供统一的 PromQL 查询接口，自动聚合来自多个 Prometheus 实例和 Store Gateway 的数据；
Compactor对冷数据进行降采样（例如将 15s 原始数据聚合成 5m 平均值），大幅降低存储成本；
Ruler支持基于长期数据的规则评估与告警触发。

这意味着，即便某个 Prometheus 实例宕机，只要对象存储中的数据未丢失，历史指标依然可用。对于跨集群、多副本的 AI 服务部署场景而言，这种高可用性和全局视图能力尤为关键。

以下是 Kubernetes 中常见的 Thanos Sidecar 部署配置：

apiVersion: apps/v1 kind: Deployment metadata: name: prometheus-thanos-sidecar spec: replicas: 1 template: spec: containers: - name: prometheus image: prom/prometheus:v2.47.0 args: - '--config.file=/etc/prometheus/prometheus.yml' - '--storage.tsdb.path=/prometheus' volumeMounts: - name: storage mountPath: /prometheus - name: thanos-sidecar image: thanosio/thanos:v0.34.0 args: - 'sidecar' - '--prometheus.url=http://localhost:9090' - '--objstore.config-file=/etc/thanos/storage.yaml' - '--tsdb.path=/prometheus' - '--grpc-address=0.0.0.0:10901' ports: - containerPort: 10901 name: grpc volumeMounts: - name: storage mountPath: /prometheus - name: storage-config mountPath: /etc/thanos volumes: - name: storage emptyDir: {} - name: storage-config secret: secretName: thanos-storage-config

配套的对象存储配置（以 MinIO 为例）：

type: S3 config: bucket: "thanos-archive" endpoint: "minio.example.com:9000" access_key: "minioadmin" secret_key: "minioadmin" insecure: true

这套组合拳下来，原本只能保存两周的数据，现在可以轻松保留一年以上。而且得益于 Compactor 的压缩与降采样机制，长期存储的成本也被控制在合理范围内。

从“能用”到“好用”：真正的智能系统需要闭环反馈

当我们把 Langchain-Chatchat 和 Thanos 放在一起看待时，会发现它们共同构成了一个完整的 AI 应用生命周期管理闭环：

前端，用户通过 Web UI 或 API 提问，系统基于私有知识库返回答案；
后端，每一次请求的延迟、内存占用、向量检索耗时都被记录下来，经由 Prometheus 抓取后，由 Thanos 持久化归档。

这样的设计带来了三个层面的质变：

1. 数据主权掌握在自己手中

无论是员工手册、客户合同还是研发文档，都不再需要经过第三方 API。整个知识处理链条封闭运行，满足 GDPR、等保三级等合规要求。某些对信创有明确需求的企业，还可选用国产化替代方案，如用 QingStor 替代 S3，或使用华为云 OBS 存储监控数据。

2. 运维从“被动救火”转向“主动优化”

有了长达数月的监控数据，我们可以做很多以前做不到的事：

分析每日高峰时段的问答延迟趋势，判断是否需要扩容；
对比不同版本模型上线前后的资源消耗变化，评估性价比；
设置动态基线告警，比如“今日平均响应时间比过去七天高出 50%”，及时发现问题苗头。

甚至可以结合日志系统（如 Loki）和分布式追踪（如 Tempo），进一步下钻到具体请求链路，看清是向量检索慢了，还是 LLM 推理本身成了瓶颈。

3. 系统演进有了历史参照系

AI 系统的迭代往往伴随着不确定性。一次嵌入模型升级，可能导致某些类型的问题召回率下降；一次提示词调整，或许会让回答变得更流畅但也更啰嗦。如果没有长期数据对比，很难客观评价这些变更的实际影响。

而 Thanos 提供的时间机器功能，让我们能够精确回放任意时间段的系统状态，真正做到“变更可验证、效果可度量”。

工程实践中的几个关键考量

尽管整体架构清晰，但在落地过程中仍有一些细节值得推敲：

资源隔离：Langchain-Chatchat 属于计算密集型应用，尤其是 LLM 推理阶段会大量占用 GPU 和内存。建议将其与 Prometheus、Thanos 等监控组件部署在不同节点，避免相互干扰。
向量数据库可观测性：FAISS 或 Chroma 本身不暴露 Prometheus metrics，需自行封装中间件或使用代理层收集索引大小、查询延迟等关键指标。
冷热分离策略：近期数据保留在 SSD 上用于快速查询（热存储），超过 30 天的数据自动归档至低成本对象存储（冷存储），兼顾性能与成本。
安全性加固：对象存储应启用 TLS 加密传输，并通过 IAM 权限控制访问范围，防止未授权下载。若涉及跨境部署，还需考虑数据驻留合规问题。
国产化适配路径：除前述存储替代外，也可探索使用阿里云 ARMS、腾讯云 Observability 等国内 APM 方案作为补充，形成混合监控体系。