OCR·레이아웃 기반 문서 정보 추출

앞 노트는 수많은 문서를 색인으로 흘려보내는 흐름이었습니다. 이 노트는 문서 한 건을 깊게 읽는 일입니다. 둘째 노트에서 가른 짝 — 여럿 중에서 고르면 Search, 한 건 안에서 뽑으면 Content Understanding — 의 뒤쪽을 여기서 구성합니다. 시험은 「이 문서에서 무엇을 어떤 꼴로 꺼내야 하는가」를 주고 분석 방식·출력 형식·검토 기준을 고르게 합니다.

OCR과 레이아웃 분석

읽기

OCR은 이미지 속 글자를 텍스트로 바꾸는 일입니다. 결과는 단순한 문자열이 아니라 쪽마다 줄과 낱말의 목록이고, 낱말마다 신뢰도(0~1)와 위치를 나타내는 다각형 좌표가 붙습니다. 인쇄체와 손글씨를 함께 읽고, 한 문서에 여러 언어가 섞여도 읽습니다. 「문서에서 글자만 빠르게 뽑으면 된다」는 요구라면 OCR만 하는 읽기 분석이 가장 가볍고 쌉니다.

레이아웃

레이아웃 분석은 OCR 위에 문서의 구조를 얹습니다. 글자가 어디 있는지에 더해 그것이 무엇인지 — 제목인지, 본문 문단인지, 표의 칸인지 — 를 알려 줍니다.

읽기와 레이아웃을 가르는 질문은 「구조가 필요한가」입니다. 영수증 사진에서 합계 금액 하나를 찾는 일과, 50쪽짜리 계약서의 조항 표를 행 단위로 비교하는 일은 다른 분석을 부릅니다.

표와 그림

표 구조

표는 칸의 목록으로 나옵니다. 칸마다 행 번호·열 번호·내용이 있고, 여러 행이나 열을 차지하는 병합 칸에는 행 범위·열 범위가 붙습니다. 머리글 칸에는 그것이 머리글이라는 표시가 따로 붙어, 머리글을 키로 삼아 값을 꺼낼 수 있습니다. 쪽을 넘어가는 표는 쪽마다 따로 잡힐 수 있어서, 머리글이 같은 표를 이어 붙이는 후처리가 필요할 때가 있습니다.

from azure.identity import DefaultAzureCredential
from azure.ai.documentintelligence import DocumentIntelligenceClient
from azure.ai.documentintelligence.models import AnalyzeDocumentRequest, DocumentContentFormat

client = DocumentIntelligenceClient(
    endpoint="https://my-foundry.cognitiveservices.azure.com",
    credential=DefaultAzureCredential(),
)
poller = client.begin_analyze_document(
    "prebuilt-layout",
    AnalyzeDocumentRequest(url_source="https://contoso.blob.core.windows.net/docs/policy.pdf"),
    output_content_format=DocumentContentFormat.MARKDOWN,
)
result = poller.result()

for table in result.tables:
    print(f"표 {table.row_count}행 × {table.column_count}열")
    for cell in table.cells:
        if cell.kind == "columnHeader":
            print("  머리글:", cell.column_index, cell.content)

body = [p.content for p in result.paragraphs
        if p.role not in ("pageHeader", "pageFooter", "pageNumber")]

위는 Foundry Tools 중 문서 구조 분석에 특화된 Document Intelligence의 레이아웃 모델을 부르는 조각입니다. 분석은 시간이 걸리는 작업이라 호출하면 곧바로 결과가 오지 않고, 작업을 시작한 뒤 끝날 때까지 기다려 결과를 받는 꼴(begin_ + result())입니다.

그림

그림은 영역 좌표와 쪽 번호로 나오고, 캡션이 있으면 함께 잡힙니다. 그림 안 글자는 OCR이 이미 읽었으므로 텍스트에 섞여 들어오지만, 차트의 뜻이나 사진의 내용은 OCR이 말해 주지 않습니다. 그림을 근거로 쓰려면 좌표로 그 영역을 잘라 이미지로 꺼낸 뒤 멀티모달 모델에 설명을 맡기거나, 다음 절의 분석기에 그림 설명을 함께 시킵니다.

Content Understanding 분석기

분석기 구성

분석기는 「이 종류의 콘텐츠에서 무엇을 어떻게 뽑는가」를 저장해 둔 정의입니다. 송장·영수증처럼 흔한 문서에는 미리 만든 분석기가 있고, 우리 문서에 맞는 것이 없으면 기반 분석기를 하나 고르고 그 위에 필드 스키마를 얹어 사용자 정의 분석기를 만듭니다.

