RAG Pipeline for SRE Runbooks: 7 Vector Search Tips That Work

개요

SRE(Site Reliability Engineering) 런북(Runbook)을 위한 RAG(Retrieval-Augmented Generation) 파이프라인은 임베딩 모델 선택, 인덱스 구조, 데이터 수집 방식, 검색 품질을 모두 충족해야 프로덕션 환경에서 효과적으로 작동합니다.

주요 내용

* 적합한 임베딩 모델 선택: SRE 전문 용어(OOMKilled, CrashLoopBackOff 등)를 이해하는 도메인 특화 임베딩 모델이 중요합니다. BAAI/bge-small-en-v1.5 모델은 384차원 벡터를 생성하고, 처리 속도가 빠르며 기술적 문맥을 더 잘 처리합니다. OpenAI의 ada-002 모델 사용 시 Qdrant 컬렉션 설정에서 Dot 거리를 사용해야 합니다.
* 런북 내용 기반 청킹: 고정된 토큰 수로 분할하기보다 절차적 단계 경계를 존중하는 청킹이 필요합니다. 512토큰 청크와 64토큰 오버랩을 시작점으로 사용합니다.
* 사고 분류 체계 기반 벡터 스토어 인덱싱: alert_name, service, severity, on_call_team, last_updated와 같은 구조화된 메타데이터 필터링을 통해 관련 없는 결과를 약 60% 줄일 수 있습니다. last_updated 필드는 오래된 런북에 대한 경고를 제공합니다. Qdrant는 네이티브 sparse+dense 하이브리드 검색을 지원하며, Weaviate는 빌트인 generative-openai 모듈을 제공합니다. Qdrant 사용 시에는 인증 설정(QDRANT_SERVICE_API_KEY) 및 비공개 서브넷 활용이 중요합니다.
* Confluence 또는 Git 기반 경량화 파이프라인으로 런북 수집: 해시 기반 변경 감지로 벡터 스토어를 최신 상태로 유지합니다. Git에서는 docs/runbooks/{service}/{alert_name}.md 경로 규칙을 사용하고, Confluence는 REST API 또는 LangChain의 ConfluenceLoader를 활용할 수 있습니다. Redis를 사용하여 문서의 SHA256 해시를 저장하고 변경 사항을 감지합니다.
* 알림 워크플로우에 RAG 쿼리 연동: Alertmanager 또는 PagerDuty 웹훅을 통해 알림이 발생하면 alertname을 쿼리 문자열로 사용하여 RAG 엔드포인트에 요청합니다. PagerDuty 웹훅 v3에서는 event.data.title을 incident 이름으로 매핑해야 합니다. 유사도 점수 임계값 0.78을 설정하고, 이보다 낮으면 "matched": false 신호를 반환하여 잘못된 런북을 제공하는 것을 방지합니다. 최대 3개의 청크를 반환합니다.
* 프로덕션 환경 적용 전 검색 품질 평가: LLM의 답변 정확성보다 검색된 청크가 올바른 런북 섹션인지 평가하는 것이 중요합니다. (alert_name, expected_runbook_section) 쌍으로 구성된 골든 데이터셋을 구축하고 recall@3 지표를 확인합니다. ragas 라이브러리를 사용하여 context_recall 및 answer_relevancy 메트릭을 측정할 수 있습니다.
* 파이프라인 보안 강화: 벡터 스토어에는 민감한 운영 정보가 포함될 수 있으므로 접근 제어를 강화해야 합니다. Qdrant의 컬렉션별 API 키 또는 Weaviate의 RBAC를 사용하고, RAG 쿼리 엔드포인트를 인증 없이 외부에 노출하지 않습니다. Redis 임베딩 캐시도 보호하고, last_updated 메타데이터 필드를 포함하여 오래된 런북에 대한 경고를 제공합니다.
* 캐싱 및 재색인 빈도 조절을 통한 비용 통제: Redis 임베딩 캐시는 동일한 청크 콘텐츠의 재임베딩 비용을 줄여줍니다. 전체 재색인은 주간 단위로, 변경된 문서에 대한 점진적 재색인은 메인 브랜치 병합 시점에 수행하여 비용을 절감합니다. Qdrant 배치 업서트 시 HTTP 대신 gRPC를 사용하면 지연 시간을 30% 줄일 수 있습니다.

시사점

SRE 런북 RAG 파이프라인 구축 시 기술적인 측면 외에도 데이터의 신선도, 보안, 비용 효율성, 그리고 무엇보다 엔지니어의 실질적인 온콜(on-call) 경험 개선을 위한 지속적인 평가와 개선이 필수적입니다.