기능정의서의 RAG-001~RAG-022, NFR-07~NFR-12와
groupware-chat-backend-develop 레퍼런스 구조를 기준으로,
기존 사내검색 RAG 위에 평가 계층을 어떻게 얹을지 시각화한 문서다.
RAG-001~RAG-022NFR-07~NFR-12| 화면/메뉴 | 사용자에게 보여줄 내용 | 요구사항 근거 | 필요 데이터/API | 우선순위/구분 |
|---|---|---|---|---|
| 실시간 현황 Overview | 최근 5분/15분/1시간 평균 점수, 평가 건수, 실패 건수, 큐 적체, 평가 지연 p95, Judge 모델별 성공률을 한 화면에 표시한다. | RAG-010, NFR-07, NFR-12 |
ragas_evaluation, ragas_metric_score, queue status, worker heartbeat |
필수 요구사항 기반 |
| 기간 통계 Dashboard | 일/주/월별 평균, p5/p50/p95, 분포 histogram, 운영/Golden Set 모드 비교, Judge 모델별 비교, 이전 기간 대비 증감을 보여준다. | RAG-011, RAG-014, NFR-08 |
summary table, materialized view, 기간/모드/metric 필터 API | 필수 요구사항 기반 |
| 메트릭별 상세 | faithfulness, answer relevancy, context precision, context recall 각각의 평균, 실패율, not_applicable 비율, 입력 조건 누락 이유를 보여준다. |
RAG-002, RAG-003, RAG-004 |
metric registry, metric status, missing field reason, evaluation_type | 필수 요구사항 기반 |
| 케이스 드릴다운 | 질문, AI 응답, retrieved contexts top-K, 출처 문서, 각 metric score, Judge reasoning, 실패 로그, 재평가 버튼을 제공한다. | RAG-013, RAG-015, NFR-10 |
ragas_evaluation, ragas_payload, source metadata, permission check API |
필수 요구사항 기반 |
| 검색/필터 | 기간, 사용자/조직, 평가 모드, Judge 모델, metric, 점수 구간, 실패 원인, source type, batch id로 필터링한다. | RAG-014, RAG-021 |
dashboard query contract, cursor pagination, indexed columns | 필수 요구사항 기반 |
| Golden Set 관리 | 질문, 기준 답변, 기준 컨텍스트, 태그, 담당자, 상태를 CRUD하고 CSV/JSONL import, 수동 검수, batch 실행을 제공한다. | RAG-004, RAG-020, RAG-022 |
ragas_golden_set, ragas_golden_case, batch API, import validator |
필수 요구사항 기반 |
| 운영 샘플링 정책 | 운영/조직/모드별 샘플링 비율 0/10/50/100%, 제외 조건, 평가 대상 카테고리, 적용 이력을 설정한다. | RAG-006, NFR-12 |
sampling config, config history, enqueue decision log | 필수 요구사항 기반 |
| Judge LLM 설정 | Judge 모델, endpoint, temperature, timeout, retry, token/cost limit, 모델 변경 이력을 관리한다. | RAG-007, RAG-009 |
LiteLLM model config, encrypted secret reference, run config, audit log | 필수 요구사항 기반 |
| 알림 규칙 | metric 임계값, 기간 window, 적용 모드, cooldown, 수신 채널, 실패 시 3회 재시도 결과를 관리한다. | RAG-012, NFR-09 |
alert rule, alert event, delivery log, retry policy | 필수 요구사항 기반 |
| Export | 현재 필터 조건으로 CSV/JSON export, batch report export, metric summary export를 제공한다. payload 포함 여부는 권한으로 제어한다. | RAG-010, RAG-011, RAG-013, NFR-10 |
export job, signed download, payload permission scope | 필수 요구사항 기반 |
| 데이터소스 품질 | 게시판/문서/URL/source type별 평가 점수, 문서 수, chunk 수, 최근 crawl/embedding 상태, 검색 실패율을 보여준다. | RAG-015, RAG-016, RAG-017, RAG-018 |
OpenSearch metadata, crawler job/task, source_type normalization, embedding status | 필수 요구사항 기반 |
| Human Review Queue | 낮은 점수, Judge 실패, 사용자 negative feedback 케이스를 검수 큐로 모아 사람이 정답/컨텍스트/판정 사유를 보정한다. | RAG-019, RAG-020 |
review assignment, reviewer note, corrected reference, feedback link | 필수 요구사항 기반 |
| 저점 케이스 클러스터 | 낮은 점수 케이스를 질문 유형, source type, 부서, 검색된 문서, 실패 사유별로 묶어 “무엇을 고쳐야 하는지” 우선순위를 보여준다. | 요구사항 직접 명시는 없지만 RAG-011, RAG-013 분석 고도화 |
embedding/keyword clustering, failure reason taxonomy, grouped drilldown API | 추가 제안 토의 권장 |
| 릴리즈/모델 비교 | RAG 프롬프트, retrieval 파라미터, embedding 모델, Judge 모델 변경 전후 점수 변화를 비교한다. | A/B 비교 요구와 연결 가능: RAG-022, 기존 WBS의 A/B 언급 |
experiment id, config snapshot, before/after batch result | 추가 제안 토의 권장 |
| 비용/쿼터 모니터링 | Judge LLM 호출 수, token 사용량, 추정 비용, timeout/retry 비용, quota 소진 위험을 보여준다. | NFR-12 확장성과 운영 안정성 보강 |
LiteLLM usage log, worker retry log, model quota config | 추가 제안 운영 필수에 가까움 |
| 권한/마스킹 감사 | payload 조회 이력, 민감 정보 마스킹 여부, 권한 실패 로그, 조직별 접근 범위를 감사 로그로 제공한다. | NFR-10, payload 분리 저장 요구 보강 |
payload access audit, masking policy, permission denial log | 추가 제안 보안 토의 필요 |
| 데이터 드리프트/품질 추세 | 특정 게시판, 문서 유형, 시점 이후 context recall/faithfulness가 떨어지는지 추세와 원인을 표시한다. | RAG-011, RAG-017, RAG-018의 운영 분석 확장 |
time series summary, source freshness, embedding/crawl version | 추가 제안 2차 고도화 |
| 운영 상태 Timeline | 평가 job 생성, queue 대기, worker 실행, RAGAS 호출, Judge 호출, 저장, 알림까지 각 단계 소요 시간을 timeline으로 보여준다. | RAG-009, RAG-010, NFR-07 |
evaluation event log, worker span, retry event, alert delivery event | 추가 제안 장애 분석용 |
RAGAS Admin은 평가 실행 시스템이면서 운영 관측 화면이다.
따라서 화면 API는 list/summary/detail/config/action으로 분리하고,
목록 API에는 민감 payload를 싣지 않는다. payload는 상세 화면에서 권한 확인 후 별도 조회한다.
admin_embedding_router.py의 Admin API 패턴,
deep_research_json_router.py의 장기 작업 상태 패턴,
Redis 상태 캐시와 SQLAlchemy repository 패턴을 그대로 가져와 RAGAS 전용 service/router/repository만 추가한다.
| 구현 단위 | 어떤 식으로 구현 가능한가 | 고려해야 할 점 | 우선 적용 화면 |
|---|---|---|---|
| Read Model API | GET /admin/ragas/overview, /stats, /evaluations처럼 조회 전용 API를 먼저 만든다. summary table/materialized view를 읽어 대시보드 응답을 빠르게 만든다. |
100만 건 5초 요구 때문에 원장 테이블 직접 집계는 피하고, 시간 bucket별 사전 집계를 둔다. | 실시간 현황, 기간 통계, 검색/필터 |
| Detail Payload API | 목록에서는 점수/상태/메타만 보여주고, 상세 진입 시 GET /admin/ragas/evaluations/{id}/payload로 질의/응답/context를 별도 조회한다. |
NFR-10 때문에 payload 권한 확인, 조직 범위 체크, 마스킹, 조회 audit log가 필요하다. |
케이스 드릴다운, Export, 권한/마스킹 감사 |
| Config Versioning | 샘플링 정책, Judge LLM, 알림 규칙은 단순 update가 아니라 versioned config로 저장한다. 평가 row에는 실제 적용된 config version을 남긴다. | 나중에 점수 변화가 설정 변경 때문인지 검색/모델 변경 때문인지 추적하려면 snapshot이 필요하다. | 샘플링 정책, Judge 설정, 알림 규칙, 릴리즈/모델 비교 |
| Queue Action API | Golden Set batch 실행, 실패 job 재시도, 특정 케이스 재평가는 action API로 분리한다. 요청은 즉시 job id를 반환하고 상태는 polling/SSE로 조회한다. | 중복 실행 방지를 위해 idempotency key와 retry policy를 평가 job에 저장한다. | Golden Set 관리, 케이스 재평가, 운영 상태 Timeline |
| Metric Status 설계 | 점수 컬럼만 두지 말고 metric별 completed, failed, not_applicable, skipped 상태를 둔다. |
운영 트래픽에는 reference가 없으므로 context precision/recall을 무리하게 0점 처리하면 통계가 왜곡된다. | 메트릭별 상세, 기간 통계, 운영/Golden Set 비교 |
| Source Join Layer | internal_search_sources와 OpenSearch/crawler metadata를 정규화해 source type, 문서명, 게시판, chunk 수, embedding 상태를 연결한다. |
source id가 없는 검색 결과도 있을 수 있으므로 URL/title/hash 기반 fallback 매칭을 고려한다. | 데이터소스 품질, 케이스 드릴다운, 저점 케이스 클러스터 |
| Review Workflow | 낮은 점수/실패/사용자 피드백 케이스를 review queue로 만들고, 사람이 정답/컨텍스트/판정 메모를 보정하면 Golden Set 후보로 승격한다. | 검수 결과가 다시 평가 품질을 높이는 선순환이 되도록 review와 Golden Set을 분리하지 말고 연결한다. | Human Review Queue, Golden Set 관리 |
| Event Timeline | 평가 생성, queue 대기, worker 시작, RAGAS 호출, Judge 호출, 저장, 알림 발송을 event log로 남겨 timeline UI를 만든다. | 장애 분석과 p95 지연 원인 파악에 필요하다. 추가 제안이지만 운영 안정화 단계에서는 가치가 크다. | 운영 상태 Timeline, 실시간 현황, 알림 규칙 |
| 단계 | 먼저 만들 것 | 그 다음 확장 |
|---|---|---|
| 1차 MVP | overview, stats, evaluation list/detail, Golden Set CRUD/batch, sampling/Judge 설정, 기본 export | Human Review Queue와 데이터소스 품질 화면을 붙인다. |
| 운영 안정화 | alert rule, retry/cancel, queue lag, worker heartbeat, 비용/쿼터 모니터링 | 권한/마스킹 audit와 event timeline을 추가한다. |
| 분석 고도화 | 저점 케이스 클러스터, 릴리즈/모델 비교, source별 품질 추세 | 데이터 드리프트 탐지와 자동 개선 후보 추천으로 확장한다. |
| 영역 | 기존 레포 기준점 | 신규 구현 모듈 | 판단 |
|---|---|---|---|
| 채팅 응답 hook | ai_chat_json_router.py, message_model.py, internal_search_service.py |
RagasEvaluationService.enqueue_if_sampled() |
필수 |
| 평가 큐/상태 | deep_research_json_router.py, Redis 상태 캐시 패턴 |
ragas_queue_service.py, ragas_worker.py |
필수 |
| RAGAS 호출 | LiteLLM provider/config, dependency 관리 | RagasEvaluator, metric registry, RunConfig |
API 변화 대응 |
| 저장소 | SQLAlchemy model/repository 패턴 | ragas_evaluation, ragas_payload, ragas_metric_score |
필수 |
| Admin 화면/API | admin_embedding_router.py, embedding job/task UI 흐름 |
admin_ragas_router.py, dashboard/drilldown/export API |
필수 |
| 권한/마스킹 | JWT 사용자/조직 코드, 게시판 권한 메타 | payload 상세 조회 권한, source 권한 재검증 | 보안 위험 |
실제 사용자 응답에는 정답 문장이 없다. 따라서 faithfulness와
answer relevancy를 기본 지표로 삼고,
context precision/context recall은 입력 조건이 없는 경우
not_applicable로 저장한다.
질문, 기준 답변, 기준 컨텍스트가 있는 테스트셋에서는 4대 지표를 모두 계산한다. 이전 batch와 비교해 검색 품질 변화, 생성 품질 변화, 모델/Judge 설정 변경 영향을 추적한다.
ragas_evaluation
평가 원장. 상태, 평가 타입, 샘플링 정보, 평균 점수, 실패 사유, Judge 모델, 사용자/조직 메타를 저장한다.
ragas_payload
질의, 응답, retrieved contexts, source metadata, Judge reasoning 같은 민감 payload를 분리 저장한다.
ragas_metric_score
metric별 score, status, reason, token/cost/latency를 저장해 통계와 드릴다운을 동시에 지원한다.
summary view
100만 건 기준 기간 통계 5초 요구를 맞추기 위해 시간/모드/메트릭 단위 집계 테이블 또는 materialized view를 둔다.
평가 원장, payload, metric score, batch, 설정 테이블과 migration을 만든다.
채팅 응답 저장 후 샘플링 정책에 따라 평가 job을 생성한다.
RAGAS API 변화를 격리하는 adapter와 timeout/retry/cancel 정책을 구현한다.
실시간 현황, 기간 통계, 케이스 드릴다운, Export API를 붙인다.
테스트셋 import, batch 실행, 임계값 알림, 운영 리포트를 완성한다.
evaluate()/aevaluate() deprecated 흐름이 있어 직접 호출을 흩뿌리지 말고 adapter 안에 숨겨야 한다.
운영 샘플에 context precision/recall을 강제로 계산하면 잘못된 지표가 된다. metric status를 분리해야 한다.
질문/응답/context에는 민감 정보가 들어갈 수 있다. 목록 API와 상세 payload API를 분리하고 권한을 재검증해야 한다.