불확실성을 중심으로 한 AI 탐지 보고서 구축하기

AI 탐지(AI detection)는 지나치게 단순화하기 쉬운 매력적인 제품 카테고리입니다.

사용자가 텍스트를 제공하면, 모델은 확률을 제공합니다. UI는 이를 쉽게 빨간색 라벨, 초록색 라벨, 그리고 잘못된 확신(false sense of certainty)으로 바꿀 수 있습니다.

그것이 바로 제가 붙여넣은 텍스트와 호환 가능한 문서들을 위한 작은 Next.js 탐지 워크플로우인 Detector de IA를 작업하면서 피하고자 했던 제품 설계상의 실수입니다. 구현상의 질문은 단순히 "어떻게 탐지기를 호출할 것인가?"가 아니었습니다. 그것은 "어떻게 저자성을 증명하는 척하지 않으면서 결과를 유용하게 만들 것인가?"였습니다.

이 글은 AI의 도움을 받아 초안을 작성하였으며, 현재의 코드베이스 및 주제 제약 사항에 따라 수동으로 검토되었습니다.

핵심 구조는 보고서 파이프라인(Report Pipeline)입니다

유용한 추상화는 판결 API(verdict API)가 아닙니다. 그것은 보고서 파이프라인(report pipeline)입니다:

텍스트 입력 정규화 (Normalize).
소스 유형 보존.
필요 시 문서 텍스트 추출 또는 읽기.
텍스트를 문장 객체(sentence objects)로 분할.
신뢰성을 설명할 수 있는 텍스트 특징(text features) 구축.
탐지 실행.
하이라이트를 다시 문장에 정렬.
보고서와 함께 한계점(limitations) 반환.

이러한 구조가 중요한 이유는 AI 탐지 결과는 사용자가 그것이 어떻게 생성되었는지 검사할 수 있을 때에만 유용하기 때문입니다. 단일 점수는 표시하기 쉽지만, 신중한 결정을 내리기 위한 문맥(context)으로는 충분하지 않습니다.

현재의 보고서 유형은 다음과 같은 문맥을 함께 유지합니다: 로캘(locale), 소스 유형, 모델, 판결(verdict), 위험도(risk), 신뢰성 근거, 점수, 요약, 분석 불렛 포인트, 문장 하이라이트, 한계점, 텍스트 특징, 소스 텍스트, 그리고 문장들.

문서 처리는 신뢰 경계(Trust Boundary)를 변화시킵니다

붙여넣은 텍스트는 직접적입니다. 문서는 그렇지 않습니다.

PDF 및 DOCX 입력의 경우, 브라우저 측 추출 흐름(browser-side extraction flow)이 분석 전에 파일을 읽습니다. PDF 추출에는 pdfjs-dist를 사용하고, DOCX 추출에는 Mammoth 브라우저 패키지를 사용합니다. 추출된 텍스트는 정규화되며, 추출 내용이 비어 있는 경우 조용한 저품질 보고서 대신 명시적인 "읽을 수 있는 텍스트 없음" 오류가 발생합니다.

TXT와 Markdown은 다르게 처리됩니다. 서버 측 업로드 경로(upload path)는 직접적인 텍스트 형태의 포맷은 수락하지만, 지원되지 않는 직접 업로드는 거부하며, 일반 텍스트(plain text)를 읽고 정규화한 뒤 파일 이름과 함께 소스 유형(source type)을 반환합니다.

이러한 구분은 제품 내에서 가시화할 가치가 있습니다. 탐지기(detector)는 객체로서의 "PDF"를 판단하는 것이 아닙니다. 추출 과정을 통과한 텍스트를 판단하는 것입니다. 스캔본, 표(table), 보호된 파일 또는 특이한 레이아웃으로 인해 불완전한 텍스트가 생성된 경우, 보고서는 사용자가 결과값을 과도하게 신뢰하도록 유도해서는 안 됩니다.

문장 객체(Sentence Objects)는 가공되지 않은 하이라이트 문자열보다 유용합니다

한 가지 실질적인 설계 세부 사항은 보고서를 구축하기 전에 텍스트를 문장 객체(sentence objects)로 변환하는 것입니다.

각 문장은 ID, 텍스트, 그리고 글자 수(character count)를 가집니다. 이는 이후 단계에서 참조할 수 있는 안정적인 대상을 제공합니다. 만약 탐지기가 하이라이트된 텍스트 스니펫(snippets)을 반환하면, 애플리케이션은 해당 스니펫을 문장 ID와 다시 정렬하여 사용자에게 신호(signal)가 어디에서 나타났는지 보여줄 수 있습니다.

이는 단순히 "이것은 78% AI입니다"라고 보여주는 것보다 더 나은 사용자 경험(UX)을 제공합니다. 이를 통해 검토자는 다음과 같은 구체적인 질문을 던질 수 있습니다.

