23차시. Modular RAG 개념
4. 모듈 간 계약 (인터페이스)
출처: 원본 PDF 23차시_ModularRAG개념.pdf 8쪽 · 쪽 그림 8쪽
이 표가 3부 전체의 설계도입니다. 여기만 지키면 모듈을 자유롭게 교체할 수 있습니다.
| 모듈 | 읽는 State 키 | 쓰는 State 키 | 책임 |
|---|---|---|---|
| Retriever | query, top_k | documents, scores, / retrieval_ok | 근거 확보 |
| Generator | documents, question | answer, insufficient, / has_citation | 답변 작성 |
| Verifier | answer, documents, question | grade, reason | 품질 판정 |
| Rewriter | question, retries, / reason | query | 질의 개선 |
| Fallback | question, reason | answer, grade | 안전한 마무리 |
⚠️ 계약을 지키는 3가지 규칙
① 남의 키는 쓰지 않는다
Generator가 documents를 수정하면 안 됩니다
읽기만 합니다
② 자기 키는 반드시 쓴다
Verifier가 grade를 안 채우면 Router가 판단 못 합니다
③ 흐름 결정은 하지 않는다
모듈은 결과만 남깁니다
"다음에 어디로 갈지"는 Router(조건부 Edge)의 일입니다
이 규칙이 깨지면 모듈화의 의미가 사라집니다.
🎯 왜 모듈이 흐름을 결정하면 안 되나
Verifier가 이렇게 만들어졌다고 해봅시다.
"검증 실패하면 직접 generate를 다시 호출"
그러면
· 재시도 횟수를 어디서 세죠?
· 재검색으로 바꾸려면 Verifier를 고쳐야 합니다
· Verifier를 단독 테스트할 수 없습니다
판정과 결정을 분리하면
Verifier — "이 답변은 근거 부족입니다" (판정)
Router — "그럼 재검색으로 보내자" (결정)
나중에 정책이 바뀌어도 Router만 고치면 됩니다.