“이 펌프의 허용 압력은 얼마인가요?” 설비 매뉴얼을 넣은 AI에 질문했더니 즉시 숫자를 답합니다. 페이지 링크도 붙어 있습니다. 그런데 원문을 열어보면 AI가 찾은 숫자는 다른 모델의 열에 있고, 단위는 바로 위 머리글에만 적혀 있습니다. 숫자를 정확히 읽고도 답은 틀린 셈입니다.
문서 AI를 구축할 때 이런 오류는 생각보다 자주 일어납니다. PDF는 사람이 보기 쉽게 배치된 문서이지, AI가 읽기 좋은 데이터베이스가 아닙니다. 표의 행·열 관계, 도면과 캡션, 본문과 주석, 페이지를 넘기는 표의 연결이 텍스트 추출 과정에서 흐트러질 수 있습니다. 설비 매뉴얼, 전기 도면, 시험 성적서, 견적서처럼 숫자와 구조가 중요한 문서에서는 작은 위치 오류가 실무 판단을 바꿉니다.
이번 글은 기존의 기업 지식 검색에서 한 단계 더 들어갑니다. 문서를 “검색 가능한 문자열”로 만들기 전에 원문에서 무엇이 어디에 있고, 어떤 요소와 연결돼 있는지를 보존하는 방법을 살펴보겠습니다.
왜 PDF 텍스트만 추출하면 의미가 빠질까
일반적인 텍스트 추출은 문서 안의 글자를 읽는 데 유용합니다. 하지만 “A 열의 모델명과 같은 행에 있는 C 열의 한계값”이라는 관계까지 항상 알려주지는 않습니다. 두 단으로 편집된 페이지에서는 왼쪽과 오른쪽 문단이 섞일 수 있고, 표 셀이 줄바꿈으로 분리되면 숫자와 단위가 멀어집니다. 도면의 치수선은 텍스트 일부로 추출돼도 어느 부품을 가리키는지는 남지 않을 수 있습니다.
예를 들어 표가 모델 A와 모델 B를 열로, 압력과 온도를 행으로 가진다고 가정해 봅시다. 모든 글자를 평문으로 이어 붙이면 ‘모델 A’, ‘모델 B’, ‘압력’, ‘온도’, 값 네 개가 한 문단처럼 보입니다. 검색 모델은 관련 숫자 주변을 찾았더라도 어느 행·열의 교차점인지 잘못 연결할 수 있습니다. 여기서 모델과 값은 설명을 위한 가상 사례이며, 특정 제품 사양을 뜻하지 않습니다.
Microsoft Document Intelligence의 레이아웃 문서는 표의 셀, 그림, 섹션 계층과 페이지 안의 위치 정보를 별도 구조로 다룹니다. Google Document AI의 레이아웃 파서 문서도 제목, 표, 그림, 문단 사이 관계를 보존한 구조화 결과를 설명합니다. 이들은 단순 OCR만으로 충분하지 않은 이유를 보여주는 공식 사례입니다.
첫 단계는 문서를 ‘요소’로 분해하는 것이다
설비 문서에서 필요한 단위는 무조건 500자짜리 텍스트 덩어리가 아닙니다. 제목과 문단, 표와 셀, 그림과 캡션, 각주, 페이지 번호처럼 역할이 다른 요소를 먼저 구분해야 합니다. 그리고 요소마다 문서 ID, 버전, 페이지, 페이지 안의 영역, 추출 방식, 원문 파일 위치를 남깁니다. 영역은 서비스에 따라 다각형이나 경계 상자 등으로 표현될 수 있습니다.
이 정보가 있어야 검색 결과를 클릭했을 때 원문 PDF의 정확한 영역을 강조해 보여줄 수 있습니다. “12쪽”만 표시하는 것보다 “12쪽 표 3의 모델 B 열과 허용 압력 행”을 보여주는 편이 훨씬 검증하기 쉽습니다. 본문 문장과 도면 캡션이 서로 연결돼 있다면 함께 검색할 수 있도록 관계도 기록합니다.
실제 도구를 고를 때는 “표와 그림을 추출한다”는 기능 목록보다 출력이 원문과 어떻게 연결되는지를 확인해야 합니다. 페이지 번호와 좌표, 표 셀의 행·열 인덱스, 캡션 연결, 다중 페이지 표 처리 방식이 중요한 이유입니다.
표는 숫자보다 머리글과 단위가 더 중요할 때가 있다
표 안의 값 하나를 별도 청크로 저장하면 검색은 잘될 수 있습니다. 하지만 그 숫자의 의미는 행 제목, 열 제목, 단위, 조건, 각주가 함께 정합니다. “18”이라는 값만 찾는 것과 “모델 B·정상 운전·압력·bar·18”을 찾는 것은 다릅니다. 그렇다고 문서 전체 표를 한 청크에 넣으면 길어져 특정 행이 검색 결과에서 묻힐 수 있습니다.
실무에서는 표 구조를 원본 그대로 보관하고, 검색용 표현을 별도로 만듭니다. 검색용 행 표현에는 문서 제목, 섹션 제목, 표 제목, 열 머리글, 행 머리글, 값과 단위, 각주를 함께 넣습니다. 사용자가 질문하면 검색용 표현으로 후보를 찾되, 최종 답변 전에는 구조화된 원본 셀에서 해당 값과 관계를 다시 확인합니다. 추출된 표와 OCR 텍스트가 서로 다르면 검토 대상으로 표시합니다.
Amazon Textract의 표 처리 문서는 셀, 병합 셀, 열 머리글, 제목, 푸터 같은 요소를 구분합니다. Microsoft의 Markdown 표현 문서도 복잡한 표를 HTML 구조로 표현해 병합 셀과 캡션을 보존한다고 설명합니다. 특정 제품을 쓰지 않더라도 관계를 보존해야 한다는 원칙은 같습니다.
페이지를 넘기는 표는 별도 시험 대상입니다. Google의 레이아웃 파서 문서에도 PDF에서 여러 페이지에 걸친 표가 둘로 나뉠 수 있다고 명시돼 있습니다. 그러므로 후처리에서 제목·머리글 반복 여부와 페이지 연속성을 점검하고, 합칠 수 없는 표는 한 표인 것처럼 답하지 않는 편이 안전합니다.
도면은 설명문 한 줄로 끝나지 않는다
도면과 차트는 이미지 설명 모델이 “모터와 밸브가 보인다”고 요약할 수 있습니다. 이 설명은 검색에는 도움이 되지만 실제 치수나 연결 관계를 보증하지는 않습니다. 정비 담당자가 원하는 것은 “어느 밸브를 잠가야 하는가”처럼 특정 부품의 위치와 절차일 수 있습니다. 이때 필요한 것은 도면 설명문뿐 아니라 원문 그림의 영역, 확대 가능한 크롭, 캡션, 관련 본문을 함께 보여주는 것입니다.
도면 안에서 읽은 숫자는 특히 보수적으로 다뤄야 합니다. 작은 글씨, 회전된 표시, 화살표와 치수선, 비슷한 부품 번호 때문에 인식 오류가 생깁니다. 그림에서 추출한 수치가 중요한 의사결정에 쓰인다면 원문 영역을 사람이 확인하거나, 별도의 구조화된 사양 표와 교차 검증하도록 설계합니다. 모델이 그림을 “이해했다”는 말만으로 수치를 확정하지 않습니다.
검색 결과에는 원문으로 돌아가는 좌표가 있어야 한다
검색 시스템의 청크는 답변을 만들기 위한 재료입니다. 각 청크에는 사람이 확인할 수 있는 출처 정보를 함께 넣어야 합니다. 최소한 문서 ID와 버전, 페이지, 요소 종류, 원문 영역, 부모 제목, 표 또는 그림의 식별자를 권합니다. 개인정보나 접근 권한이 섞인 문서라면 기존의 권한 규칙도 청크와 원문 모두에 일관되게 적용합니다.
질문에 적합한 후보를 찾았을 때 모델에 텍스트만 넘기지 않고 표 구조나 그림 크롭을 함께 넘길 수 있습니다. 결과 화면에서는 답변 아래에 출처 문서와 해당 영역을 연결합니다. 사용자가 “모델 B의 허용 압력이 얼마인가”라고 묻는다면, 특정 표 셀의 행·열·단위를 강조해 보여주는 것이 목표입니다. 출처 영역을 열었을 때 실제로 답의 근거가 보이지 않으면 인용에 실패한 것입니다.
기존에 발행한 기업 RAG의 권한·버전·시간 설계는 어떤 문서에 접근할 수 있는지를 다뤘습니다. 이 글의 초점은 허용된 문서 안에서도 표와 그림의 어느 부분을 근거로 읽었는지 확인하는 데 있습니다.
답변 직전에 숫자와 단위를 한 번 더 검사한다
검색에서 올바른 페이지를 찾았더라도 생성 모델이 숫자를 옮겨 쓰는 과정에서 잘못 말할 수 있습니다. 따라서 중요한 수치 질문에는 답변 직전 검증 단계를 둡니다. 질문이 요구하는 대상 모델·항목·조건을 구조화하고, 후보 표의 행·열 머리글과 일치하는지 확인합니다. 값과 단위가 원문 셀에 실제로 존재하는지 비교하고, 서로 다른 버전의 문서가 충돌하면 최신 문서라는 이유만으로 자동 선택하지 않습니다.
표 추출 결과의 신뢰도가 낮거나 도면의 숫자가 흐릿하다면 “근거가 부족하다”고 답하거나 담당자 검토로 보내는 것이 낫습니다. Amazon Textract의 모범 사례도 사용 사례의 민감도에 따라 신뢰도 점수를 고려하고 낮은 결과는 사람 검토 대상으로 삼도록 권합니다. 다만 OCR 신뢰도가 높다는 사실이 행·열 관계나 답변 전체의 정확성을 보증하지는 않습니다.
평가는 정답 문장보다 ‘근거가 맞는지’로 한다
문서 AI의 시험 문제를 만들 때 “질문과 정답”만 모으면 부족합니다. 어떤 문서 버전의 몇 페이지, 어느 표 셀이나 그림 영역을 봐야 하는지도 함께 표시해야 합니다. 그래야 오류를 검색 실패, 레이아웃 추출 실패, 표 관계 오류, 답변 생성 오류로 나눌 수 있습니다. 잘못된 단계가 다르면 개선 방법도 다릅니다.
평가 세트에는 쉬운 문장형 질문뿐 아니라 실무에서 헷갈리는 사례를 넣습니다. 같은 이름의 장비가 두 모델에 있는 문서, 바뀐 개정판, 병합 셀, 페이지를 넘기는 표, 각주가 조건을 바꾸는 표, 치수선이 복잡한 도면, 읽을 수 없는 스캔본, 정답이 문서에 없는 질문이 필요합니다. 평가에서는 정답 일치율과 함께 올바른 출처 영역을 짚었는지, 숫자와 단위를 그대로 옮겼는지, 답할 근거가 없을 때 멈췄는지를 기록합니다.
운영 중 사용자가 틀린 답을 신고하면 답변만 고치는 데서 끝내지 않습니다. 원문 PDF, 추출된 레이아웃, 검색 청크, 선택된 근거 영역, 최종 답변을 함께 보고 어느 단계에서 관계가 끊겼는지 찾습니다. 고친 사례는 평가 세트에 추가해 같은 유형의 오류가 다시 생기는지 확인합니다.
작게 시작하는 설비 문서 AI 구축 순서
처음에는 문서가 많은 것보다 검증 가능한 문서가 중요합니다. 설비 한 종류의 매뉴얼과 점검 기록을 골라 다음 순서로 시험해 볼 수 있습니다.
- 문서 목록을 정리합니다. 원본 파일, 개정판, 언어, 스캔 품질, 접근 권한을 확인합니다.
- 레이아웃을 추출합니다. 제목·본문·표·그림·각주를 구분하고 페이지 위치를 보존합니다.
- 표와 도면을 따로 검수합니다. 머리글·단위·병합 셀·캡션이 맞는지 대표 페이지를 눈으로 확인합니다.
- 검색용 청크를 만듭니다. 표 행은 머리글과 단위를 함께 넣고, 모든 청크에 원문 영역 참조를 붙입니다.
- 답변 검증을 추가합니다. 수치·단위·문서 버전이 근거와 일치하지 않으면 답을 보류합니다.
- 평가 세트를 만듭니다. 문장, 표, 도면, 답 없음 사례를 고르게 넣고 오류 원인을 단계별로 기록합니다.
첫 목표는 모든 PDF를 완벽히 읽는 시스템이 아닙니다. 현장 직원이 자주 찾는 질문 몇 가지에 대해 빠르고 검증 가능한 답을 제공하는 것입니다. 숫자가 중요한 질문에서는 “빨리 답함”보다 “원문을 바로 확인할 수 있음”이 채택을 좌우합니다.
문서 AI의 품질은 원문까지 이어지는 길에서 결정된다
PDF를 AI에 넣는 일은 파일 업로드로 시작하지만, 신뢰할 수 있는 답변은 레이아웃 분석, 관계 보존, 원문 위치 연결, 수치 검증에서 만들어집니다. 표의 숫자를 잘 읽는 것과 그 숫자가 어떤 모델·조건·단위에 속하는지 아는 것은 다른 문제입니다. 도면을 설명하는 것과 정확한 부품 위치를 확인하는 것도 다릅니다.
좋은 멀티모달 RAG는 답변을 그럴듯하게 만드는 시스템이 아니라, 사용자가 답의 출처를 원문에서 직접 확인할 수 있게 만드는 시스템입니다. 설비 매뉴얼처럼 실수가 현장 작업에 영향을 주는 문서라면 이 기준부터 설계하는 편이 좋습니다.
참고 자료
- Microsoft, Document Intelligence 레이아웃 분석
- Google Cloud, Document AI 레이아웃 파서
- AWS, Textract 표 구조 문서
- AWS, Textract 모범 사례
#멀티모달RAG #문서AI #PDF분석 #표인식 #도면AI #OCR #레이아웃분석 #근거검증 #RAG #제조AI #설비매뉴얼 #지식검색
