RAG 시스템이 엉뚱한 답을 하면 보통 임베딩 모델, 벡터 데이터베이스, 프롬프트부터 의심합니다.
하지만 PDF에서 원문 자체를 잘못 읽었다면 그 뒤의 검색과 생성이 아무리 좋아도 정답을 만들기 어렵습니다.
2026년 Mistral이 공개한 OCR 4/4.1 계열은 문서를 단순 텍스트로만 읽는 것이 아니라 제목, 목록, 표, 이미지, 수식, 코드 같은 구조를 block 단위로 다룰 수 있고 confidence 정보도 제공합니다.
이 모델을 계기로 RAG의 앞단을 다시 보겠습니다.
검색 품질은 chunking보다 먼저 ‘문서를 제대로 읽었는가?’에서 시작합니다.
PDF는 텍스트 파일이 아닙니다
사람에게는 한 페이지로 보이지만 PDF 내부에는 이런 요소가 섞여 있습니다.
- 본문
- 두 단 레이아웃
- 머리말과 꼬리말
- 표
- 캡션
- 수식
- 코드 블록
- 스캔 이미지
파서가 읽는 순서를 잘못 잡으면 문장이 뒤섞일 수 있습니다.
예를 들어 화면에는 이렇게 보일 수 있습니다.
왼쪽 열: 실험 조건
오른쪽 열: 결과
그런데 추출 텍스트가 줄 단위로 교차되면:
실험 조건 결과 첫 번째 조건 정확도 92% 두 번째 조건 ...
처럼 의미가 망가집니다.
CodeBridge 미니 실험: 같은 PDF를 ‘검색 전’에 검사하기
RAG에 넣을 PDF 하나를 골라 검색부터 하지 말고 먼저 다섯 부분만 눈으로 비교해보세요.
- 제목과 섹션 순서
- 표 하나
- 숫자가 많은 문단
- 각주 또는 머리말
- 그림 캡션
그리고 추출 결과에 아래 체크를 붙입니다.
[ ] 읽는 순서가 맞다
[ ] 표의 행/열 관계가 보존됐다
[ ] 머리말·페이지 번호가 본문에 섞이지 않았다
[ ] 숫자와 단위가 사라지지 않았다
[ ] 이미지 캡션이 엉뚱한 문단에 붙지 않았다
이 단계에서 이미 문제가 보인다면 임베딩 파라미터를 바꾸기 전에 파싱을 고쳐야 합니다.
구조 정보가 중요한 이유
RAG에서 모든 텍스트를 일정 글자 수로 자르는 방식은 구현이 쉽습니다. 하지만 문서의 논리 구조와 어긋날 수 있습니다.
예를 들어:
## 환불 정책
### 30일 이내
...
### 디지털 상품 예외
...
라는 문서를 단순 길이 기준으로 자르다가 디지털 상품 예외 제목과 설명이 떨어지면 검색 결과의 의미가 약해집니다.
OCR 단계에서 heading, list, table 같은 구조를 얻을 수 있다면 이후 chunking에서도 그 정보를 활용할 수 있습니다.
Confidence score는 ‘자동 거절’보다 ‘재확인 지점’으로 보세요
OCR 4.1은 page, block, word 수준의 confidence granularity를 지원합니다. confidence가 낮다는 이유로 내용을 바로 삭제하기보다 다음처럼 활용할 수 있습니다.
- 낮은 confidence 페이지는 이미지 기반 재처리
- 중요한 숫자가 낮은 confidence면 사람 검수
- 표 영역만 다른 파서와 교차 확인
- 검색 결과에 낮은 confidence 원문이 포함되면 답변에 주의 표시
즉 confidence는 정답 여부 자체가 아니라 어디를 다시 봐야 하는지 알려주는 신호입니다.
RAG 문제를 찾을 때 순서를 바꿔보세요
질문에 답을 못했을 때 다음 순서로 추적하면 원인 파악이 쉬워집니다.
1. 원본 문서에 답이 실제로 있는가?
2. OCR/파서가 그 부분을 제대로 추출했는가?
3. chunk에 필요한 문맥이 남아 있는가?
4. 검색기가 그 chunk를 가져왔는가?
5. LLM이 검색 결과를 올바르게 사용했는가?
많은 팀이 4~5번부터 시작하지만, 실제 문제는 2번일 수도 있습니다.
이 흐름은 RAG 기본 개념과 사내 문서 AI 챗봇을 볼 때도 유용합니다.
실전에서 자주 생기는 시행착오
모든 PDF를 같은 파서로 처리한다
텍스트 PDF, 스캔 PDF, 슬라이드형 PDF, 표가 많은 보고서는 성격이 다릅니다. 문서 유형별 샘플을 따로 평가하는 편이 좋습니다.
OCR 결과를 눈으로 한 번도 보지 않는다
벡터 DB에 바로 넣으면 파싱 오류가 숨겨집니다. 최소한 몇 페이지는 원본과 추출 결과를 나란히 보세요.
답변 품질만 평가한다
최종 답변이 틀렸을 때 어느 단계가 원인인지 알 수 없습니다. 파싱, 검색, 생성 단계를 분리해서 확인해야 합니다.
결론: 좋은 RAG는 ‘좋은 검색’보다 한 단계 앞에서 시작합니다
Mistral OCR 4.1 같은 문서 모델이 보여주는 중요한 방향은 OCR 정확도 몇 퍼센트의 문제가 아닙니다.
문서를 단순 문자열이 아니라 구조를 가진 데이터로 다루기 시작했다는 점입니다.
RAG가 이상하게 동작할 때 바로 모델을 바꾸지 말고 먼저 원본과 파싱 결과를 나란히 놓아보세요.
검색할 수 없는 형태로 깨진 정보는 어떤 LLM도 되살리기 어렵습니다.