토큰 예산을 기능이 아니라 구조로 다루기

늘리면 해결되는 것처럼 보인다

프롬프트가 길어지면 비용이 는다. 그런데 진짜 문제는 비용이 아니다.

String prompt = systemInstruction + conversationHistory + retrievedDocuments;

retrievedDocuments 가 늘어날수록 모델이 봐야 할 것과 봐도 그만인 것의 비율이 나빠진다. 컨텍스트를 두 배로 키우면 답이 두 배 좋아지는 것이 아니라, 흐려질 여지가 두 배가 된다.

예산을 자리로 나눈다

기능이 늘 때마다 프롬프트에 문단이 하나씩 붙는 구조는 오래 못 간다. 자리를 먼저 정하고, 그 자리 안에서 경쟁시킨다.

규칙은 코드가 아니라 데이터로 둔다

상한을 상수로 박으면 모델을 바꿀 때마다 배포해야 한다. 설정으로 두면 운영 중에 조정할 수 있고, 무엇을 줄였을 때 답이 나빠지는지를 실제 트래픽으로 확인할 수 있다.

줄일 수 없는 것을 먼저 찾는 일이 설계다. 컨텍스트를 키우는 것은 그 일을 미루는 것이다.