점수를 검증 가능한 결정으로 바꾸기.

요약하기 전에 출력을 보관하기

분석은 입력, 레퍼런스, 예측의 조인부터 시작합니다. 기대하는 각 식별자가 정확히 한 번씩 나타나는지 확인하세요. 오답과 미완료 요청, 중복, 판독 불가능한 출력을 구분하세요. 이 문제들은 해결책이 다르며, 평균을 계산할 때 사라져서는 안 됩니다.

원시 출력을 정규화된 버전, 모델 리비전, 프롬프트, 설정, 판정 사유와 함께 보관하세요. 모호한 날짜를 조용히 변환하는 과정은 인위적인 성공을 만들어낼 수 있습니다. 검증 세트에서 탐색을 시작하세요. 최종 테스트 세트가 다음 수정 사항을 고안하는 데 사용된다면, 별도로 보관한 새로운 확인이 필요합니다.

기술 출처: scikit-learn 1.9 — 모델 선택에서 테스트를 분리하기

도수와 함께 혼동 행렬 읽기

각 항목당 하나의 범주로 분류하는 경우, 혼동 행렬은 레퍼런스 클래스와 예측 클래스를 교차시킵니다. 여기와 scikit-learn에서 사용하는 관례에서는 행이 레퍼런스를, 열이 예측을 나타냅니다. 정규화하기 전에 원시 도수를 보관하세요: 예시 수 없이 백분율만 보면 결론의 견고함을 과장할 수 있습니다.

다음 예시는 가상의 예이며 순전히 산술적인 계산입니다. 백 개의 티켓이 청구서, 접근, 삭제로 나뉩니다. 대각선에는 54 + 24 + 5 = 83개의 정답이 있으며, 이는 83%입니다. 이 합계는 삭제 클래스를 가립니다. 예상되는 10개의 티켓 중 5개만 인식됩니다. 어떤 모델이나 GPU도 이 수치를 산출하지 않았습니다.

기술 출처: scikit-learn 1.9 — 혼동 행렬 정의

정밀도, 재현율, 실질적 결과 연결하기

삭제의 경우 정밀도는 5/8 = 62.5%입니다. 즉 이 범주로 분류된 티켓 중 다섯 개가 정확합니다. 재현율은 5/10 = 50%입니다. 즉 이 범주 티켓의 절반이 검출됩니다. F1은 2 × 5 / (2 × 5 + 3 + 5)로, 약 55.56%입니다. 세 개의 오탐과 다섯 개의 미탐은 서로 다른 문제를 나타냅니다.

청구서, 접근, 삭제 클래스의 F1은 각각 88.52%, 80%, 55.56%입니다. 이들의 비가중 평균인 매크로 F1은 약 74.69%입니다. 이는 83%의 정답률을 보완하지만, 도수를 대체하지는 않습니다. 어떤 클래스가 레퍼런스나 예측에서 빠져 있으면 일부 지표는 정의되지 않을 수 있습니다: 이 경우를 평균에 숨기지 말고 사용한 관례를 밝히세요.

기술 출처: scikit-learn 1.9 — 정밀도, 재현율, F1, 평균 및 0 나누기

행동과 연결된 짧은 분류 체계 구축하기

오류 범주는 무엇을 살펴볼지 결정하는 데 도움이 되어야 합니다. 몇 개의 범주, 하나의 정의, 대표적인 예시로 시작하세요. 중복 집계 없이 사례를 세기 위한 주 레이블을 추가하고, 여러 현상이 함께 나타나면 보조 레이블을 추가하세요. 억지로 설명을 붙이기보다는 '검토 필요' 범주를 유지하세요.

이 분류 체계는 작업 제안이지 자동 진단이 아닙니다. 잘린 문서는 참조의 모호성을 포함할 수도 있습니다. 레이블의 빈도는 재검토한 사례를 나타낼 뿐, 아직 원인을 입증하지는 않습니다. 해석을 뒷받침하는 입력 구절을 보존하고, 관찰된 원인, 가설, 누락된 정보를 구분하세요.

추출의 경우 필드와 문서 수를 세기

유효한 JSON 형식이라고 해서 값이 올바르다는 보장은 없습니다. 허용되는 정규화를 정하세요: 표준 날짜 형식, 소수점 구분자, 공백 또는 범주 코드. 누락된 필드, 만들어낸 값, 허용된 보류를 구분하세요. 채우기 비율을 높이기 위해 문서에서 없는 값을 추측으로 대체해서는 안 됩니다.

