AI 자동 추출이 틀렸을 때: 온톨로지 사람 검수 워크플로

2026년 8월 29일 기준, AI 운영자는 오추출을 값·근거·감사 기록까지 함께 고쳐야 합니다. 원문 확인이 안 되면 보류해야 합니다.

검수 화면에서 승인 상태만 바꾸면 데이터는 고쳐졌지만 원문 근거와 검색 결과는 예전 값을 가리키는 상태가 생깁니다. 사람 검수는 수정·승인·거절·보류마다 어떤 데이터와 증거가 함께 바뀌어야 하는지 정의하는 운영 워크플로입니다.

검수 역할마다 먼저 볼 정보가 다릅니다#

• 운영 검수자는 추출값과 원문 스팬을 한 화면에서 비교하고 수정 이유를 남깁니다.
• 데이터 책임자는 속성 스키마와 엔터티 관계를 바꿀 권한이 검수자에게 있는지 확인합니다.
• AI 제품 책임자는 승인 뒤 검색 인덱스와 후속 처리까지 같은 결정으로 갱신되는지 확인합니다.

검수 유형별 결정은 어떻게 나누나요?#

아래 표는 Ontokit 내부 검수 유형을 참고해 운영 결정을 정리한 알파카랩스의 D등급 관측 가설입니다. 2026년 8월 29일 기준이며, 조직별 권한과 위험 수준에 맞게 조정해야 합니다.

승인 버튼 앞뒤의 데이터 변화를 설계하십시오#

1. 큐 항목에 원문, 추출값, 후보 근거, 우선순위와 담당자를 함께 보여 줍니다.
2. 수정은 허용된 기존 속성만 받으며 스키마 변경과 분리합니다.
3. 편집 승인 때 객체 값, 원문 청크, provenance, 검색 인덱스, 감사 전후값과 후속 이벤트를 함께 갱신합니다.
4. 엔터티 해소 승인은 병합 서비스에 위임하고 거절은 두 객체를 분리해 둡니다.
5. 보류는 데이터 변경 없이 이유와 다음 확인자를 남깁니다.
6. 해결된 항목의 재승인을 막고 일괄 처리에서도 명시적으로 선택한 항목만 바꿉니다.

제품 범위는 Ontokit 소개, 데이터·출처 경계를 먼저 정하는 방법은 ERP 데이터 AI 에이전트 구축 가이드에서 확인할 수 있습니다. 검수 워크플로를 시험 단계의 종료 조건과 연결하려면 AI PoC 종료 기준도 함께 참고하십시오.

내부 구현에서 확인한 검수 경계#

C 자기표기, 2026년 8월 29일 확인. Ontokit 내부 inbox는 낮은 신뢰도, 엔터티 해소 후보, 제약 위반을 구분하고 승인·거절·보류·만료 상태를 기록합니다. 큐는 우선순위와 대기 순서로 정렬하며 유형·상태·담당자 필터와 다음 항목, 일괄 결정을 지원합니다.

낮은 신뢰도 항목의 편집 승인은 기존 스칼라 속성만 반영하고 새 속성 키를 차단합니다. 승인된 수정은 객체 값, 원문 청크, provenance 범위와 검색 임베딩을 갱신하며 리뷰 상태, 감사 전후값과 후속 이벤트를 한 트랜잭션에 묶습니다.

엔터티 해소 후보의 승인은 병합 서비스에 위임하고 거절은 분리 상태를 유지하며 보류는 데이터 변경을 만들지 않습니다. 내부 테스트는 해결된 항목의 재승인 차단, 선택하지 않은 데이터의 자동 폐기 방지와 트랜잭션 경계를 확인합니다. 실제 검수 정확도, 처리량, 평균 처리 시간과 운영 절감 효과는 미확인입니다.

승인 상태만 바꾸면 왜 실패하나요?#

추출값만 고치고 원문 스팬을 그대로 두면 화면과 근거가 어긋납니다. 인덱스를 다시 만들지 않으면 검색은 이전 값을 반환할 수 있습니다. 감사 전후값이 없으면 누가 무엇을 왜 바꿨는지 재구성하기 어렵습니다.

규칙이 안정적이고 잘못 처리해도 즉시 되돌릴 수 있는 항목은 자동 통과시킬 수 있습니다. 다만 실제 결과를 표본 검수하고 오류 유형이 바뀌면 자동 처리 경계를 다시 닫는 절차가 필요합니다.