Коротко. RAG-пайплайн — это последовательность компонентов: эмбеддинг-сервис, vector DB, retriever и LLM-API документацию. Сбой или замедление любого этапа проверку портов ответы. мониторинг сайтов RAG сводится к проверке доступности каждого компонента по HTTP, контролю латентности этапов и heartbeat фоновой индексации. enterno.io даёт внешний availability-слой из РФ, ЕС и США, не заменяя eval качества выдачи.
Компоненты RAG, которые отказывают
В типовом RAG отказать может каждый этап:
- Эмбеддинг-сервис — недоступен или медленный;
- Vector DB (Qdrant, Weaviate, pgvector и др.) — упала или деградирует по латентности;
- Retriever / API поиска — возвращает ошибки или пусто;
- LLM-API — 429/5xx, рост времени ответа;
- Индексация — фоновый процесс перестал обновлять базу.
Три слоя мониторинга RAG
- Доступность компонентов — HTTP health-проверки каждого сервиса.
- Латентность этапов — где именно теряется время.
- Свежесть индекса — heartbeat фоновой индексации.
Самая коварная проблема RAG — не падение, а тихая деградация: vector DB отвечает, но медленно, и пользователь получает ответ с задержкой или по устаревшим документам.
| Компонент | Типовой отказ | Чем мониторить |
|---|---|---|
| Эмбеддинг-сервис | Недоступен или медленный | HTTP-монитор |
| Vector DB | Падение, рост латентности | HTTP-монитор + латентность |
| Retriever / API поиска | Ошибки или пустая выдача | HTTP-монитор |
| LLM-API | 429/5xx, медленный ответ | HTTP-монитор |
| Индексация | Не обновила базу вовремя | Heartbeat |
Health-check компонентов
Заведите проверку каждого критичного сервиса пайплайна:
# Vector DB
curl -o /dev/null -s -w "vectordb %{http_code} %{time_total}s\n" \
https://vectordb.internal.example.com/healthz
# Retriever / API поиска
curl -o /dev/null -s -w "retriever %{http_code} %{time_total}s\n" \
https://retriever.example.com/health
# LLM-API
curl -o /dev/null -s -w "llm %{http_code} %{time_total}s\n" \
https://api.example-llm.com/v1/healthКаждую проверку добавьте в enterno.io как отдельный HTTP-монитор — так вы сразу видите, какой компонент уронил пайплайн.
Heartbeat для индексации
Фоновая переиндексация должна сигналить о завершении. Пусть джоба пингует heartbeat после успешного обновления:
# После успешной переиндексации
curl -fsS https://enterno.io/api/heartbeat/INDEX_TOKEN \
-o /dev/null && echo "index heartbeat sent"Если индексация не отработала вовремя, вы узнаете об устаревшем индексе раньше, чем пользователи начнут получать неактуальные ответы.
Что мониторить помимо доступности
- Латентность по этапам — отдельные мониторы на retriever и LLM-API.
- SSL и DNS внешних сервисов пайплайна.
- Стоимость — токены LLM на генерацию ответа (логируйте в своём трейсинге).
Граница: availability, а не качество
Будем честны: enterno.io не оценивает релевантность retrieval и не считает метрики качества RAG (precision/recall выдачи, faithfulness). Для этого нужны eval-инструменты. enterno.io отвечает на вопрос «жив ли каждый компонент пайплайна и как быстро отвечает» — и это тот слой, который чаще всего и ломает прод.
FAQ
enterno.io оценивает качество retrieval?
Нет, это задача eval-инструментов. enterno.io покрывает доступность и латентность компонентов плюс heartbeat индексации.
Как понять, какой этап тормозит?
Заведите отдельный монитор на каждый сервис и сравнивайте латентность — узкое место станет очевидным.
Что с устаревшим индексом?
Heartbeat фоновой индексации: алерт, если переиндексация не прошла в окне.
Можно ли мониторить из РФ?
Да, проверки доступны из ru-msk, на платных тарифах добавляются ЕС и США.
Накройте пайплайн мониторингом: заведите HTTP-проверки компонентов на странице мониторов и подключите heartbeat для индексации.
По теме: мониторинг AI/LLM-API, инструменты мониторинга API, мультирегион.