[면접 복기] RAG/LLM 품질 관리·테스트 중심 질문 정리 (서울 영커리언스)
0. 한 줄 요약
이번 면접은 RAG 기반 LLM의 품질을 “운영 관점에서 어떻게 측정·기록·개선할 수 있는지”와
LLM의 비결정성(같은 질문인데 결과가 달라짐)을 어떻게 설명하고 통제할지,
그리고 테스트셋(특히 LLM이 생성한 데이터)의 신뢰성을 어떻게 바라보는지에 초점이 있었습니다.
1. 질문 목록(기억 정리)
- 1분 자기소개
- RAG 품질을 관리하기 위해 관리자가 확인·기록해야 하는 것은?
- RAG+LLM 시나리오 16가지(일부 조건 조합) 중 “올-굿”을 제외한 15가지 중 하나 선택 →
(a) 현실 사례 가정 (b) 선택 이유 (c) 해결 방안 제시 - 일정 시간 간격으로 동일 질문을 했을 때 결과가 달라지는 현상의 원인(1~2개, 깊게)
- LLM Agent 테스트를 위해 LLM이 만든 테스트셋을 써도 되는가? 의견 제시
2. Q1) 1분 자기소개 — “역량의 증거”를 3문장으로
질문 의도
- 커뮤니케이션, 압축 능력, 그리고 “이 포지션에서 바로 쓸 수 있는 경험”을 확인
답변 프레임(권장)
- (현재) 나는 어떤 사람/역할인가
- (근거) RAG/LLM/품질/평가에 연결되는 경험 1~2개(수치/성과가 있으면 베스트)
- (미래) 이 회사에서 어떤 문제를 어떻게 풀고 싶은가(업무 언어로)
3. Q2) RAG 품질 관리 — “무엇을 기록해야 개선이 된다” 체크리스트
질문 의도
- 단순히 “평가하겠다”가 아니라, 운영/개선 가능한 수준의 관측 가능성(Observability)을 갖추는지 확인
답변 핵심(결론)
RAG 품질 관리는 결국 (입력 → 검색 → 생성 → 후처리/가드레일 → 사용자 반응) 전 구간에서
재현 가능한 기록과 판단 가능한 라벨을 남기는 문제입니다.
운영자가 확인·기록해야 할 항목(권장 목록)
1) 입력(사용자/세션/요구)
- 원질문(raw query), 전처리/리라이트된 질문
- 사용자/테넌트/권한/세션 컨텍스트(가능한 범위에서 비식별화)
- 기대 응답 형식(요약/근거 포함/표/코드 등), 언어, 톤 등
2) 검색(Retrieval) 트레이스
- 사용한 인덱스/컬렉션 버전, 임베딩 모델 버전
- Top-k 문서 ID, 각 문서 점수(score), 문서 최신성(timestamp)
- 필터 조건(권한/도메인/기간), reranker 유무/버전
- “검색 실패”를 판단할 수 있는 신호(예: 평균 점수, 점수 분산, query-doc 유사도 임계치)
3) 생성(Generation) 트레이스
- 모델/엔진 버전(또는 라우팅 정책), 프롬프트 템플릿 버전
- 디코딩 파라미터(temperature, top_p 등), tool-use 여부
- 응답 원문, 근거/인용(citation) 링크/문서 ID 매핑 결과
- latency(검색/생성 구간 분리), 토큰 사용량/비용
4) 품질 라벨(평가/판정)
- 할루시네이션 여부(근거 없는 주장/문서와 불일치)
- 정답성/완전성/형식 준수/안전성(각각 별도 항목으로 분리)
- 내부(운영/품질팀) 판정 + 고객사 판정(가능하면 불일치 이유 태깅)
5) 피드백/개선 연결 고리
- 사용자 피드백(thumbs up/down, 코멘트)
- 이슈 유형 태그(검색 실패 / 문서 최신성 / 프롬프트 문제 / 모델 불안정 / 정책 거부 등)
- 후속 액션(프롬프트 수정, 문서 보강, 인덱스 재빌드, 가드레일 강화)과 릴리즈 노트 연결
4. Q3) 16가지 시나리오 중 1개 선택 — “문제 분해 능력” 확인
시나리오 축은 다음 4개로 정리됩니다.
- 답변: 생성 / 실패
- 할루시네이션: 있음 / 없음
- 내부(제공사) 판단: 좋음 / 나쁨
- 고객사 판단: 좋음 / 나쁨
총 2×2×2×2 = 16가지이며, “생성·할루시네이션 없음·내부 좋음·고객 좋음” 1가지를 제외하고 15개 중 하나를 고르라는 요구였습니다.
4.1 전체 시나리오(요약 테이블)
아래에서 (G, NoHall, 내부Good, 고객Good) 1개는 제외 대상이므로 표에서 뺐습니다.
| ID | 답변 | 할루시네이션 | 내부 판단 | 고객 판단 | 대표 해석(예시) |
|---|---|---|---|---|---|
| 1 | 생성 | 없음 | 좋음 | 나쁨 | “정답인데 고객 요구(형식/범위/업무 맥락) 불일치” |
| 2 | 생성 | 없음 | 나쁨 | 좋음 | “내부 기준이 과도하게 엄격 / 고객은 만족(과소검출 위험도)” |
| 3 | 생성 | 없음 | 나쁨 | 나쁨 | “할루시네이션은 없지만 유용하지 않음(불완전/애매/누락)” |
| 4 | 생성 | 있음 | 좋음 | 좋음 | “양쪽이 할루시네이션을 놓침(가장 위험한 유형)” |
| 5 | 생성 | 있음 | 좋음 | 나쁨 | “고객이 오류를 감지 / 내부는 과신(감시체계 문제)” |
| 6 | 생성 | 있음 | 나쁨 | 좋음 | “고객이 오류를 못 느낌(리스크 큼) / 내부는 감지” |
| 7 | 생성 | 있음 | 나쁨 | 나쁨 | “명백한 할루시네이션(근거 불일치), 재현/원인분석 필요” |
| 8 | 실패 | 없음 | 좋음 | 좋음 | “정상 실패(권한/정책/정보부재를 정확히 고지)” |
| 9 | 실패 | 없음 | 좋음 | 나쁨 | “정상 거부였지만 고객은 ‘해결’ 기대(정책/UX 정렬 필요)” |
| 10 | 실패 | 없음 | 나쁨 | 좋음 | “실패로 분류했으나 고객은 만족(기대치가 낮거나 대안 제시가 유효)” |
| 11 | 실패 | 없음 | 나쁨 | 나쁨 | “진짜 실패(툴 장애/검색 실패/타임아웃), 운영 이슈” |
| 12 | 실패 | 있음 | 좋음 | 좋음 | “실패 상황에서 헛소리/왜곡이 섞였는데도 양측이 ok(탐지 부재)” |
| 13 | 실패 | 있음 | 좋음 | 나쁨 | “실패+왜곡(부분 생성), 고객이 불신 / 내부는 과신” |
| 14 | 실패 | 있음 | 나쁨 | 좋음 | “내부는 위험 감지, 고객은 체감 못함(고객 피해 가능)” |
| 15 | 실패 | 있음 | 나쁨 | 나쁨 | “최악: 실패+왜곡, 재현·차단이 최우선” |
5. Q4) 동일 질문인데 결과가 달라짐 — 원인 1~2개를 깊게
이 질문은 “정답”보다 원인을 시스템적으로 분해할 수 있는지를 봅니다.
저라면 아래 2개를 가장 핵심으로 설명합니다.
원인 1) LLM 디코딩의 비결정성(샘플링)
- temperature/top_p 등의 샘플링 파라미터가 0이 아니라면, 같은 입력이라도 다른 토큰 경로를 선택할 확률이 생깁니다.
- 서버에서 seed가 고정되지 않거나, 멀티 인스턴스 환경에서 실행 경로가 달라지면 시간이 지나며 결과가 달라질 수 있습니다.
통제 방법
- deterministic 모드(temperature=0 등) + seed 고정(가능한 환경에서)
- “재현 가능한 실행 로그(모델/프롬프트/파라미터/버전)” 저장
- 테스트 환경에서는 라우팅/버전 고정(AB 테스트 환경과 분리)
원인 2) RAG의 검색 결과가 시간에 따라 변함(인덱스/문서/임베딩)
- 문서가 추가/수정되거나, 인덱스가 재빌드되거나, 임베딩/리랭커 버전이 바뀌면 Top-k 문서 자체가 달라져 생성 답변이 달라집니다.
- 특히 “최신 문서 우선”, “권한 필터”, “동일 점수 tie-breaker” 같은 요소가 있으면 미세한 변화가 출력 차이를 만들 수 있습니다.
통제 방법
- 인덱스/임베딩/리랭커 버전 관리 + 롤백 가능하게
- 검색 결과(문서 ID/점수/버전)를 로그로 저장해 “왜 달라졌는지” 추적
- 운영에서는 최신성을 반영하되, 테스트/회귀에서는 고정된 스냅샷 인덱스 사용
6. Q5) LLM이 만든 테스트셋으로 LLM Agent를 테스트해도 되나?
내 결론
“조건부로는 가능하지만, 단독으로 쓰면 위험하다.”
즉, 초안 생성/커버리지 확장용으로는 유용하지만,
최종 품질 판단(합격/불합격)의 근거로 100% 의존하면 안 된다는 입장입니다.
반대(위험 요소)
- 모델 편향/말투/구조가 비슷해서 “진짜 사용자 분포”를 못 담음
- 생성 모델이 만든 데이터는 정답(ground truth)의 신뢰성이 낮을 수 있음
- 같은 계열 모델을 쓰면 평가 오염(teacher-student leakage) 위험
- 테스트가 “정답성”보다 “그럴듯함”을 학습할 수 있음
마무리
이번 면접에서 느낀 점은, RAG/LLM 품질 논의가 결국 “모델 성능”이 아니라 “측정 가능한 기준 + 재현 가능한 로그 + 개선 루프”로 귀결된다는 것이었습니다.
다음에는 질문이 나오면
- (1) 문제를 정의하고
- (2) 관측 가능한 신호를 제안하고
- (3) 해결책을 운영 가능한 단위로 쪼개서
말할 수 있도록 준비해보려 합니다.
Leave a comment