测验：分支、循环与递归上限

add_conditional_edges("review", after_review, {"ship": "ship", "revise": "revise"}) 에서 after_review 가 돌려주어야 하는 것은?

• 그 갈래로 넘길 상태 딕셔너리
• 경로 지도의 열쇠, 즉 갈래 이름
• 다음에 실행할 노드 함수 객체
• 다음 노드까지의 엣지 개수

노드 3개를 나란히(전부 START 에서 갈라져) 둔 그래프와 줄줄이 이은 그래프의 최소 recursion_limit 을 재어 보니 각각 2 와 4 였다. 이 차이가 말하는 것은?

• 나란히 둔 노드는 한도를 절반만 쓴다
• 줄줄이 이은 그래프는 엣지 수만큼 한도를 쓴다
• 한도는 노드 실행 횟수가 아니라 수퍼스텝을 세고, 나란한 노드는 같은 수퍼스텝이다
• 한도는 조건부 엣지가 있을 때만 늘어난다

GraphRecursionError 가 자꾸 나서 recursion_limit 을 25 에서 200 으로 올렸다. 이 대응의 문제는?

• 한도를 올리면 체크포인트가 그만큼 커진다
• 한도는 그래프를 컴파일할 때만 정할 수 있어 config 로는 바뀌지 않는다
• 끝내는 조건에 닿지 못하는 입력이 있다면 한도와 무관하게 그 건은 끝나지 않는다
• 한도를 올리면 조건부 엣지의 경로 지도가 무시된다

상태의 rounds 로 거는 안쪽 상한이 recursion_limit 만으로는 안 되는 이유는?

• 바깥 상한에 닿으면 예외가 나서 여태 만든 결과가 사라진다
• recursion_limit 은 비동기 실행에서는 동작하지 않는다
• recursion_limit 은 조건부 엣지가 있는 그래프에서 무시된다
• rounds 를 세지 않으면 체크포인터가 상태를 저장하지 않는다

어떤 문의가 몇 바퀴를 돌아도 통과하지 못한다. 그래프를 돌리지 않고 이것을 미리 알아내는 방법으로 가장 적절한 것은?

• 첫 바퀴의 점수가 기준의 절반 미만인지 본다
• 고치는 함수를 더 이상 바뀌지 않을 때까지 적용해 보고 그때의 점수가 기준에 닿는지 본다
• 질문의 길이를 기준 길이와 비교한다
• 재귀 한도를 두 배로 올려 돌려 본다

GraphRecursionError 를 잡아 {"status": "limit"} 으로 남기고, 스스로 끝난 경우는 {"status": "done"} 으로 남기는 이유는?

• limit 으로 끝난 건은 자동으로 재시도되기 때문이다
• 예외를 잡아 두지 않으면 체크포인트가 지워지기 때문이다
• status 값이 다르면 LangGraph 가 다음 실행에서 한도를 자동으로 늘리기 때문이다
• 판단할 기회를 잃은 것과 판단해서 끝낸 것은 다른 사건이라 나중에 가를 수 있어야 하기 때문이다