{
  "description": "공급 계약서에서 핵심 조건을 뽑는다",
  "baseAnalyzerId": "prebuilt-document",
  "fieldSchema": {
    "fields": {
      "SupplierName":  { "type": "string", "method": "extract",
                         "description": "계약 당사자 중 공급자의 상호" },
      "TermMonths":    { "type": "integer", "method": "extract",
                         "description": "계약 기간(개월)" },
      "PenaltySummary":{ "type": "string", "method": "generate",
                         "description": "위약금 조항을 한 문장으로 요약" },
      "ContractType":  { "type": "string", "method": "classify",
                         "enum": ["구매", "용역", "임대"] }
    }
  }
}

필드마다 방법을 고릅니다. extract는 문서에 적힌 값을 그대로 꺼내고, generate는 문서를 읽고 새 문장을 지으며, classify는 정해 둔 범주 중 하나를 고릅니다. description이 곧 모델에게 주는 지시라, 「금액」보다 「부가세를 포함한 총 계약 금액(원)」처럼 적어야 엉뚱한 숫자를 덜 집습니다.

신뢰도와 근거 위치

추출한 필드에는 신뢰도와 함께 그 값이 문서의 어디에서 왔는지가 붙습니다. 이 둘이 사람 검토로 보낼지를 정하는 근거입니다. 필드마다 문턱값을 두고 그 아래면 검토 대기열로 보내는 구성이 기본형이고, 금액처럼 틀리면 비싼 필드에는 문턱을 높게 둡니다. 한 달에 계약서 2,000건이 들어오고 금액 필드의 8%가 문턱 0.85 아래로 나온다면 사람이 볼 건은 160건이고, 문턱을 올릴수록 이 수가 늘어 비용과 정확도를 맞바꿉니다.

generate로 지은 필드는 원문에 그대로 있는 값이 아니어서 근거 위치가 덜 정확할 수 있습니다. 감사가 필요한 값은 extract로 꺼내는 편이 안전합니다.

멀티모달 파이프라인

분석기는 문서만 받지 않습니다. 이미지·오디오·비디오도 각자의 기반 분석기가 있어, 같은 필드 스키마 방식으로 통화 녹음에서 「고객 불만 유형」을 분류하거나 영상에서 장면별 요약을 뽑습니다. 그래서 멀티모달 문서 파이프라인은 입력 종류마다 다른 도구를 잇는 대신, 종류에 맞는 분석기를 고르고 출력을 같은 필드 꼴로 모으는 설계가 됩니다.

출력 형식

마크다운 출력

분석 결과의 본문은 마크다운으로 받을 수 있습니다. 제목은 #, 표는 표 문법, 그림 자리는 표시로 남아 문서 구조가 텍스트 안에 그대로 실립니다. RAG에 넣을 때 이 형식이 유리한 이유는 둘입니다. 모델이 마크다운의 표와 제목을 잘 읽고, 절 제목을 경계로 조각을 자르면 조각마다 맥락이 살아납니다. 평문으로 받으면 표가 칸 구분 없는 낱말 나열이 되어 「3행 2열의 값」을 모델이 되짚지 못합니다.

구조화 출력

필드 스키마로 뽑은 값은 JSON으로 나옵니다. 마크다운이 사람과 모델이 읽을 본문이라면 구조화 출력은 프로그램이 읽을 값입니다. 계약 기간을 데이터베이스 열에 넣거나 금액으로 조건 분기를 하려면 이쪽이고, 둘을 함께 받아 마크다운은 색인에, 필드는 메타데이터 필드에 넣는 구성이 흔합니다.

그라운딩 표현

정제

에이전트와 RAG에 넣을 근거는 정제된 표현이어야 합니다. 쪽마다 되풀이되는 머리말·꼬리말·쪽 번호를 레이아웃 역할로 걷어 내고, 같은 문단이 여러 쪽에 겹쳐 실린 것은 하나만 남깁니다. 이것을 안 하면 「대외비 — 무단 복제 금지」 같은 줄이 조각마다 섞여 검색 점수를 흐리고, 모델의 컨텍스트를 같은 문장으로 채웁니다.

출처 좌표

