수행할 가치가 있는 최적화와 인상적으로 보이는 최적화

최적화 작업은 기술적으로 흥미로운 쪽으로 끌리는 경향이 있습니다. 추론 수준 기술은 정말 영리하고 잘 문서화되어 있으며 구현하기에 만족스럽습니다.

또한 대부분의 배포에서 도움이 될 수 있는 항목 목록에서 5위 미만입니다.

우리가 실제로 작업할 순서

먼저, 할 필요가 없는 작업을 제거하십시오. 모든 호출에서 컨텍스트를 차지하는 사용되지 않은 도구 정의입니다. 2년 전 특별한 사례에 대한 프롬프트 섹션이 추가되었습니다. 3개가 필요한 구절을 10개 반환하는 검색입니다. 이는 순수한 낭비이며, 이를 제거하는 것은 아무런 기여도 하지 않기 때문에 품질 면에서 아무런 비용도 들지 않습니다.

둘째, 재시도를 수정합니다. 실패하고 다시 시작되는 실행은 하나의 결과에 대해 두 배의 비용을 지불합니다. 재시도는 일반적으로 해결 가능한 가장 큰 단일 비효율성이며 성공과 별도로 측정되지 않는 한 눈에 띄지 않습니다.

셋째, 순차적이지만 독립적인 것을 병렬화합니다. 대부분의 에이전트 코드는 읽어야 하기 때문이 아니라 읽는 방식 때문에 단계를 연속적으로 실행합니다.

넷째, 단계별로 모델의 크기를 조정하세요. 분류 및 추출 단계에는 프론티어 기능이 거의 필요하지 않으며 이를 실행하는 데 아무런 이점도 없이 영구적인 비용이 소요됩니다.

다섯째, 지금은 추론 수준 기술입니다.

기술보다 순서가 더 중요한 이유

처음 4개는 저렴하고 위험도가 낮으며 규모가 큰 경우가 많습니다. 다섯 번째는 정교하며, 그 영향은 애초에 추론에 소요된 시간이 얼마나 되는지에 따라 제한됩니다.

추론이 런타임의 1/3이라면 추론이 20% 향상되면 실행이 7% 향상됩니다. 이는 가질 만한 가치가 있으며, 트래픽 공유에 100%의 비용을 초래하는 재시도 전에는 가질 가치가 없습니다.

선택하기 전에 측정하세요

위의 모든 내용은 귀하가 고장을 알고 있다고 가정합니다. 표준 계측은 단계가 아닌 실행별로 보고하기 때문에 대부분의 팀에서는 그렇지 않습니다.

단계별 측정은 이 목록의 모든 결정에 대한 전제 조건입니다. 그것이 없으면 최적화는 취향의 문제이며 취향은 흥미로운 옵션을 확실하게 선택합니다.

모든 최적화는 품질에 대한 가설입니다.

우리가 최적화 전 평가를 고집하는 이유는 이러한 모든 변화가 품질을 저하시킬 수 있고, 대부분의 감소는 즉시 눈에 띄지 않기 때문입니다.

기능이 필요한 것으로 판명된 단계의 작은 모델입니다. 실제 극단적인 경우를 처리하는 단락을 제거한 잘린 프롬프트입니다. 검색된 구절 수가 적습니다. 질문에 네 번째 구절이 필요할 때까지는 괜찮습니다.

미리 정의한 기준에 따라 각 변경 사항의 점수를 매기는 것이 비용 절감과 지연을 구분하는 것입니다. 이것이 바로 옵티마이저가 하는 일이며, 이것이 바로 옵티마이저가 변경 사항을 비용 측면의 개선으로 제시하는 것을 거부하는 이유입니다.

화려하지 않은 결론

대부분의 에이전트 시스템에서 가장 큰 수익을 내는 최적화 작업은 사용하지 않는 도구, 축적된 프롬프트 텍스트, 불필요한 검색, 순차적이어서는 안 되는 단계 등을 삭제하는 것입니다.

그 중 어느 것도 글을 쓰는 데 흥미롭지 않습니다. 아마도 이것이 대안에 대해 훨씬 더 많이 쓰여진 이유일 것입니다.

다음

옵티마이저 및 토큰 모니터링 페이지에서는 단계별 측정 및 평가 측정 최적화를 다룹니다. AI 관찰 가능성 페이지에서는 실행 내부의 계측을 다룹니다.