처음 몇 주 동안 나는 실패가 모델의 잘못이라고 가정했다. 그것은 쉬운 설명이었고, 또한 해결책이 다른 사람의 일이라는 의미도 내포하고 있었다.
그러다가 나는 숫자를 세어보았다. 내가 기록한 실패 중 약 18%만이 실제로 모델 오류였다. 나머지는 상태(state), 권한(permissions), 그리고 종료 조건(finish condition)이 작성되지 않은 작업들 때문이었다.
어쨌든 내가 진행했던 세 번의 모델 교체
직관에 공정하기 위해, 나는 모델을 세 번이나 교체했다. 각 교체는 실제로 무언가를 개선했다:
- 첫 번째 교체는 잘못된 형식의 도구 인자(tool arguments) 클래스를 수정했다. 일주일 만에 눈에 띄는 진정한 개선이었다.
- 두 번째 교체는 작성 작업에서 어조를 수정하여 초안이 재작성될 필요가 없어지게 했다. 가치가 있었지만, 동시에 글쓰기 작업 자체가 애초에 내가 위임해서는 안 되는 것이었음을 깨닫게 해 주었다.
- 세 번째 교체는 관찰 가능한 아무것도 고치지 못했고 비용만 더 들였다. 나는 포기하기 전에 한 달 동안 그것을 유지했다.
이것이 전반적인 모습이다: 더 좋은 모델은 실제로 모델의 잘못인 실패를 수정한다. 그것들은 잘못된 분기(wrong branch), 막힌 포트(held port), 또는 에이전트가 끝났다고 느끼면 언제든지 종료되는 작업을 건드리지 못한다.
프레이밍에 숨겨진 함정
'그냥 더 좋은 모델을 사용하라'는 말은 도구(tooling)에 대한 조언처럼 들린다. 실제로는 종종 지루한 부분, 즉 저렴한 모델로도 처리할 수 있을 만큼 충분히 작업을 설명하고 상태를 잘 정의하는 것을 피하라는 조언이다.
나는 다섯 줄을 작성하는 것을 피하기 위해 토큰을 사는 나 자신을 보았다. 그것은 잠시 효과가 있지만, 더 높은 비용 지점에서 같은 실패가 다시 돌아온다.
더 좋은 모델이 진정으로 필요한 경우
나는 그것에 반대하는 것이 아니다. 남아있는 실패들이 도구 선택과 다단계 추론(multi-step reasoning)에 집중되어 있을 때, 더 좋은 모델은 즉시 변화를 가져오며 돈을 잘 쓰는 것이다.
핵심은 순서이다. 상태를 고정하고, 종료 조건을 작성하며, 권한 경계(permission edges)를 정의한 다음, 수정할 것이 남아있을 때 모델을 업그레이드하라. 다른 순서로 진행하는 것은 같은 실패를 더 빠르게 실행하기 위해 비용을 지불하는 것을 의미한다.
최근에 교체(swap)를 해보셨다면, 나중에 구체적으로 지적할 수 있는 문제가 해결되었나요? 제 경우엔 세 번 중 두 번이나 효과가 있었고, 그 두 번의 성공은 제가 어떤 실패(failure)를 없애려고 하는지 정확히 알고 있던 경우였습니다.