어떤 문장이 주의를 끌었는가?
주변 문장과 비교했을 때 어휘(wording)가 변하는가?
해당 구절이 일반적인가, 근거가 없는가, 아니면 단순히 격식적인(formal) 것인가?
원본 문서의 추출 방식이 특이한 어휘를 설명해 주는가?

문장 수준의 하이라이트(highlighting)는 한계를 정직하게 명시하기에도 더 용이합니다. 즉, 문서 업로드의 경우, 하이라이트는 보고서에 표시된 추출된 텍스트를 기준으로 정렬됩니다.

신뢰성에는 확률뿐만 아니라 기능(Features)이 필요합니다

구현 단계에서는 텍스트 특징 요약(text feature summary)도 구축합니다. 여기에는 글자 수, 문장 수, 단락 수, 평균 문장 길이, 문장 길이 분산(variance), 짧은 문장 및 긴 문장의 비율, 글자 다양성, 반복 구간 비율, 문장 부호 다양성, 그리고 일반적 표식(generic-marker) 사례가 포함됩니다.

이러한 특징(features)들이 탐지(detection)를 대체하는 것은 아니지만, 왜 증거가 강력하거나 약할 수 있는지 설명하는 데 도움을 줍니다.

예를 들어, 단 몇 문장으로 구성된 짧은 샘플은 비교할 수 있는 내부 리듬(internal rhythm)이 적습니다. 문장의 다양성이 더 많은 긴 문서는 보고서에 더 많은 질감(texture)을 부여합니다. 반복되는 세그먼트(segments)와 일반적인 마커(markers)는 분석 항목을 뒷받침할 수 있는 반면, 적은 문장 수는 신뢰성 노트(reliability note)를 약화시킬 수 있습니다.

이것이 바로 AI 기능이 마땅히 가져야 할 수준보다 더 자신만만하게 들리지 않도록 유지해 주는 제품 디테일(product detail)입니다.

폴백 경로(Fallback Path)는 그것이 폴백임을 인정해야 합니다

탐지기(detector)는 서버 런타임(server runtime)으로부터 기본 탐지 서비스(primary detection service)를 사용할 수 있습니다. 만약 해당 서비스가 성공적으로 응답하지 않으면, 보고서는 로컬 텍스트 패턴 신호(local text-pattern signals)로 폴백(fallback)할 수 있습니다.

중요한 부분은 단순히 폴백을 갖는 것이 아닙니다. 요약(summary)과 한계점(limitations) 섹션에 해당 내용이 폴백임을 명시하는 것입니다. 백업 추정치(backup estimate)는 연속성을 위해 유용하지만, 기본 탐지기 응답(primary detector response)과 동일한 신호인 것처럼 가장해서는 안 됩니다.

이 패턴은 많은 AI 제품 작업에 적용됩니다. 성능 저하(degradation)는 괜찮지만, 보이지 않는 성능 저하는 괜찮지 않습니다.

제약 사항(Constraints)은 제품 카피(Product Copy)에 포함되어야 합니다

주제 제약 사항(topic constraints)은 시스템 동작의 일부이지, 하단에 숨겨두어야 할 법적 문구(legal copy)가 아닙니다.

이 워크플로(workflow)의 경우, 텍스트는 300자에서 100,000자 사이여야 합니다. 호환 가능한 파일은 12MB 미만이어야 합니다. 요청은 속도 제한(rate-limited)이 걸릴 수 있습니다. 오탐(false positives)과 미탐(false negatives)은 예상되는 한계점입니다. 보고서는 학술적, 고용, 법적 또는 징계 결정의 유일한 근거가 되어서는 안 됩니다.

그러한 제약 사항들은 제품을 덜 극적으로 만들지만, 더 사용 가능하게(usable) 만듭니다. 이는 사용자에게 출력값을 어떻게 해석해야 하는지 가르쳐 줍니다.

다른 AI 도구에서 재사용할 만한 것들

동일한 패턴은 AI 탐지 이외의 분야에서도 유용합니다:

가공되지 않은 성공 지표(raw success metric)를 "증거(proof)"라는 언어와 분리할 것;
소스 유형(source type)과 변환 경로(transformation path)를 보존할 것;
특정 텍스트 구간(text spans)이나 레코드(records)에 설명을 첨부할 것;
한계점(limitations)을 일급 객체 보고서 필드(first-class report fields)로 반환할 것;
폴백 동작(fallback behavior)을 가시화할 것;
사용자의 다음 검토 단계(next review step)를 중심으로 UI를 설계할 것.

목표는 단순히 시스템이 불확실해 보이도록 만드는 것이 아닙니다. 목표는 불확실성을 운영 가능하게 (operational) 만드는 것입니다. 검토자는 보고서를 확인한 후 다음에 무엇을 점검해야 할지 알고 있어야 합니다.

Detector de IA는 스페인어 AI 텍스트 및 문서 검토를 위해 이러한 태도를 소규모로 구현한 사례입니다:

https://detector-de-ia.net/