Quiz: Tool Calls and Result Validation

모델이 고른 인자를 검증하는 자리를 도구를 부르기 전으로 잡는 가장 큰 이유는?

• 부르기 전에 재야 예외를 잡는 코드를 안 써도 되기 때문이다
• 한 번 부르고 나면 돌이킬 수 없는 도구가 있기 때문이다
• 부른 뒤에는 인자 값을 더 이상 읽을 수 없기 때문이다
• 검증을 먼저 해야 결과 검증보다 빨리 끝나기 때문이다

limit 을 {"type": "int", "min": 1, "max": 2} 로 적어 두고 limit=True 로 불렀더니 검증을 통과했다. 원인은?

• 딕셔너리 열쇠 순서 때문에 범위 검사가 형 검사보다 먼저 돌았다
• 참거짓은 형이 없어 어떤 검사도 통과시킨다
• True 가 1 로 바뀌어 저장되므로 범위 안에 든다
• 파이썬에서 bool 은 int 의 하위형이라 정수 검사를 통과한다

도구가 {"sku": "A-1001", "rows": []} 를 돌려줬다. 이 결과를 어떻게 다루는 것이 옳은가?

• 빈 결과를 실패 사유로 분류하고 답을 지어내지 않는다
• 성공으로 보고 다음 노드가 알아서 처리하게 둔다
• 예외를 던져 그래프 실행을 끝낸다
• 같은 인자로 상한까지 다시 불러 본다

call_tool 이 실패를 예외 대신 {"ok": False, "error": "args:allowed:region"} 로 돌려줄 때 얻는 것은?

• 도구 함수를 고치지 않고도 재시도 횟수를 늘릴 수 있다
• 실패한 호출도 캐시에 들어가 다음에 빨라진다
• 사유가 상태에 쌓여 다음 시도에서 무엇을 고칠지 코드로 정해진다
• 그래프가 실패한 노드를 자동으로 다시 실행한다

도구 결과를 기억(캐시)할 때 열쇠를 이름 + json.dumps(args, sort_keys=True) 로 만드는 이유는?

• JSON 문자열이 딕셔너리보다 비교가 빨라서
• 인자를 적은 순서가 달라도 같은 호출이면 같은 열쇠가 나와야 해서
• 정렬해 두어야 캐시에서 오래된 항목을 먼저 지울 수 있어서
• 딕셔너리는 열쇠로 쓸 수 없어 문자열이면 무엇이든 되어서

고칠 수 있는 사유의 목록과 시도 상한을 둘 다 두는 이유로 가장 정확한 것은?

• 목록은 예산을 아끼고 상한은 고칠 수 없는 실패를 걸러 낸다
• 목록은 문서용이고 상한만 실제로 실행을 멈춘다
• 둘 중 하나만 있으면 그래프가 컴파일되지 않는다
• 목록은 고칠 수 없는 실패를 바로 끊고 상한은 고쳐도 안 되는 경우를 끊는다