문서에서 정보 추출하기

2.1 문서에서 정보 추출하기

세부 학습 목표

• OCR·레이아웃·필드 추출과 원문·업무 검산의 책임을 구별한다.
• Content Understanding·Document Intelligence를 입력·출력·근거 요구로 비교한다.
• JSON/Markdown analyzer와 시험의 single-task/pro 표현을 현재 GA/Preview API 지원과 대조한다.

개요

• OCR: 문서 이미지에서 문자 인식.
• 레이아웃: 표의 행·열과 문단·위치 관계 파악.
• 필드 추출: 주문번호·수량·금액 등 필요한 값 연결.
• 검증: 원문 일치와 산식·통화·단위 일치를 각각 확인.

스캔 송장을 데이터로 바꾸는 과정

• 스캔 PDF는 화면에 글자가 보여도 텍스트 선택이 되지 않을 수 있습니다.

  먼저 OCR로 문자를 인식한 뒤 문단·표·행·열 같은 구조를 분석합니다. 다음으로 “거래처”, “품목”, “수량”, “합계”의 의미를 정해 필드에 값을 연결합니다.

• 같은 12000이라는 숫자도 단가인지 소계인지 문서의 위치와 표 구조에 따라 의미가 달라집니다.

  문자 추출만 성공했다는 이유로 계산에 바로 넣으면 다른 행의 금액을 결합할 수 있습니다. 문서 처리의 검증 단위는 글자 정확도에서 끝나지 않고 필드·구조·업무 관계까지 이어집니다.

CU와 Document Intelligence를 선택하기

• Document Intelligence는 문서의 OCR·레이아웃과 사전 구축/사용자 지정 모델을 통한 구조·필드 추출을 제공합니다.

  Content Understanding(CU)은 문서뿐 아니라 이미지·음성·영상 분석과 사용자 출력 스키마를 구성하는 흐름을 제공합니다. 입력 종류, 필요한 필드, 구조 보존, 처리 방식과 실제 정확도로 비교합니다.

• 예: 송장의 총액만 필요할 때와 송장·제품 사진을 함께 분석할 때는 비교할 기능이 달라집니다.

  송장만 처리한다면 문서 추출 모델의 결과부터 확인할 수 있습니다. 사진의 제품 상태도 같은 업무 필드로 정리해야 한다면 CU의 해당 입력 지원을 함께 검토합니다. 서비스 이름만으로 결정하지 않고 실제 표본에서 필요한 필드와 근거가 보존되는지 확인합니다.

• CU의 analyzer는 처리할 콘텐츠와 추출 대상·출력 구조 등을 정하는 재사용 가능한 설정입니다.

  아래는 필드 정의의 형태를 보여 주는 구성 예제입니다. 실제 생성 요청에는 선택한 API 버전과 모델 구성 등 공식 문서의 필수 조건을 확인해야 합니다.

{
  "baseAnalyzerId": "prebuilt-document",
  "description": "송장의 공급자와 합계 추출",
  "fieldSchema": {
    "fields": {
      "supplier": {"type": "string", "description": "공급자 이름"},
      "total": {"type": "number", "description": "문서의 최종 합계"}
    }
  }
}

• 필드명과 설명은 어떤 값을 원하는지 구체화합니다.

  값이 없을 때의 표현, 여러 통화가 섞일 때의 처리, 합계가 여러 개일 때의 선택 기준은 앱의 계약에 포함합니다. 생성형 추출이 만든 숫자는 원문과 대조하고 결정적 산식으로 다시 계산합니다.

추출값을 검산하는 예제

다음은 서비스 응답 전체가 아닌, 앱이 받은 추출 필드를 정리한 가상 데이터입니다. 로컬에서 실행할 수 있습니다.

from decimal import Decimal
 
item = {"quantity": "2", "unit_price": "6000", "subtotal": "12000"}
expected = Decimal(item["quantity"]) * Decimal(item["unit_price"])
actual = Decimal(item["subtotal"])
assert expected == actual
print(expected)

• 금액 계산에는 소수점·통화·반올림 규칙을 명확히 둡니다.

  위 검산이 통과해도 원문에서 수량과 단가를 모두 잘못 읽었을 가능성은 남습니다. 원문 일치와 산식 일치는 각각 확인합니다.

JSON·Markdown과 근거 보존

• 정해진 필드 처리에는 JSON 구조가, 본문과 표를 검색 문맥으로 읽는 흐름에는 Markdown 같은 표현이 편리할 수 있습니다.

  어느 형식이든 페이지·구간·원문 위치와 문서 버전을 보존해야 값의 출처를 추적할 수 있습니다. 구조를 평문으로 바꿀 때 표의 열 이름과 단위가 사라지지 않는지도 봅니다.

• 2026년 10월 확인 기준으로 CU의 2025-11-01 API는 GA(일반 공급), 2026-06-01-preview API는 공개 미리 보기입니다.

  문서 분석의 agentic mode와 동기식 Read/Layout(prebuilt-read, prebuilt-layout) 작업은 후자에 속하므로 GA에서 그대로 사용할 수 있는 기능으로 가정하지 않습니다.

• 시험 가이드의 pro mode 표현은 현재 API와 구분해 읽습니다.

  최신 CU 문서는 이전 pro API 종료와 agentic mode 이전을 안내하며 설정과 지원 입력에 차이가 있습니다. 교재의 기본 개념을 익힌 뒤 실습 시점의 GA/preview 버전과 analyzer 지원 조건을 확인합니다.

