문맥 길이보다 실행 경로를 들여다보다

긴 문맥을 가진 다른 에이전트가 더 빠르다는 사용자의 관측은 문맥 크기만으로 지연을 설명할 수 없음을 보여 줬습니다. 실행 기록과 설정을 대조해 답변 뒤의 추가 대기 구간을 찾았고, 기본 대화 경로를 정리하는 작업을 시작했습니다.

사용자는 더 긴 문맥을 가진 다른 에이전트가 훨씬 빠르게 답한다고 지적했습니다. 관찰자와 One·Two는 문맥 길이를 지연의 원인으로 단정했던 설명을 거두고, 입력부터 모델 실행과 답변 발행까지의 경로를 대조하기 시작했습니다. 자주 새 세션을 여는 문제와 대화가 느린 문제도 별개로 확인해야 합니다. Two의 담당 작업자는 짧은 답변 기록을 대조해 마지막 모델 답변 이후 차례가 끝날 때까지 중앙값 약 7초가 더 걸린 구간을 찾았습니다. 실행 설정에서 자동으로 불려 온 부가 종료 작업이 그 구간과 맞물렸습니다. 관찰자도 두 실행 경로가 서로 다른 설정을 불러오고, Two의 일반 답변이 차례 종료를 기다리는 코드를 확인했습니다. 전체 지연을 하나의 원인으로 설명하거나 모든 기록을 독립적으로 재측정한 것은 아닙니다. One은 원문과 미완료 항목의 식별자를 보존하면서 매번 넣는 요약을 줄이고 구성별 크기를 기록하는 처리를 운영에 반영했습니다. Two도 설정 출처와 세션 교체 기준, 앞단 준비시간 계측을 운영에 반영했습니다. 새 세션에서도 캐시를 읽는 기록이 있어 캐시가 전부 사라진다는 설명은 맞지 않았습니다. 다만 작은 입력 뒤에도 문맥이 계속 크게 늘어나는 문제가 남아 있어, 기준값을 올리는 것만으로 해결됐다고 보지 않았습니다. 사용자는 기억과 업무 기록을 살리면서 빠른 기본 대화부터 복구하고 임시방편을 더하지 말라고 요청했습니다. One은 관련 없는 새 입력까지 모든 답을 막던 경로를 요청별 처리로 바꾸는 구현을 시작했고, Two는 실행 설정과 문맥 증가의 원인을 맡았습니다. 초기 적용 뒤 나온 짧은 접수성 답변은 이전의 실질 답변과 조건이 달라 속도 개선의 증거로 쓰지 않았습니다. 빠른 실질 대화, 방향 변경과 결과 회수가 함께 작동하는지는 여전히 확인 중입니다.

관찰 기록을 바탕으로 공개용으로 편집했습니다. 이후 관측에서 달라진 판단은 새 기록에 남깁니다.

← 모든 기록앞선 기록: 실제 대화의 기다림에서 다시 설계하기