소위 “긴 문맥 AI”의 문제점은 모두가 자기가 가지고 있다고 장담하지만, 47페이지에 대한 자세한 질문을 하면 갑자기 머리를 다친 금붕어만큼 기억력이 나빠진다는 것입니다. DeepSeek-OCR은 단순하지만 진실된 주장을 내세워 이 혼란스러운 상황에 뛰어듭니다. 중요한 것을 압축하고, 구조를 유지하며, 2023년처럼 토큰을 낭비하는 것을 멈추라는 것입니다. 약속은 “더 나은 OCR”이 아니라 레이아웃을 존중하고 맥락 창을 소음으로 부풀리지 않는 OCR입니다.
그리고 이것은 대부분의 소위 긴 문맥 파이프라인이 잘못하는 바로 그 부분입니다. 그들은 원시 텍스트를 모델에 쑤셔 넣고 끝이라고 생각합니다. 그러면 곧바로 환각으로 끝납니다.
DeepSeek-OCR을 실제 긴 문맥 파이프라인에 통합하는 방법을 자세히 살펴보겠습니다. 실제로 확장 가능하고, 눈물 없이 컴퓨팅 비용을 지불하며, PDF에 테이블, 각주 또는 법률 증거 자료가 있을 때도 무너지지 않는 파이프라인입니다.
DeepSeek-OCR이 다른 이유 (및 유용한 이유)
- 레이아웃은 데이터입니다. 긴 문서는 단순한 텍스트가 아니라 공간적 주장입니다. 제목, 열, 테이블, 그림 설명 등 모든 것이 의미를 담고 있습니다. DeepSeek-OCR은 이러한 구조를 최우선으로 보존하는 것을 목표로 하며, 이는 긴 문맥 모델이 줄거리를 잃지 않고 수백 페이지에 걸쳐 추론하는 데 필요한 바로 그 것입니다.
- 뇌엽 절제술 없는 압축: 모든 것을 8K 창에 쑤셔 넣는 것이 아닙니다. 핵심은 신호(밀도 높고, 구조화되고, 탐색 가능함)를 유지하고 나머지는 저렴하게 만드는 것입니다.
- 다운스트림 단계와 잘 작동합니다. RAG, 요약, 긴 문맥 트랜스포머, 심지어 에이전트까지. OCR 레이어가 좋을수록 검색 및 추론 레이어가 OCR에 대해 사과할 필요가 줄어듭니다.
구축할 내용: 척추가 있는 긴 문맥 파이프라인
파이프라인을 각각 하나의 작업을 잘 수행하는 5개의 부분으로 생각하십시오.
- 입력 유형: PDF (디지털 및 스캔), 이미지, 스캐너의 TIFF, 지저분한 사무실 내보내기.
- 전처리: 필요에 따라 기울기 보정, 노이즈 제거, 이진화하고 페이지를 일관되게 분할합니다. 페이지 번호, 소스 파일, 섹션 앵커와 같은 페이지별 메타데이터를 유지합니다.
- 출력 대상: 안정적인 DPI로 예측 가능한 형식 (PNG 또는 JPEG)의 이미지 또는 페이지 캔버스.
- 각 페이지에서 DeepSeek-OCR을 실행하여 다음을 추출합니다.
- 경계 상자 (x, y, 너비, 높이)가 있는 텍스트 범위
- 블록 유형: 제목, 단락, 목록, 테이블, 그림, 각주
- 원시 텍스트와 레이아웃 기능을 모두 유지합니다. 토큰 수준 맵을 내보낼 수 있다면 유지합니다. 테이블은 구조화되어야 (CSV/HTML)하며 좌표에 다시 연결되어야 합니다.
- 비법: 단순한 토큰 잘림이 아닌 블록 중요도를 기준으로 압축합니다.
- 제목 및 섹션 요약: 있는 그대로 유지합니다.
- 단락: 경량 순위 지정기 (BM25/ColBERT 스타일 또는 작은 로컬 인코더)를 사용하여 문장 수준 선택.
- 테이블: 헤더 및 상위 k개의 통계적으로 다양한 행을 보존합니다. 숫자 열은 완전히 그대로 유지합니다. 전체 테이블은 대역 외에 보관합니다.
- 캡션 및 각주: 유지합니다. 토큰은 적고 의미는 높습니다.
- 컴팩트하고 레이아웃을 인식하는 내러티브 컨텍스트: 원래 토큰의 10~20%, 일관성 있고 탐색 가능합니다.
- 사이드카 인덱스: 압축된 범위에서 전체 충실도 블록으로의 포인터.
- 문장/단락에 대한 의미론적 검색을 위한 조밀 벡터.
- 정확한 조회를 위한 희소 (BM25)—코드, 인용, 식별자.
- 테이블 인식 인덱스: 숫자 쿼리를 위한 행별 및 셀별 임베딩.
- 키워드가 많은 질문 → 먼저 희소, 조밀하게 재순위 지정.
- 분석적 또는 “이유” 질문 → 먼저 조밀, 희소 앵커로 재순위 지정.
- 테이블/수학 쿼리 → 행/열 출처와 함께 테이블 인덱스를 직접 사용.
- 전체적인 프롬프트를 위한 긴 문맥 LLM (정책 문서, RFP, 연구 논문).
- 다단계 작업을 위한 단계별 도구 호출 에이전트: 검색 → 분석 → 확인 → 인용.
- 전체 컴팩트 내러티브를 모델에 절대 넣지 마십시오. 적시 컨텍스트를 어셈블합니다. 의도별 상위 섹션, 관련 테이블 및 주변 단락. 빵 부스러기 (섹션 이름, 페이지 참조, 그림 ID)로 스티치합니다.
결과물: 영수증이 있는 답변. 모든 주장은 원래 PDF에서 강조 표시할 수 있는 블록 ID, 페이지 번호 및 좌표 범위로 다시 연결됩니다. 이것이 신뢰를 얻는 방법입니다.
실용적인 청사진: 원시 PDF에서 긴 문맥 답변으로
1단계: 문서 수집
- 파일 유효성 검사: 암호로 보호되거나 손상된 경우 빠르게 실패합니다.
- 고정된 DPI로 페이지 이미지를 렌더링합니다 (300이면 충분하고, 속도를 위해 200).
- OCR을 캐시할 수 있도록 페이지 수준 해시를 유지합니다.
2단계: DeepSeek-OCR 통과
- GPU 처리량을 위해 페이지를 일괄 처리합니다.
- 블록 및 읽기 순서를 추출합니다. 좌표를 일관된 페이지 공간으로 정규화합니다.
- JSON: 유형, 텍스트, bbox, 페이지가 있는 블록 목록.
- 각 셀에 대한 bbox 맵과 함께 CSV/HTML 형식의 테이블.
- 레이아웃 힌트가 있는 선택적 스티치 마크다운 (제목의 경우 ##, 테이블의 경우 :::table 등).
3단계: OCR 후 정리
- 줄 바꿈에서 하이픈으로 연결된 단어를 병합합니다.
- 열 해결: 페이지에 두 개의 열이 있는 경우 읽기 순서가 열을 존중하는지 확인합니다.
- 제공되지 않은 경우 글꼴/크기 휴리스틱을 통해 제목을 감지합니다. TOC 트리를 빌드합니다.
- 반복되는 머리글/바닥글을 제거합니다 (스캔 계약에서 일반적임).
4단계: 구조를 사용한 압축
- 문장을 분할합니다. 도메인에서 훈련된 저렴한 순위 지정기로 문장 점수를 매깁니다.
- 점수가 높은 문장을 유지합니다. 항상 각 제목 아래에서 첫 번째 문장을 유지합니다.
- 테이블의 경우: 헤더 행 + 분산/중요도별 상위 k개 행과 전체 테이블에 대한 참조를 유지합니다.
- 컴팩트 내러티브와 유지된 모든 문장을 원본에 연결하는 인덱스 사이드카를 생성합니다.
5단계: 인덱싱
- 문장에 대한 조밀 임베딩 (필요한 경우 강력한 다국어 모델 사용).
- 전체 코퍼스에 대한 희소 인덱스 (제목, 머리글, 코드, 인용, 식별자, 단위).
- 행 및 셀 수준의 테이블 임베딩. 빠른 필터를 위해 숫자 통계 (최소, 최대, 평균)를 유지합니다.
- 출처 저장: doc_id, 페이지, bbox, block_id.
6단계: 쿼리 라우팅 및 검색
- 쿼리 의도 분류: 조회 vs 분석 vs 테이블 수학 vs 비교.
- 테이블 수학: 테이블 인덱스 + 행 필터. 컨텍스트를 위해 주변 텍스트를 첨부합니다.
- 3~6개의 검색된 구절 (제목 및 페이지 참조 포함)
- 필요한 경우 1~2개의 작은 테이블 또는 계산된 통계
- 모델별 스위트 스폿에서 프롬프트를 유지합니다. 긴 컨텍스트는 무한 컨텍스트가 아닙니다.
7단계: 인용이 포함된 답변 합성
- [Doc §2.3, p. 47, tbl A]와 같은 섹션화된 답변 및 인라인 인용과 같은 구조화된 출력을 요청합니다.
- 까다로운 주장의 경우 확인 단계를 트리거합니다. 정확한 범위를 다시 검색하고, 대상 질문을 다시 묻고, 충돌을 조정합니다.
- 사용자가 클릭할 수 있는 출처 추적과 함께 답변을 반환합니다.
실제 비용을 절약하는 성능 참고 사항
- GPU를 YOLO하지 마십시오. OCR은 이상한 교대로 I/O 바운드 및 GPU 바운드됩니다. 페이지 수로 일괄 처리하고 커널 재사용을 최대화하기 위해 이미지 크기를 정규화합니다.
- 적극적으로 캐시합니다. 소스 문서가 변경되지 않은 경우 OCR을 다시 수행하지 마십시오. 파일이 아닌 페이지 비트맵의 콘텐츠를 해시합니다.
- 테이블은 지뢰입니다. 토큰 수를 늘리고 품질을 떨어뜨립니다. 깔끔하게 추출하고 질문에 필요하지 않은 경우 일반 컨텍스트에서 제외합니다.
- 청킹은 종교가 아닙니다. 토큰 길이가 아닌 레이아웃 (제목, 단락)별로 청크합니다. 토큰 길이 청킹은 논쟁 구조를 잃는 방법입니다.
- 요약하기 전에 확인합니다. 검색이 컨텍스트를 좁힐 때까지 모호한 구절을 요약하지 마십시오. 잘못된 것을 압축하게 됩니다.
오류 처리: 중요한 매력 없는 부분
- 손상된 PDF: 래스터화 폴백을 시도합니다. 여전히 손상된 경우 진단 아티팩트를 반환합니다. 조용한 실패는 답변이 없는 것보다 나쁩니다.
- 쓰레기 스캔 (팩스 등급): 노이즈 제거/대비 범프를 시도합니다. 신뢰도가 임계값 아래로 떨어지면 사람 검토를 위해 플래그를 지정합니다. 모르는 것을 인정하십시오.
- 비 라틴 스크립트: OCR 모델이 스크립트 세트를 지원하는지 확인합니다. 그렇지 않으면 특수 OCR 변형으로 라우팅합니다.
- 예술처럼 보이는 테이블: 테이블 감지가 실패하면 모르는 척하지 마십시오. 캡션이 있는 이미지로 취급하고 “수동 추출 필요” 알림을 반환합니다.
데이터 모델: 영역과 함께 맵을 유지합니다.
- 텍스트 (선택 사항), bbox, 순서, 스타일 힌트
- 행, 열, 셀 텍스트, 셀 bbox, 머리글 플래그
- doc_id, 페이지, block_id, 오프셋, bbox
보안 및 규정 준수
- 정책에서 허용하지 않는 한 민감한 PDF를 타사 API에 업로드하지 마십시오. 필요한 경우 전송 중 및 보관 시 암호화합니다.
- 가능하면 OCR 단계에서 PII를 수정합니다. 경계 상자 수정은 사후 문자열 마스크보다 강력합니다.
- 금지된 곳에서 콘텐츠를 기록하지 않고 검색 및 답변 생성을 기록합니다. 원시 텍스트가 아닌 해시 및 ID를 유지합니다.
과장 없이 긴 문맥 모델 선택
- 질문이 대부분 “X라고 어디에 나와 있습니까”인 경우 순수한 컨텍스트 길이보다 검색 및 인용을 우선시합니다. 짧고 정확한 컨텍스트가 1M 토큰 환각을 이깁니다.
- 문서가 내러티브 (연구, 보고서)인 경우 긴 문맥 모델이 도움이 되지만 섹션 구조로 안내되는 경우에만 도움이 됩니다.
- 테이블이 많은 워크플로는 분할된 두뇌를 원합니다. 산문을 위한 언어 모델, 산술 및 필터링을 위한 경량 프로그램.
버전 관리 및 드리프트
- OCR이 개선되고, 문서가 변경되고, 임베딩이 드리프트됩니다. 모든 것을 버전 관리합니다.
- 버전이 변경되면 점진적으로 다시 인덱싱합니다. 패리티를 증명할 때까지 이전 버전과 새 버전을 모두 유지합니다.
개발자 통합 스케치
- 작업자 1: 수집 → 페이지 렌더링 → 대기열에 추가.
- 작업자 2 (GPU): 페이지당 DeepSeek-OCR → 구조화된 JSON → 테이블.
- 작업자 3: 정리 + 레이아웃 트리 → 압축.
- 작업자 4: 인덱스 빌드 (조밀 + 희소 + 테이블) → 게시.
- 서비스: 쿼리 라우터 → 검색 → 프롬프트 어셈블리 → LLM → 확인 → 응답.
- 스토리지: 페이지 이미지 및 사이드카용 객체 스토어, 블록 및 출처용 DB, 벡터 및 희소 인덱스.
엉망을 만들지 않는 도구에 대한 한마디
가장 화려하지 않은 부분이 종종 파이프라인을 만듭니다. 레이아웃을 존중하는 타이트한 OCR, “모르겠습니다”라고 말할 수 있는 인덱스, 과도하게 채우기를 거부하는 프롬프트 빌더. 그것이 임무입니다. 계약 요약, 300페이지 RFI 검토 또는 SOP 매뉴얼 감사와 같은 실용적인 워크플로에 이를 통합하려면 Sider.AI는 특히 마법사가 아닌 훈련된 감독자처럼 취급할 때 OCR, 검색 및 긴 문맥 프롬프트 간의 접착제 레이어 역할을 합니다. 이를 사용하여 수집 작업, 청킹 정책, 모델 선택 및 “신뢰하기 전에 확인” 루프를 오케스트레이션합니다. 이러한 작업을 팀 전체에서 확장하고 결과를 재현 가능하게 유지해야 할 때 그 가치를 입증합니다. 금요일까지 겪게 될 “함정”
- 과도한 압축: 너무 많이 잘라내고 답변이 뉘앙스를 잃습니다. 답변 길이/범위 메트릭을 감시합니다. 신뢰도가 떨어지면 전체 블록을 가져오는 폴백을 추가합니다.
- 과도한 검색: 60개의 청크를 프롬프트로 끌어와 컨텍스트를 날려 버립니다. 이를 제한하고 인접성에 바이어스를 둡니다 (인접 섹션은 금입니다).
- 테이블 착시: 모델이 숫자를 설득력 있게 인용하지만 잘못된 행에서 인용합니다. 항상 프롬프트에서 행 키와 함께 테이블 스니펫을 페어링합니다.
- 중복 페이지: 스캔 워크플로는 반복하는 것을 좋아합니다. 페이지를 해시합니다. OCR 비용을 지불하기 전에 페이지 수준에서 중복을 제거합니다.
- 상호 참조 및 각주: 법적으로 의미 있는 주의 사항을 전달합니다. 정책/법률 문서에서 각주를 삭제하지 마십시오. 낮은 토큰 레인에 보관합니다.
거짓말하지 않는 품질 메트릭
- 상위 k개 인용 정확도: 인용된 블록이 실제로 주장을 뒷받침합니까?
- 테이블 셀 정밀도: 숫자 답변에서 올바른 셀 참조 비율.
- 압축 충실도: 섹션당 압축된 내러티브와 원본 간의 ROUGE/LFQA 스타일 오버랩.
- 로드 시 쿼리 대기 시간: LLM 시간이 아닌 P95 엔드 투 엔드.
- 인간 신뢰 점수: 사용자가 언뜻보기에 답변을 수락하거나 거부합니까? 이는 채택을 예측하는 유일한 메트릭입니다.
최소 작동 예제 (개념적)
- 입력: 부록과 5개의 까다로운 테이블이 있는 180페이지 조달 사양.
- DeepSeek-OCR을 실행합니다. 상자와 충실한 TOC가 있는 구조화된 블록을 내보냅니다.
- 압축은 모든 제목, 첫 번째 문장 및 테이블의 필수 행을 유지합니다. 사이드카는 모든 것을 다시 가리킵니다.
- 사용자가 질문합니다. “어떤 섹션에서 전기 부품에 대한 보증 기간을 설정합니까?”
- 프롬프트는 인라인 인용과 함께 제목+단락을 제공합니다.
- 모델 답변: “섹션 4.2.1, p. 67: ‘전기 부품은 최소 36개월 보증이 적용됩니다…’” 정확한 범위를 강조 표시하는 링크가 있습니다.
- 사용자가 질문합니다. “랙 전체의 총 전력 예산은 얼마입니까?”
- 라우터는 테이블 인덱스를 선택합니다. 올바른 행을 추출하고 간단한 도구로 두 열을 합산하고 행 키와 함께 테이블 B-3을 인용합니다. 환각된 수학이 없습니다.
다른 사람들이 하지 못할 때 이것이 작동하는 이유
OCR, 검색 및 추론을 계약을 맺은 별도의 작업으로 취급하기 때문입니다. DeepSeek-OCR은 구조를 제공하고, 압축은 의미를 보존하고, 검색은 올바른 증거를 가져오고, 긴 문맥 모델은 채우기에 빠지지 않고 함께 연결합니다. 업계 기본값은 모든 것을 더 큰 창에 넣고 기도하는 것입니다. 기도는 전략이 아닙니다.
구석을 잘라야 한다면 가장 마지막에 자르십시오.
- 테이블 추출: 여기에서 아끼면 모든 다운스트림 단계가 엉망을 상속합니다.
- 출처 배관: 사용자는 느림과 가끔 잘못된 답변조차 용서합니다. 확인할 수 없는 답변은 용서하지 않습니다.
- 캐시 및 해싱: 올바르게 수행하면 클라우드 청구서가 용서할 것입니다.
변증법적 비트: 긴 문맥이 필요합니까?
매운 생각: 때로는 긴 문맥이 잘못된 검색의 디딤돌입니다. 질문이 좁고 정확하면 더 나은 인덱싱과 더 작은 컨텍스트에 투자하십시오. 긴 문맥은 섹션, 정책 예외, 상호 참조 조항, 문헌 검토에서 종합해야 할 때 빛을 발합니다. 그렇지 않으면 필요하지 않은 관심에 대한 비용을 지불하는 것입니다.
정말로 “전체 읽기” 이해가 필요한 경우 모델이 모든 것을 작업 메모리에 유지하도록 강요하지 마십시오. 단계별로 수행합니다. 개요 → 검색 → 정당화. 심지어 인간도 그렇게 합니다.
마무리: 영수증을 가져오거나 신경 쓰지 마십시오.
DeepSeek-OCR을 긴 문맥 파이프라인에 통합하는 것은 더 큰 창의 제단에서 숭배하는 것이 아닙니다. 문서를 공간적 주장으로 존중하고, 맛으로 압축하고, 의도를 가지고 검색하고, 영수증을 가지고 답변하는 것입니다. 그렇게 하면 파이프라인이 47페이지를 기억하는 척하는 것을 멈추고 이를 증명하기 시작합니다.
상식적으로 사용되는 Sider.AI는 이를 실용적으로 만듭니다. 단계를 오케스트레이션하고, 프롬프트를 정직하게 유지하고, 긴 문맥 작업에 실제로 필요한 규율을 시행합니다. 그것이 매력적이지 않게 들리면 좋습니다. 매력적인 부분은 신뢰할 수 있는 답변입니다. FAQ
Q1:DeepSeek-OCR을 긴 문맥 파이프라인에 통합하는 가장 빠른 방법은 무엇입니까?
OCR을 엄격한 캐싱이 있는 GPU 배치 서비스로 취급한 다음 검색하기 전에 레이아웃 (제목, 단락, 테이블)별로 압축합니다. 하이브리드 인덱스 (조밀 + 희소 + 테이블)를 추가하고 전체 문서를 덤프하는 대신 적시에 프롬프트를 어셈블합니다.
Q2:DeepSeek-OCR을 사용하는 경우 긴 문맥 모델이 정말로 필요합니까?
항상 그런 것은 아닙니다. 질문이 정확하면 더 나은 검색과 인용이 무차별 대입 컨텍스트를 이깁니다. 긴 문맥은 67페이지에서 한 조항을 찾을 때가 아니라 섹션 전체에서 종합해야 할 때 효과가 있습니다.
Q3:토큰 수를 폭발시키지 않고 테이블을 처리하는 방법은 무엇입니까?
테이블을 구조적으로 추출하고, 머리글과 몇 개의 높은 신호 행을 유지하고, 전체 테이블을 대역 외에 저장합니다. 테이블 질문을 테이블 인덱스로 라우팅하고 프롬프트에 필요한 셀만 포함합니다.
Q4:파이프라인이 실제로 작동한다는 것을 증명하는 메트릭은 무엇입니까?
인용 정확도, 테이블 셀 정밀도, 섹션당 압축 충실도 및 P95 엔드 투 엔드 대기 시간을 추적합니다. 가장 중요한 것은 인간 신뢰 점수입니다. 사용자가 증거를 찾지 않고 답변을 수락합니까?
Q5:Sider.AI는 이 설정에서 어디에 적합합니까?
오케스트레이션 레이어로서 OCR을 예약하고, 청킹 및 검색 정책을 시행하고, 프롬프트를 규율있게 유지합니다. 마법사가 아닌 감독자로 생각하십시오. 다른 모든 부분이 정시에 영수증과 함께 나타나도록 만드는 것입니다. 
