Langchain-Chatchat与Thanos长期存储监控数据方案

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

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

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

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

---

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

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

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

1. 用户上传 PDF、Word 或 TXT 格式的内部制度文件；
2. 系统使用 PyPDFLoader、Docx2txtLoader 等组件提取文本，并通过 RecursiveCharacterTextSplitter 按段落或句子切分，避免跨句断裂；
3. 切片后的文本交由中文优化的嵌入模型（如 BGE-zh）转化为向量，存入 FAISS 或 Chroma 这类轻量级向量数据库；
4. 当用户提问时，问题同样被向量化，在向量空间中搜索最相似的知识片段；
5. 检索结果与原始问题拼接成 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 方案作为补充，形成混合监控体系。

---

结语：智能不止于“会说话”，更在于“可治理”

Langchain-Chatchat 让企业拥有了一个懂业务、守秘密的“数字员工”；而 Thanos 则赋予这个员工一张完整的“体检报告”。两者结合，不只是技术组件的简单叠加，更是理念上的契合——真正的智能系统，不仅要能输出答案，更要能解释自己为何这样回答，以及在过去的表现如何。

未来，随着更多 CNCF 生态工具的融入，比如用 Loki 统一采集日志、用 Tempo 实现全链路追踪，这套架构有望演化为面向 AI 应用的一体化 AIOps 平台。届时，我们将不再仅仅构建“能跑起来”的模型服务，而是打造出真正稳定、可信、可持续演进的企业级智能中枢。

这条路很长，但从第一步开始，方向已经清晰。