다음은 분류 표와 독립적인 두 번째 예시 계산입니다. 문서 50개에 각각 기대 필드가 3개씩 있으면 총 150개 값입니다. 38개 문서가 완전히 정확하고, 6개가 두 필드 정확, 6개가 한 필드 정확이라고 가정합시다. 그러면 38 × 3 + 6 × 2 + 6 × 1 = 132개의 정확한 값, 즉 88 %입니다. 그러나 세 필드가 모두 요구된다면 완전히 허용 가능한 문서는 38/50 = 76 %에 불과합니다.

18개의 잘못된 값이 열두 개의 문서에 영향을 미칩니다. 이를 열여덟 개의 결함 있는 문서로 제시하지 마세요. 용도에 따라 유용한 단위는 검증된 필드 하나이거나 완전히 승인된 문서 하나일 것입니다. 비교 전에 이를 정의하세요. 날짜, 금액, 범주 중 어디에서 문제가 발생하는지 알 수 있도록 필드별 결과를 유지하세요.

캠페인을 다시 실행하기 전에 수정 사항 선택

영향을 받는 범위와 결과를 기준으로 우선순위를 정하세요. 단순히 행 수를 기준으로 삼지 마세요. 가상의 매트릭스에서 프로젝트가 해당 범주를 중대한 것으로 정의했다면 삭제 오류 다섯 건이 청구서 오류 여섯 건보다 먼저 검토될 수 있습니다. 이 우선순위는 프로젝트 계약에 속합니다. 표만으로는 업무상 중대성을 임의로 만들어낼 수 없습니다.

검증 가능한 가설을 세우세요: '긴 입력은 준비 과정에서 결정적인 구절을 잃는다.' 이를 살펴볼 수 있는 변경을 선택한 다음 나머지는 일정하게 유지하세요. 예시를 동시에 추가하고, 모델을 바꾸고, 컨텍스트를 늘리면 점수는 향상될 수 있지만, 그 효과를 단일 수정에 귀속시킬 수는 없습니다.

• 기준이 일관되게 적용되는지 확인하기 위해 오류 외에도 몇 가지 성공 사례를 재검토하세요.
• 동일한 식별자와 참조로 변형을 비교하고, 코퍼스의 변경 사항은 별도로 표시하세요.
• 수정된 오류, 지속되는 오류, 새로운 오류, 변경되지 않은 사례를 구분하세요.
• 회귀를 찾기 위해 표적 범주 밖의 예시도 다시 실행하세요.

회귀를 지우지 않고 이득을 확인

짝지은 계산은 순점수가 무엇을 숨기는지 보여줍니다. 가상의 100개 티켓에서 9개의 오류가 수정되었지만 기존의 4개 성공이 오답이 되었다고 가정해 봅시다. 결과는 83에서 83 + 9 − 4 = 88개의 정답으로 바뀝니다. 이득은 5포인트이며, 검토해야 할 4개의 회귀가 있습니다. 이는 9개의 수정이 대가 없이 이루어졌다는 의미가 아닙니다.

결정 노트는 수정 전후 표, 수정된 사례, 새로 생긴 오류, 수정 버전, 통과한 기준을 보존합니다. 치명적인 규칙이 여전히 위반된다면 평균이 더 높다는 이유만으로 그 변형을 채택할 수는 없습니다. 그런 다음 비용과 소요 시간을 허용 가능한 옵션들 사이에서 비교합니다. 이미 거부된 결과의 속도를 높인다고 해서 품질 문제가 해결되지는 않습니다.

결론을 검토한 범위로 한정하기

눈에 띄는 오류가 반드시 대표성을 갖는 것은 아닙니다. 긴 입력이나 드문 범주의 실패를 주로 다시 읽었다면 그 선택 방식을 밝히고, 그 빈도를 전체 코퍼스의 빈도인 것처럼 제시하지 마세요. 아직 판정하지 않은 사례도 남겨 두세요. 그것이 여러분 평가의 불확실성을 규정합니다.

여러분의 분석은 다른 독자가 입력을 찾아내고, 판정을 이해하고, 제안된 수정을 검증할 수 있을 때 활용 가능합니다. 그것은 생성된 응답의 내부 원인을 증명하지도, 미래의 품질을 보장하지도 않습니다. 수정안을 선택한 뒤에는 따로 보관한 최종 세트로 넘어가고, 한계는 결론과 함께 기록해 두세요.

실용적인 질문