如何使用 Prometheus 监控 RAG 系统的检索耗时指标

在 RAG 应用代码中集成 Prometheus 客户端库，针对检索环节埋点记录耗时直方图，适合自部署检索服务场景。注意埋点逻辑本身会引入微小开销，避免在高频循环中创建新指标对象。

先说结论：通过代码埋点暴露检索耗时直方图，配合 PromQL 计算分位值监控。

先定位：明确检索链路包含 Embedding 生成、向量数据库查询、重排序三个阶段。
先做：使用 Prometheus 客户端库在代码中定义 Histogram 指标并包裹检索逻辑。
再验证：通过 PromQL 查询 p95 延迟确认指标采集正常。

命令速用版

监控依赖代码埋点而非 shell 命令，以下是 Python 示例核心片段：

from prometheus_client import Histogram, start_http_server
import time

RETRIEVAL_LATENCY = Histogram('rag_retrieval_duration_seconds', 'RAG retrieval latency')

@RETRIEVAL_LATENCY.time()
def retrieve_documents(query):
    # 执行检索逻辑
    return docs

start_http_server(8000)

为什么会这样

Prometheus 适合记录时序化的性能指标，RAG 检索耗时属于业务逻辑耗时，必须在应用层埋点。

向量数据库自带的监控通常只覆盖数据库内部查询，无法包含网络传输和 Embedding 计算时间。只有在应用代码中记录从发起检索到拿到结果的完整耗时，才能反映用户感知的延迟。

分步处理

安装客户端库：根据开发语言安装 Prometheus 客户端，例如 Python 使用pip install prometheus-client。
定义指标：创建 Histogram 类型指标，bucket 范围建议覆盖 0.1 秒到 5 秒区间。
包裹逻辑：使用装饰器或手动计时器包裹检索函数，确保异常抛出时也能记录耗时或错误计数。
暴露端点：启动 HTTP 服务器暴露/metrics路径，确保 Prometheus 服务器网络可达。
配置抓取：在 Prometheus 配置文件的scrape_configs中添加 RAG 服务地址。

怎么验证是否生效

访问服务 IP 的 8000 端口/metrics路径，确认存在rag_retrieval_duration_seconds指标。

在 Prometheus UI 输入查询语句histogram_quantile(0.95, rate(rag_retrieval_duration_seconds_bucket[5m]))，确认能返回数值而非空值。

常见坑

标签基数爆炸：不要在指标标签中加入用户 ID 或查询文本，会导致内存激增。
异步支持：异步框架需使用异步客户端库，否则阻塞事件循环。
错误统计：仅记录成功耗时会导致监控失真，需配合 Counter 指标记录检索失败次数。

常见问题

如何区分 Embedding 和向量查询耗时？

需要定义两个独立的 Histogram 指标分别埋点。

使用托管向量数据库如何监控？

托管服务通常提供自带监控面板，应用层仍需记录 SDK 调用耗时。

参考来源

Prometheus Official Documentation, Client Libraries, https://prometheus.io/docs/instrumenting/clientlibs/
Prometheus Official Documentation, Instrumenting HTTP services, https://prometheus.io/docs/instrumenting/writing_clientlibs/#http-servers-and-request-handlers