스캔 PDF와 텍스트 PDF 분류

• 텍스트 레이어가 있는 문서와 이미지로 된 스캔 문서는 입력 구조가 다릅니다.

  OCR은 영상에서 문자를 추정하므로 인식 오류와 표·레이아웃 손실을 검증해야 합니다.

• 상황: 스캔 송장과 검색 가능한 계약서가 같은 파이프라인에 들어옵니다.

• 적용: 스캔 문서는 OCR 단계가 필요할 수 있고 계약서는 기존 텍스트를 활용할 수 있습니다.

  추출 텍스트와 원문 위치·표 구조를 각각 비교해야 합니다.

OCR와 레이아웃 추출 차이

• OCR은 글자 인식이 중심이고 레이아웃 이해는 단락·표·열·위치 관계 등을 다룹니다.

  표가 텍스트만 이어붙은 결과로 바뀌면 원래 행과 열의 관계가 사라질 수 있습니다.

• 상황: 송장에는 세 품목의 수량과 단가가 표로 있습니다.

  추출 텍스트는 모든 수치를 한 줄로 합쳤습니다.

• 적용: 각 품목과 수량·단가의 행 열 관계를 복원하고 원문 표와 대조해야 합니다.

Content Understanding Analyzer 설계

• Azure Content Understanding Analyzer는 입력 유형·필드 스키마·동작 모드를 지정해 구조화된 정보를 얻습니다.

  API 2025-11-01은 GA이며 2026-06-01-preview는 신규 기능을 포함한 미리 보기 버전입니다. 설정·지원 필드·동기 호출·agentic mode 기능을 실제 사용 버전별로 구분하고, 누락된 필드를 임의로 채우지 않습니다.

• 상황: 발주서에서 주문번호·납기·금액을 추출하고 싶습니다.

• 적용: 발주서의 주문번호·납기·금액을 필드 스키마로 정의합니다.

  응답에 필드가 없거나 값이 없으면 앱에서 미확인 상태로 처리하고 임의 값을 채우지 않습니다. 모든 API가 동일한 null 표현을 반환한다고 가정하지 말고, 사용 버전의 응답 계약과 Analyzer 설정을 확인합니다.

• Content Understanding 버전·수명주기 

• Analyzer 설정 

출처 추적과 숫자 검증

• 추출값이 맞는지 검증하려면 최종 JSON만 아니라 어디에서 어떤 문맥으로 나온 값인지 추적 가능해야 합니다.

  숫자·단위·기간은 원문과 계산 규칙을 함께 검사합니다.

• 상황: 주문서의 세 품목은 각각 수량 2·단가 30,000원, 수량 3·단가 20,000원, 수량 1·단가 60,000원입니다.

  모델은 합계 18,000원을 출력했습니다.

• 적용: 2×30,000 + 3×20,000 + 1×60,000 = 180,000원이므로 출력된 18,000원은 오류입니다.

  원본 페이지·품목 행·수량·단가·통화 단위를 함께 보존하고 원문 총액과 계산 결과를 대조합니다.

문서 추출을 RAG·Agent에 연결

• 문서 분석 결과는 RAG 인덱스 또는 에이전트 도구의 입력이 될 수 있습니다.

  원문을 구조화했다고 해서 이후 질문의 권한·적용일·출처 품질을 자동 보장하지 않습니다.

• 상황: 스캔 계약서에서 추출한 조항을 검색 인덱스로 보내 결재 에이전트가 이용합니다.

• 적용: 문서 ID·판본·적용일·조항·페이지·접근 범위와 추출/검증 상태를 함께 전달해야 합니다.

확인 문제

송장 p1:
품목 | 수량 | 단가
볼트 |  2   | 300
너트 |  3   | 100
합계 |      | 900
평탄 OCR: "볼트 너트 2 3 300 100 900"
앱 추출: 볼트 수량=3, 합계=900

분석 결과:
  doc_id=D9 / page=3 / field=total / value=900
  quote="합계 900" / access_group=finance
현재 색인 문서:
  {"body":"합계 900"}
요구: 재무팀만 조회, 답변에서 원문 페이지로 이동

소비자 A: 송장 합계·통화의 타입과 필수 필드 검사
소비자 B: 문단·표 맥락을 검색해 답변하고 원문 인용
CU 결과: 구조화 fields + 문서 Markdown + 원문 위치
현재 변환: fields를 버리고 Markdown만 전달
A 오류: total 필드 없음 / B: 문맥 검색 가능

범위 메모: CU pro mode 항목 포함
현재 확인한 공식 문서: pro API 종료, agentic mode 이전 안내
새 실습 조건: 2026-06-01-preview / 단일 입력 파일
기존 실습: pro API로 파일 3개를 한 번에 제출
요구: 범위 용어 설명 + 현재 실행 가능한 실습

참고 자료

• What is a Content Understanding analyzer? 
• Azure Content Understanding in Foundry Tools document solutions 
• What is the Document Intelligence layout model? 
• Agentic mode for document analysis (preview) 
• What is new in Azure Content Understanding? 

자료 확인: 2026-10-25 · 적용 사례 교정: 2026-10-23. 사례는 교육용이며 Azure API 호출·요금은 실행 검증하지 않았습니다.

가상 청구서의 소계는 10,000원, 세금은 1,000원, 인쇄된 총액은 12,000원입니다. 세 값이 모두 명확히 읽힙니다.