이 페이지에서
짧은 대답
LLM 회귀 테스트는 시스템 변경 후 알려진 요구 사항 및 실패 사례를 다시 실행합니다. 기계적 계약에 대한 정확한 검사, 의미에 대한 보정된 검토, 가변성이 중요한 경우 반복적인 시도를 사용합니다. 후보자의 결과를 보기 전에 릴리스 차단 조건을 정의하십시오.
무엇을 가져갈 것인가
- 회귀 스위트는 미래의 모든 사례가 아닌 알려진 동작을 보호합니다.
- 결정론적 검증과 시끄러운 판단을 별도로 유지하십시오.
- 도구 및 검색을 포함하여 전체 시스템의 버전을 지정합니다.
출처 확인 . 연구 종합 및 Rubrex 권장 사항. 예제와 지역 실험이 표시되어 있습니다. 이는 클라이언트 결과가 아닙니다.
현재 툴링은 생산 실패를 오프라인 테스트에 연결합니다
LangSmith가 유지 관리하는 평가 문서에는 오프라인 비교, 온라인 평가 및 실패한 생산 추적을 데이터 세트에 추가하는 방법이 설명되어 있습니다. Anthropic의 2026년 지침에서는 더 광범위한 평가 관행 내에서 회귀 제품군에 대해서도 논의합니다. 이는 지원되는 워크플로우이며, 자동화 제품군을 통과하는 것만으로도 릴리스에 충분하다는 증거는 아닙니다.
계층화된 테스트 스위트 구축
Rubrex는 출력 형태, 필수 필드, 허용된 식별자, 권한 적용 및 정확한 계산과 같은 빠른 결정론적 검사부터 시작할 것을 권장합니다. 증거 지원 또는 작업 완료와 같은 요구 사항에 대한 의미 체계 검사를 추가합니다. 통합 동작에 대해 더 작은 규모의 완전한 워크플로 테스트 세트를 유지하십시오.
그레이더를 종속성으로 취급합니다. 프롬프트나 모델을 변경하면 애플리케이션이 변경되지 않은 경우에도 점수가 이동할 수 있습니다. 후보 및 기준과 함께 그레이더 구성을 저장합니다. 의미 체계 검사가 불안정한 경우 자동 릴리스 차단기로 만들기 전에 신뢰성을 조사하십시오.
평균이 변명할 수 없는 실패를 정의하세요
명백히 수용할 수 없는 결과에 대해 하드 게이트를 선택하고 이를 품질 추세와 분리합니다. 예를 들어, 잘못된 응답은 산문 품질에 관계없이 통합 계약에 실패할 수 있습니다. 약간의 평균 개선이 승인되지 않은 상태 변경을 보상해서는 안 됩니다.
결론이 나지 않은 결과에 대한 프로세스를 유지하세요. 작고 잡음이 많은 표본의 한계 차이는 강제 통과 또는 실패보다는 더 많은 증거를 정당화할 수 있습니다. 소유자, 결정 및 후속 작업을 기록합니다. 릴리스 프로세스는 임의의 임계값을 확실성으로 인코딩하는 대신 불확실성을 가시화해야 합니다.
예시: 스키마 변경으로 인해 이전 작업이 중단됨
팀이 생성된 출력에 필수 필드를 추가합니다. 새로운 예제는 통과하지만 이전 작업 변형에서는 이를 채우는 데 필요한 정보가 생략됩니다. 모델은 스키마를 만족시키기 위해 값을 만들어냅니다. 구조적 테스트는 통과하지만 의미론적 요구사항은 실패합니다.
제품 계약에 따라 알 수 없거나 사용할 수 없는 정보를 명시적으로 허용하는 경우를 추가합니다. 스키마와 의미를 함께 테스트해 보세요. 다음 스키마 변경 시 지원되는 사용 사례를 자동으로 좁힐 수 없도록 이전 작업 변형을 보존합니다.
실행을 재현 가능하게 유지하고 오류를 조치 가능하게 유지
적절한 데이터 제어를 사용하여 데이터 세트 버전, 모델 식별자, 프롬프트, 검색 스냅샷, 도구 구성, 출력, 심판 결정 및 오류 로그를 저장합니다. 반복 중에 가장 작은 유용한 제품군을 실행하고 출시 전에 더 광범위한 결정을 내리세요. 사고가 발생한 후 검토된 회귀 사례를 추가하고 제안된 수정 사항이 일반화되는지 테스트합니다.
- 알려진 고장과 대표적인 일상사례를 보관합니다.
- 환경 실패와 작업 실패를 버리지 않고 구별합니다.
- 실패한 테스트를 업데이트하거나 제거하려면 증거가 필요합니다.
- 알려진 회귀를 넘어서는 주장에 대한 보류 세트를 유지합니다.
변경 사항 출시 전 LLM 테스트 및 즉각적인 평가
LLM 테스트는 문구 변경 후에도 유지되는 요구 사항으로 시작됩니다. 프롬프트 평가에서는 동일한 입력에 대해 이전 프롬프트와 새 프롬프트를 실행하고 가능한 경우 모델, 도구 및 검색 설정을 고정된 상태로 유지합니다. 먼저 정확한 요구 사항을 채점한 다음 보정된 기준표를 사용하여 의미적 차이를 검사합니다. 시스템의 여러 부분이 변경된 경우 결과를 프롬프트에만 귀속시키기보다는 엔드투엔드 비교로 표시하십시오.
LLM 테스트 체크리스트의 경우 Rubrex는 일상적인 사례, 알려진 실패, 불완전한 입력, 종속성 실패 및 거부하거나 전달해야 하는 사례를 권장합니다. 어떤 검사가 실행되었는지, 어떤 검사가 결론에 이르지 않았는지, 어떤 증거가 공개를 정당화하는지 기록합니다. 확인된 생산 실패를 예상 결과가 포함된 검토된 회귀 사례로 변환합니다.
증거의 한계
자동화된 제품군은 불완전하거나, 조정으로 인해 오염되거나, 외부 종속성으로 인해 영향을 받을 수 있습니다. 제안된 게이트는 실제 제품에 맞게 조정되어야 합니다. 회귀 테스트 통과는 테스트된 동작에 대한 증거이지 일반적인 신뢰성을 보장하는 것은 아닙니다.
일반적인 질문
모든 즉각적인 변경이 평가를 실행해야 합니까?
릴리스 결정에 대한 광범위한 검증을 통해 가능한 효과와 관련된 검사를 실행합니다. 작은 문구 변경으로 인해 행동이 바뀔 수 있습니다.
불안정한 의미 테스트를 무시할 수 있나요?
가변성이 응용 프로그램, 채점자 또는 환경에서 비롯되는지 조사합니다. 이를 반복적으로 무시하면 불확실성이 해결되기는커녕 숨겨집니다.
출처 및 추가 자료
이 브리핑의 주요 출처. 출처의 조사 결과는 자체 연구 조건에 적용됩니다. arXiv에 게시한다고 해서 동료 평가가 이루어지지는 않습니다.
- LangSmith 평가 랭체인 · 생활 참고서 · 유지 문서검토됨: 평가개요. 액세스됨 2026년 9월 25일.
- AI 에이전트에 대한 평가 이해하기 인류 · 2026 · 엔지니어링 지도검토됨: 기술 기사. 액세스됨 2026년 9월 25일.
질문이나 수정사항이 있으신가요? Rubrex에 쓰기. 편집 접근 방식을 읽어보세요.