정제하면서도 출처를 잃지 않아야 합니다. 조각마다 원본 문서 키·쪽 번호·위치를 메타데이터로 함께 담아 두면, 답에 인용을 달 때 「계약서 7쪽 표 2」처럼 되짚을 수 있고 화면에서 그 영역을 강조할 수도 있습니다. 트레이스·거버넌스 노트에서 본 프로버넌스가 바로 이 좌표 위에 서고, 시험은 「사용자가 답의 근거를 원문에서 확인할 수 있어야 한다」를 이 자리로 묻습니다.

연습 문제

1. 영수증 사진 수만 장에서 글자만 텍스트로 뽑아 보관하려 합니다. 표나 구조는 필요 없습니다. 가장 가벼운 선택은?
   ① 레이아웃 분석
   ② 읽기(OCR) 분석
   ③ 필드 스키마가 있는 사용자 정의 분석기
   ④ 멀티모달 모델에 이미지 설명 요청

   ②. 구조가 필요 없으면 OCR만 하는 분석이 가장 싸고 빠릅니다. ①과 ③은 쓰지 않을 구조와 필드를 위해 비용을 더 냅니다.
2. 모든 조각에 「대외비 — 무단 복제 금지」가 섞여 검색 품질이 떨어집니다. 알맞은 처리는?
   ① 임베딩 차원을 늘린다
   ② 레이아웃의 문단 역할로 머리말·꼬리말을 걷어 내고 색인한다
   ③ 시맨틱 랭커를 끈다
   ④ 조각 길이를 두 배로 늘린다

   ②. 반복되는 머리말·꼬리말은 레이아웃이 역할로 표시해 주므로 그 표시로 걸러 냅니다.
3. 계약서에서 「계약 종류」를 구매·용역·임대 중 하나로 받아야 합니다. 필드의 방법은?
   ① extract
   ② generate
   ③ classify
   ④ 방법 없이 type만 적는다

   ③. 정해 둔 범주 중 하나를 고르게 하는 것이 classify입니다.
4. 송장 3,000건을 처리하는데 금액 필드의 6%가 신뢰도 문턱 아래로 나옵니다. 문턱을 올렸더니 그 비율이 15%가 됐습니다. 사람이 검토할 건은 몇 건 늘었습니까?
   ① 180건
   ② 270건
   ③ 450건
   ④ 630건

   ②. 처음은 3,000 × 0.06 = 180건, 문턱을 올린 뒤는 3,000 × 0.15 = 450건이라 270건이 늘었습니다.
5. RAG 앱이 매뉴얼의 표를 근거로 답하는데 「3행 2열의 값」을 자주 틀립니다. 분석 결과는 평문으로 받아 색인했습니다. 먼저 바꿀 것은?
   ① 출력을 마크다운으로 받아 표 구조를 살린다
   ② 신뢰도 문턱을 낮춘다
   ③ 필드 방법을 generate로 바꾼다
   ④ OCR 언어를 바꾼다

   ①. 평문에서는 칸 경계가 사라집니다. 마크다운 표로 받으면 행과 열이 텍스트 안에 남아 모델이 되짚을 수 있습니다.
6. 감사 부서가 추출된 위약금 금액마다 원문의 위치를 확인할 수 있어야 한다고 요구합니다. 가장 알맞은 구성은?
   ① 위약금을 generate 필드로 요약해 담는다
   ② extract 필드로 꺼내고 근거 위치(쪽·좌표)를 함께 저장한다
   ③ 마크다운 본문만 저장한다
   ④ 그림 영역을 잘라 이미지로 저장한다

   ②. 원문에 적힌 값을 그대로 꺼내는 extract가 근거 위치와 가장 정확히 이어집니다. 지어낸 요약은 원문 한 자리로 되짚기 어렵습니다.
7. 보고서 PDF의 막대 차트가 말하는 추세를 답에 쓰려 합니다. OCR 결과에는 축 이름과 숫자 몇 개만 있습니다. 알맞은 방법은?
   ① OCR 신뢰도 문턱을 낮춘다
   ② 레이아웃의 그림 영역을 잘라 멀티모달 모델이나 분석기에 설명을 맡긴다
   ③ 표 추출 결과에서 찾는다
   ④ 쪽 번호 역할로 걸러 낸다

   ②. OCR은 그림 속 글자만 읽고 그림의 뜻은 말하지 않습니다. 영역을 꺼내 그림을 해석하는 단계가 따로 필요합니다.

이 노트의 문항은 필요한 것만큼만 읽는가로 풀립니다. 글자만이면 OCR, 구조가 필요하면 레이아웃, 정해진 값이 필요하면 필드 스키마이고, 그 결과를 넣는 곳이 사람인지 프로그램인지 모델인지가 출력 형식을 정합니다.