AI 출처 증명 확인(Provenance Checks) 구축하기: '알 수 없음'을 말할 수 있는 방법

OpenAI의 10월 5일 텍스트 출처 증명 발표는 빌더들에게 유용한 프롬프트입니다. 이 텍스트Grain 워터마크는 적격한 모델 출력물에 통계적 신호를 삽입합니다. API 고객들은 선택된 모델에 대해 옵트인할 수 있으며, EU 내의 적격 ChatGPT 및 Codex 텍스트가 앞으로 몇 주 동안 이를 받게 될 예정입니다. 감지기(Detector) 접근은 모든 제품이 호출할 수 있는 공개 엔드포인트가 아니라 승인된 연구원과 전문가 조직부터 시작됩니다.

여기서 얻을 수 있는 공학적 교훈은 이 출시보다 더 광범위합니다: 출처 신호는 의사 결정 워크플로우 내의 한 가지 관찰일 뿐입니다. 만약 데이터 모델이 그 관찰을 written_by_ai: true 또는 written_by_human: true로 변환한다면, 이미 출처가 경고하는 불확실성을 잃어버린 것입니다.

포착(Capture), 신호(Signal), 결정(Decision) 분리하기

저는 출처 증명 검토를 세 개의 연결된 레코드로 모델링할 것을 제안하며, 각각은 다른 역할을 가집니다.

포착 (Capture): 문서가 생성될 때 워크플로우가 알고 있던 내용을 기록합니다. 여기에는 버전 해시(version hash), 허용되는 AI 사용에 대한 정책, 저자 선언, 그리고 자료 주장에 사용된 참고 문헌이 포함됩니다. 해시는 검토 중인 버전을 식별하지만, 누가 작성했는지는 증명하지 않습니다. 가능하다면 버전 이력 링크를 유지하세요.

신호 (Signal): 실제로 어떤 확인(check)을 관찰했는지 기록합니다. 여기에는 해당 확인이 적용 가능했는지 여부도 포함됩니다. 워터마크 관찰에는 제공자, 방법 버전, 날짜, 입력 버전 및 알려진 한계가 필요합니다. not_detected는 인간의 저작권을 진술하는 것이 아니라 검사에 대한 결과입니다. not_run, unsupported, 그리고 inconclusive도 유용한 상태들입니다.

결정 (Decision): 사람이 증거를 가지고 무엇을 했는지 기록합니다. 어떤 주장이 확인되었는지, 누가 검토했는지, 작업이 승인되었는지 아니면 수정이 필요한지, 그리고 그 이유는 무엇인지가 포함됩니다. 증거가 불완전할 경우 결정은 보류 상태로 남아 있을 수 있습니다.

다음은 OpenAI API 응답이 아닌 제안된 내부 구조입니다:

{
  "document_version": "sha256:...",
  "declared_ai_use": "unknown"
}

이 예시는 실행되지 않았고 결정도 내려지지 않은 검사 기록을 담습니다. 다른 가능한 검사 결과로는 detected(탐지됨), not_detected(탐지되지 않음), 그리고 inconclusive(결정 불가)가 있습니다. 정확한 필드는 다를 수 있습니다. 핵심 속성은 증거가 누락된 상태로 유지된다는 것입니다. 하위 대시보드는 절대 not_detected를 “사람이 작성함”으로, 또는 detected를 부정행위로 재분류해서는 안 됩니다.

인터페이스에서 한계를 보이게 하기

OpenAI에 따르면 텍스트 워터마크는 사용자를 식별하거나, 인간의 기여도를 측정하거나, 소유권이나 책임을 확립하거나, 정확성을 검증할 수 없습니다. 또한 탐지된 워터마크가 반드시 인간 저작권을 증명하는 것은 아니라고 합니다. 편집, 번역, 짧은 구절, 오래된 출력물, 그리고 지원되지 않는 모델 모두 탐지를 복잡하게 만들 수 있습니다.

