RAG2026-5일24차시 · Retriever Node 분리5 / 18← 이전목차다음 →MetaContents

24차시. Retriever Node 분리

2. 좋은 Retriever Node의 4가지 설계 원칙

출처: 원본 PDF 24차시_RetrieverNode분리.pdf 5~6쪽 · 쪽 그림 5쪽 6쪽

2-1) 원칙 ① — State에서만 입력받는다

❌ 전역 설정에 의존

출력
──────────────────────────────────────
def retrieve(state):
    return {"documents": search(state["query"], k=config.TOP_K)}

→ 실행 중에 k를 바꿀 수 없습니다
→ 재검색할 때 더 넓게 찾을 수 없습니다

✅ State에서 읽되 기본값은 config

출력
──────────────────────────────────────
def retrieve(state):
    k = state.get("top_k") or config.TOP_K
    return {"documents": search(state["query"], k=k)}

→ 평소에는 config 값 사용
→ 필요하면 State로 덮어씀 (재검색 시 k 확대)

2-2) 원칙 ② — 판단 재료를 남긴다

🎯 검색 노드의 진짜 역할
문서를 가져오는 것만이 역할이 아닙니다.
"이 결과를 믿어도 되는가"를 함께 남겨야 합니다.
· scores — 각 조각의 점수
· retrieval_ok — 기준을 통과했는가
· fail_reason — 실패했다면 왜인가
이 정보가 없으면 Router가 판단할 수 없습니다.
노드는 판단하지 않고, 판단 재료만 남깁니다.

2-3) 원칙 ③ — 빈 결과를 에러로 만들지 않는다

검색 결과가 0건인 것은 정상적인 상황입니다.
예외를 던지면 그래프가 중단됩니다.
빈 리스트를 반환하고 retrieval_ok=False로 표시합니다.
그다음 어디로 갈지는 조건부 Edge가 정합니다.

2-4) 원칙 ④ — 혼자서도 실행된다

출처: 원본 PDF 6쪽

출력
result = retriever_node({"query": "환불 규정"})

→ 그래프 없이 딕셔너리 하나만 주면 동작
→ 디버깅과 A/B 테스트가 쉬워집니다
← 이전 절24차시 · 1. 왜 검색을 가장 먼저 독립시킬까?다음 절 →24차시 · 3. 실습 ① — Retriever Node 완성