Luna에서 Sol로 넘기면 저렴할까? 오류와 총비용 확인하기

Luna로 먼저 처리한 뒤 필요할 때 Sol로 넘기는 방식은, 접수한 결과의 오류가 허용 범위 안에 있고 전체 비용도 낮아야 의미가 있습니다. 첫 호출의 저렴한 가격만 보면 추가 모델, 재시도와 사람의 대응을 놓칩니다.

2026년 9월 24일 Luna와 Sol 문서를 확인했습니다. 두 모델을 1차 처리와 추가 검토에 배치하는 것은 설계 가설이며 실측한 품질 순위가 아닙니다. 실습 자료는 미리 작성한 기록이며 API를 호출하지 않습니다.

관찰 가능한 조건으로 경로 나누기

구조화 추출 과제의 분류, 주문 번호, 원문 인용을 사용합니다. 완료, 파싱, 스키마 적합성과 출처 검사를 통과해도 분류 의미는 틀릴 수 있습니다.

접수, Sol 추가 검토, 사람의 확인을 분리합니다. 모든 실패를 다시 모델에 보낼 필요는 없습니다. 자료가 빠졌다면 사용자에게 물어야 할 수 있고, 환불은 정확한 분류 외에 별도 권한이 필요합니다.

규칙에 버전을 붙입니다. 평가 도중 임계값을 바꾸면 이전 규칙을 보관하고 보류 평가 집합을 다시 실행해 서로 다른 조건을 섞지 않습니다.

추가 검토로 보내지 않은 오류 찾기

어려워 보이는 추가 검토 사례만 확인하면 검증기를 통과한 오답은 보이지 않습니다. 모델의 확신 점수와 별개로 접수된 기록을 추출해 독립적으로 검사하세요.

잘못 접수된 수를 접수 건수로 나눈 값과 전체 작업 수로 나눈 값을 구분합니다. 표본 크기와 추출 방법을 적고, 소수의 선택 사례로 실서비스 오류율을 주장하지 않습니다. 드물지만 비용이 큰 분류와 각 언어를 따로 봅니다.

모델의 자기 확신은 보정된 확률이 아닐 수 있습니다. 점수를 쓰려면 라벨 데이터로 임계값을 정하고 별도 집합으로 검증합니다. 답을 만든 시스템만 유일한 심사자로 삼지 않습니다.

경로 전체 비용 계산하기

원래 문의마다 1차 호출, Sol 호출, 실패 재시도, 외부 도구와 사람의 처리를 연결합니다. 해당 날짜, 공급자와 모드에 맞는 실제 사용량 및 요금을 적용하고 과거 청구액을 새 가격으로 바꾸지 않습니다.

경로 비용 = 1차 처리 + 추가 호출 + 재시도·도구 + 사람의 처리

토큰 단가가 아니라 완료하고 합격한 작업당 비용을 비교합니다. 미해결 작업도 남겨야 어려운 일을 버린 구성이 싸게 보이는 일을 피할 수 있습니다. 사람의 시간과 단가 가정을 밝히거나 분 단위로 따로 보고하고, 조용히 0으로 두지 않습니다.

오프라인 비용 반례 실행하기

압축을 푼 디렉터리에서 실행합니다.

python3 lab.py routing

합계는 17단위입니다. 모든 요청을 Sol로 처리하는 가정값 16은 토큰만 포함하며 품질과 사람의 작업을 측정하지 않았습니다. 따라서 승자를 정할 수 없는 불완전한 비교이고, 저렴한 첫 네 번의 호출만으로 절약을 증명할 수 없다는 반례입니다. 접수 두 건 중 하나의 오답도 Luna에서 측정한 50% 오류율이 아닙니다.

모든 요청을 Sol로 처리하는 기준과 공정하게 비교하기

같은 보류 입력, 분류 규칙, 출력 스키마와 판정 방식을 사용합니다. 공급자, 모델 ID, effort, 예산과 도구 권한을 고정하고 맞출 수 없는 차이는 적습니다. 서비스 부하가 지연에 영향을 주면 순서를 무작위화하고 실제 경과 시간을 측정합니다.

기준 구성에도 재시도와 사람의 확인 비용을 똑같이 넣습니다. 분류별 품질, 합격 작업 비용, 미해결 수, 지연 백분위와 표본 수를 비교하세요. 반복 실행은 불안정성을 보여 주지만 작은 표본의 대표성을 보장하지 않습니다.

허용할 오류와 비용의 범위를 먼저 정한 뒤 임계값을 선택합니다. 시험 단계에서 사람의 승인을 유지하는 것도 타당합니다. Sol 요금과 Luna 요금은 사용량 해석 자료이며 같은 과제의 실험을 대신하지 않습니다.