자사 평가 결과는 왜 자격(qualification)이 중요한지 보여줍니다. 한 테스트에서 400 토큰 분량의 영어 구절에 대해 단어의 10%를 동의어로 대체했을 때 탐지율이 약 92%에서 66%로 감소했고, 25%를 대체했을 때는 17%로 감소했습니다. 이것들은 특정 조건 하에 회사에서 보고한 결과일 뿐이며, 모든 문서에 적용할 수 있는 필드 벤치마크가 아닙니다.

결과 옆에 범위를 보여주세요. 빨간색 또는 초록색 배지만 표시하는 인터페이스는 과신하는 결정을 유도합니다. 검토 화면은 입력 버전, 방법의 적격성 여부, 관찰된 결과, 그리고 그 결과가 무엇을 확립할 수 없는지를 보여줘야 합니다. 도구가 확률이나 점수를 반환한다면, 숨겨진 임계값을 통해 판결로 변환하기보다는 그 의미와 보정(calibration)을 유지해야 합니다.

결과를 중요한 사람에게 라우팅하기

가상의 정책 메모를 고려해 봅시다. 팀은 공개된 AI 지원을 허용하며 정확한 주장과 지정된 승인자를 필요로 합니다. 탐지된 워터마크는 이 메모가 어떻게 작성되었는지 질문할 근거를 제공할 수 있습니다. 하지만 이 메모의 출처가 그 권장 사항들을 뒷받침하는지는 팀에게 알려줄 수 없습니다.

검토 대기열(review queue)에는 메모 버전, 선언문(declaration), 출처 링크(source links), 그리고 이전 편집 기록이 모두 모여야 합니다. 검토자는 그 후 중요한 주장을 확인하고, 누락된 맥락을 요청하며, 결정을 기록할 수 있습니다. 만약 결과가 개인의 평판이나 기회에 영향을 미칠 수 있다면, 증거를 설명하고 오류를 수정하는 방법을 포함해야 합니다. 탐지기 콜백(detector callback)의 자동 출력으로 불리한 조치를 취해서는 안 됩니다.

워터마크 탐지기 없이도 이 대기열을 구축할 수 있습니다. 사실 현재 접근 제한 때문에 많은 팀이 그렇게 해야만 합니다. 신호가 이용 불가능할 때에도 캡처 및 검토(Capture and review) 기능은 여전히 유용하며, 접근성이 확대되더라도 그 중요성은 계속 유지될 것입니다.

분류기뿐 아니라 워크플로우를 테스트하세요

자체 승인된 자료에 대한 출처 신호(provenance signal)를 평가할 수 있다면, 깨끗하고 편집되었으며 짧고 번역되었고 제약이 있는 예시들을 포함해야 합니다. 예시는 튜닝 세트(tuning set) 외부에 보관하세요. 오탐지율(false alarms), 놓친 신호(missed signals), 불확실한 사례(inconclusive cases), 검토자 시간, 그리고 그에 따른 결정들을 측정하세요. 결과는 콘텐츠 유형별로 분리해야 합니다. 전체 비율 하나로는 제품이 취약하게 처리하는 사례들을 숨길 수 있기 때문입니다.

점수를 보기 전에 각 결과에 대한 제안된 조치(proposed action)를 작성하세요. “뒷받침 기록 요청”은 “작업 거부”와는 다른 결과입니다. 이러한 조치들에 필요한 증거 또한 달라야 합니다. 방법의 범위가 불분명할 때 일시 중지하는 것이 가능하도록 만드세요.

저의 첫 번째 구현 단계는 문서 버전 기록(document-version record)과 명시적인 알 수 없음(unknown) 상태를 가진 작은 검토 양식일 것입니다. 그런 다음 팀이 어떤 주장을 누가 승인했는지, 그리고 무엇이 그것을 뒷받침하는 출처였는지에 답할 수 있는지 테스트할 것입니다. 탐지기는 나중에 추가 관찰 사항으로서 평가될 수 있습니다. 이 시스템은 증거를 보존하고 불확실성을 가시화할 수 있게 되는 순간부터 유용합니다.