정리와 체크리스트

19장에서 배운 것

조건부 엣지 — 분기 함수가 돌려준 이름의 노드로 가는 엣지. add_conditional_edges로 만듭니다.
분기 함수 — 상태를 받아 다음 노드의 이름을 돌려주는 함수. 상태를 바꾸지 않습니다.
라우터 — 문의를 알맞은 노드로 보내는 부분. 판단(모델)과 길 안내(코드)로 나눕니다.
라우팅 표 — 분류 결과와 노드를 잇는 규칙. 개발자가 정하고 코드에 적습니다.
기본 경로 — 표에 없는 값이 가는 노드. 반드시 하나 둡니다.
갈래 노드 — 자기 일에 필요한 도구만 가집니다. LLM이 없는 노드도 있습니다.
루프백 — 뒤에서 앞으로 돌아가는 엣지. 반복을 그래프로 표현합니다.

한눈에 보는 핵심

def route(state: CSState) -> str:            # 상태를 보고
    return {"주문배송조회": "order",          # 다음 노드의 이름을 돌려준다
            "환불교환": "policy"}.get(state["intent"], "general")

builder.add_conditional_edges("classify", route,            # 출발 노드, 분기 함수
                              ["order", "policy", "human", "general"])  # 갈 수 있는 곳

누가 정했나	무엇을
모델	이 문의가 어느 유형인가 (`classify`)
개발자	유형마다 어느 노드로 보내는가 (`route`의 딕셔너리)
개발자	노드마다 어떤 도구를 주는가
모델	도착한 노드 안에서 어떤 도구를 부르고 어떻게 답하는가

확인할 것	어디를 보나
분류가 맞는가	로그의 `분류 → …`
길이 맞는가	로그의 노드 이름과 라우팅 표
답의 근거가 맞는가	도착한 노드의 도구와 시스템 프롬프트

체크리스트

[ ] add_edge와 add_conditional_edges의 차이를 설명할 수 있다.
[ ] 분기 함수와 노드 함수가 돌려주는 값이 어떻게 다른지 말할 수 있다.
[ ] 그래프 그림에서 실선과 점선이 각각 무엇을 뜻하는지 안다.
[ ] route 함수 안에 LLM 호출이 없는 이유를 설명할 수 있다.
[ ] 라우팅 표에서 멤버십적립금과 환불교환이 같은 노드로 가는 이유를 말할 수 있다.
[ ] 기본 경로가 왜 필요한지 설명할 수 있다.
[ ] human 노드가 LLM을 부르지 않는 이유를 설명할 수 있다.
[ ] 네 문의가 각각 어느 노드로 갔는지 실행 결과의 경로로 확인했다.
[ ] 주문 노드의 답에 나온 주문번호·옵션·상태를 data/orders.csv와 견주어 확인했다.
[ ] 일반 노드가 식기세척기 질문에 "설명에 없다"고 답한 까닭을 시스템 프롬프트에서 짚을 수 있다.

한 줄 핵심

모델은 문의를 읽고, 코드는 길을 정합니다. 길 끝의 노드는 자기에게 주어진 근거 안에서 답합니다.