30초 타임아웃은 AI 워크플로우 정책이 아닙니다

30초 타임아웃은 합리적인 기본값처럼 느껴집니다.

하지만 다단계 AI 워크플로우(multi-step AI workflow)에서 이는 대개 설명되지 않은 실패가 발생하기를 기다리는 것과 같습니다.

단일 요청에는 다음과 같은 과정이 포함될 수 있습니다:

만약 이 모든 단계가 하나의 전역 타임아웃 (global timeout)을 공유한다면, 그 워크플로우는 시간 정책을 가진 것이 아닙니다.

그것은 단지 타이머를 가지고 있을 뿐입니다.

하나의 전역 타임아웃이 가진 문제점

30초 제한이 있는 RAG 워크플로우를 상상해 보십시오.

검색 (Retrieval)에 12초가 소요됩니다. 기본 모델 (primary model)이 10초를 사용합니다. 도구 호출 (tool call)에 6초가 걸립니다. 그 후 출력 검증 (validation)에 실패합니다.

이제 남은 시간은 단 2초뿐입니다.

폴백 모델 호출 (fallback model call)을 시작하는 것은 더 이상 복구(recovery)가 아닙니다. 그것은 또 다른 예측 가능한 타임아웃일 뿐입니다.

사용자는 실패한 답변을 보게 됩니다. 팀은 30초짜리 요청을 보게 됩니다. 어느 쪽도 워크플로우의 어느 부분이 예산을 소모했는지 알 수 없습니다.

이는 시스템을 개선하기 어렵게 만듭니다.

첫 번째 타임아웃 질문은 다음과 같아서는 안 됩니다:

제공업체의 타임아웃은 얼마인가?

다음과 같아야 합니다:

얼마가 지나면 이 결과가 사용자에게 더 이상 유용하지 않은가?

고객 지원 채팅 응답, 연구 작업, 그리고 야간 문서 처리 작업은 이에 대해 매우 다른 답을 내놓을 것입니다.

실시간 워크플로우의 경우, 사용자에게 보이는 마감 기한 (user-facing deadline)을 먼저 정의하십시오. 그런 다음 그 시간 내에 각 단계에 의도적으로 시간을 할당하십시오.

예를 들어:

json
{
...