오픈소스 모델이 제한되면 가장 먼저 실패하는 것은 회귀판단이다.

오픈 소스 모델에 외부 제한이 적용되면 가장 먼저 깨지는 것은 "아직 다운로드할 수 있습니까?"가 아닙니다. 그런데 “이번 결과도 지난번 결과와 함께 볼 수 있나요?” 모델명이 그대로 남아 있고 인터페이스도 계속 연결할 수 있습니다. 정말 어려워지는 것은 판단 기준이 표류하기 시작한다는 것입니다. 동일한 프롬프트 단어 세트, 동일한 샘플 배치, 동일한 작업 흐름, 실행되는 결과는 더 이상 동일한 행동 분포가 아닙니다.

이것은 서류상으로는 간단해 보이지만 실제로는 매우 짜증나는 일입니다. 이전에 통과할 수 있었던 출력 형식에 갑자기 조금 더 설명이 추가되거나, 이전에 안정적인 함수 호출 순서가 변경되기 시작하거나, 일부 영역에 추가 정책 프롬프트 계층이 있거나, 동일한 요청이 서로 다른 입구에서 서로 다른 컨텍스트 길이를 얻습니다. 그들 각각은 우연이 아니지만 종합하면 반환의 판단을 혼란스럽게 할 것입니다.

가장 먼저 무너진 것은 비교 구경이었습니다.

많은 팀이 먼저 벤치마크 점수에 초점을 맞추겠지만, 점수는 대략적인 능력을 나타내는 데에만 적합할 뿐, "현재 동작이 여전히 이전 프로세스를 따를 수 있는지 여부"를 설명하는 데는 적합하지 않습니다. 온라인으로 전환할 실제 장소는 모델이 단독으로 실행되는 것이 아니라 파서, 도구 호출, 재시도, 캐싱, 감사 및 라우팅과 함께 작동하는 것입니다. 링크 중 하나의 구경이 변경되는 한 점수는 참조 의미를 잃습니다.

가장 일반적인 상황은 평가 세트에서는 아무런 문제도 볼 수 없지만 체인이 온라인에서 떨어지기 시작하는 것입니다. 테스트 샘플은 충분히 깨끗하고 모델은 질문에 매우 잘 대답합니다. 그러나 실제 입력이 수신되면 소량의 필드 드리프트로 인해 후속 자동화 단계가 편향될 수 있습니다. 결과는 "모델을 계속 사용할 수 있습니다"처럼 보이지만 실제로는 "비교 방법이 실패했습니다"를 의미합니다.

기준선은 워크플로에 따라 저장되어야 합니다.

이러한 변경을 억제하기 위해 우리는 더 많은 목록을 실행하는 것이 아니라 기준을 재생 가능한 워크플로로 만드는 데 의존합니다. 입력에는 버전이 있어야 하고, 출력에는 스키마가 있어야 하며, 도구 응답은 재생 가능해야 하며, 실패한 샘플은 원래 컨텍스트를 유지해야 합니다. 그래야만 다른 모델, 다른 지역, 다른 전략으로 전환한 후 편차가 모델 자체에 있는지, 앞뒤 링크에 있는지 알 수 있습니다.

이러한 유형의 기준선은 점수와 결론만 저장하는 것을 가장 두려워합니다. 점수는 사람들을 위로하는 데 사용되고 결론은 보고서 작성에 사용되지만 실제로 유용한 세부 사항은 누락되어 있습니다. 나중에 제한이 강화되면 팀에서는 샘플 보충, 구경 리필, 비정상 경계 리필만 할 수 있습니다. 이는 한 번에 완료할 수 있었던 비교 작업을 여러 차례의 재작업으로 세분화하는 것과 같습니다.

마이그레이션의 실제 비용은 신뢰를 다시 확립하는 것입니다.

모델이 제한된 후 마이그레이션 작업은 사용 가능한 항목으로 변경하는 것처럼 보이지만 실제로는 "이 프로세스가 비교적 안정적"이라는 자신감을 다시 확립하는 것입니다. 신뢰는 한 번의 성공적인 호출로 구축되는 것이 아니라 반복적으로 확인할 수 있는 일련의 비교 결과로 구축됩니다. 이 결과 집합이 없으면 과거로 변경한 경우에만 일시적으로 실행 가능합니다. 이 결과 집합을 과거로 변경하면 제어 가능한 범위 내에 있게 됩니다.

표면적으로는 교체를 완료한 팀도 있지만, 내부적으로는 감히 용량을 늘리기까지는 아직 오랜 시간을 기다려야 하는 이유다. 실제로 막힌 것은 액세스 작업이 아니라 누구도 감히 대답할 수 없다는 것입니다. 이전 프로세스에서 가장 중요한 경계가 새 모델에서도 여전히 유효한지 여부입니다. 이 질문에 대한 명확한 답변이 없는 한 "이전이 완료되었습니다"라는 진술은 단지 단계적인 진술일 뿐입니다.

테스트에 적합한 부품만 재구축할 가치가 있습니다

모든 시나리오가 회귀 체인을 너무 무겁게 만들 가치가 있는 것은 아닙니다. 임시 대화, 경량 생성, 일회성 요약은 경계가 느슨하고 과도한 구성은 시간 낭비입니다. 그러나 모델이 코드 생성, 정보 추출, 라우팅 결정 및 도구 실행에 참여하기 시작하자마자 회귀 판단은 더 이상 액세서리가 아니라 작업 흐름의 일부가 됩니다.

외부 제약으로 인해 이러한 차이가 확대될 수 있습니다. 계속 사용할 수 있는지 여부는 일반적으로 가장 표면적인 계층에 불과합니다. 팀이 안정적일 수 있는지 여부를 결정하는 것은 새로운 결과를 이전 기준과 비교하여 다시 적용할 수 있는 안정적인 방법이 있는지 여부입니다. 일단 비교가 이루어지면 마이그레이션은 단지 엔지니어링 문제일 뿐입니다. 비교가 실패하면 이후의 모든 판단이 흔들리기 시작합니다.