문제를 더 작게 보이도록 내 도구를 가르치는 데 하루를 보냈다

모든 "우리는 $X만큼의 낭비를 발견했습니다!"라고 말하는 도구에는 조용한 유인이 있습니다. 숫자가 커질수록 데모가 더 인상적으로 보이기 때문입니다. 그래서 저는 트레이스 (trace)를 낭비 요약 (waste summary)으로 변환하는 보고서를 만들 때, 그 숫자를 정직하게 유지하는 것만을 목적으로 하는 네 가지 규칙을 의도적으로 설계했습니다:

1. 재실행 (re-run)만 카운트하고, 원본은 절대 카운트하지 않습니다. 에이전트 (agent)가 실제 작업을 한 번 수행한 후 중복해서 반복한다면, 반복된 부분만이 낭비입니다. 정당한 첫 번째 실행을 "낭비" 열에 포함하는 것은 헤드라인 숫자를 두 배로 불리는 가장 쉬운 방법이며, 동시에 거짓말입니다.

2. 낭비된 스팬 (span)당 하나의 행 (dedupe, 중복 제거). 하나의 반복이 이전의 여러 실행과 쌍을 이룰 때, 단순한 보고서는 이를 여러 번 나열하여 낭비가 시각적으로 부풀려집니다. 저는 행 (rows)의 수가 실제 낭비된 스팬 (wasted spans)과 같음을 테스트에서 단언합니다.

3. 추측 대신 "unknown". 토큰 수 (token count)가 캡처되지 않았나요? 보고서는 unknown이라고 표시합니다. 셀을 채우기 위해 그럴듯한 숫자를 만들어내지 않습니다.

4. 보고서는 헤더에 고정된 자체 파라미터 (φ, N, embedding model)를 출력합니다. 따라서 보고서를 읽는 누구라도 어떤 설정이 이를 생성했는지 정확히 알 수 있습니다.

이 중 어떤 것도 데모를 더 화려하게 만들지 않습니다. 그것이 핵심입니다. 모든 경쟁자가 부풀리려는 유인을 가진 카테고리에서, 과장을 거부하는 보고서는 차별화 요소가 됩니다. 그리고 이는 선의가 아니라 테스트를 통해 강제됩니다.

코드는 공개되어 있습니다: github.com/JEONSEWON/Clew-by-Custos

#BuildInPublic #AIAgents #LLMOps #DevTools

[

]