▲

DeepSeek OCR - 시각적 맥락 압축을 통한 초고효율 OCR 모델

 (github.com/deepseek-ai)
11P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • “텍스트를 이미지로 표현하면 훨씬 적은 토큰으로 동일한 정보를 담을 수 있다” 는 통찰에서 시작
  • 텍스트 정보를 2D 시각 표현으로 압축하는 새로운 접근법을 제안한 모델로, 긴 문맥을 효율적으로 다루기 위한 비전 기반 압축(Optical Compression) 개념을 실험적으로 검증함
  • 모델은 DeepEncoder(인코더) 와 DeepSeek3B-MoE-A570M(디코더) 로 구성되며, 고해상도 입력에서도 낮은 활성 메모리와 10~20배 수준의 토큰 압축 비율을 달성함
  • 10배 압축에서도 97% OCR 정밀도, 20배 압축에서도 60% 이상 정확도를 유지하며, 이는 장문 문맥 압축·기억 망각 메커니즘 연구에 실질적 가능성을 제시함
  • OmniDocBench에서 GOT-OCR2.0(256 토큰/페이지) 대비 100개 비전 토큰만으로 상회 성능, MinerU2.0(평균 6000+ 토큰/페이지) 대비 800 토큰 이하로 우수 성능을 기록함
  • 단일 A100-40G GPU로 하루 20만 페이지 이상 데이터 생성이 가능하며, LLM/VLM 대규모 학습용 데이터 엔진으로 실용 가치가 높음

1. 연구 배경

  • 기존 LLM은 시퀀스 길이에 따라 계산량이 제곱으로 증가하는 구조적 한계를 지님
  • 논문은 “텍스트를 이미지로 표현하면 훨씬 적은 토큰으로 동일한 정보를 담을 수 있다” 는 통찰에서 출발
  • 이를 시각 토큰 기반 장문 맥락 압축(Context Optical Compression) 으로 정의하고, OCR을 그 실험적 무대로 설정함
  • 결과적으로 시각 표현이 LLM의 문맥 처리 효율을 개선할 수 있는 새로운 경로를 보여줌

2. 모델 구조

  • DeepSeek-OCR = DeepEncoder + DeepSeek3B-MoE 디코더
    • DeepEncoder: SAM(Window Attention) + CLIP(Global Attention) + 16배 토큰 압축기
    • DeepSeek3B-MoE: 64개의 전문가 중 6개 활성화, 총 570M 활성 파라미터
  • 다중 해상도 모드 지원 (Tiny~Gundam)
    • 512~1280 해상도 입력을 지원하며, 최대 9개 타일을 합성 처리
    • Gundam 모드는 초고해상도 문서(신문 등)에 대응, 최대 800 비전 토큰 사용

3. 데이터 엔진

  • 총 3종류의 데이터 조합:
    • OCR 1.0 데이터: 30M 페이지(100개 언어) 문서 기반, 세밀한 레이아웃·텍스트 주석 포함
    • OCR 2.0 데이터: 차트·화학식(SMILES)·기하 도형 등 복합 인식용 16M 데이터
    • 일반 비전 데이터: CLIP 기반 시각 이해 유지용, 전체의 20%
    • 텍스트 전용 데이터: 10% 비중으로 언어 능력 보완
  • 전체 훈련 데이터 구성 비율
    • OCR 70% / 비전 20% / 텍스트 10%

4. 훈련 파이프라인

  • DeepEncoder → DeepSeek-OCR 두 단계로 학습
  • 총 20개 노드(8×A100 GPU)에서 데이터 병렬도 DP=40, 글로벌 배치 640
  • 학습 속도: 텍스트 데이터 90B 토큰/일, 멀티모달 데이터 70B 토큰/일

5. 평가 결과

(1) 압축 실험 (Fox 벤치마크)

  • 10배 압축에서 97% 정확도, 20배 압축에서도 60% 이상 유지
  • 문서가 길거나 복잡할수록 성능 저하 발생하지만, 이는 “망각 메커니즘” 시뮬레이션 가능성으로 해석
  • 압축률 10× 이하에서는 거의 손실 없는 문맥 복원 가능

(2) 실제 문서 인식 (OmniDocBench)

  • Tiny(64 토큰)~Gundam(800 토큰) 모드 비교
    • GOT-OCR2.0(256 토큰) 대비 Small(100 토큰) 모드에서 우수
    • MinerU2.0(7,000 토큰) 대비 Gundam(800 토큰)으로 상회 성능
  • 특정 문서 유형별로 요구 토큰 수가 다름
    • 슬라이드, 리포트: 64~100 토큰으로 충분
    • 신문, 논문: 400~800 토큰 필요

6. 질적 분석 (Qualitative Study)

  • Deep Parsing 모드
    • 차트, 도형, 화학식, 자연 이미지까지 단일 프롬프트로 구조적 추출 가능
  • 다국어 인식
    • 약 100개 언어의 PDF 지원, 아랍어·싱할라어 등 소수 언어 포함
  • 일반 시각 이해
    • 이미지 설명, 객체 탐지, 그라운딩까지 수행
    • LLM 연계 시 비전-언어 복합 추론의 기반 모델로 활용 가능

7. 논의 및 시사점

  • DeepSeek-OCR은 비전 토큰 기반 장문 압축의 경계를 탐색한 첫 실험으로,
    “한 이미지가 천 단어를 담는다”는 개념을 수량화함
  • 압축률 10×에서도 거의 손실 없는 복원 가능 → 대화 히스토리 압축, 장기 기억 최적화 등으로 확장 가능
  • “시간이 지나며 이미지 해상도를 줄이는 방식”을 통해 생물학적 망각 곡선과 유사한 토큰 감쇠 시뮬레이션 제안

8. 결론

  • DeepSeek-OCR은 텍스트-시각 간 10~20배 압축 매핑의 실증 모델로,
    LLM의 장문 문맥 처리 한계 극복을 위한 새로운 패러다임을 제시함
  • OCR을 넘어서, 향후에는 디지털-광학 혼합 프리트레이닝 및
    ‘Optical Context Memory’ 기반 초장기 맥락 모델로 확장될 전망
  • 코드는 공개되어 있으며, 연구 및 상용 데이터 엔진으로 활용 가능

Repo 내용 정리 : https://github.com/deepseek-ai/DeepSeek-OCR

  • DeepSeek-OCR는 기존 OCR 오픈소스 대비, 시각 정보를 효과적으로 인코딩하는 대형 언어 모델(LLM) 기반 구조로 주목받음
  • 다양한 해상도 지원(512×512~1280×1280) 과, 동적 해상도를 위한 Gundam 모드가 포함되어 다양한 환경 대응이 뛰어남
  • 명확한 프롬프트 설계로 일반 이미지 설명, 마크다운 변환, 레이아웃 무시 OCR, 도표 파싱 등 다양한 작업 모드 지원함
  • Fox, OminiDocBench와 같은 업계 벤치마크와의 연동 성능 확인, 실제 문서 처리 실험 기반 검증 진행함
  • GOT-OCR2.0, PaddleOCR 등 다른 인기 프로젝트들의 장점과 아이디어를 수용해 구현되었음
  • 지원 해상도
    • Tiny: 512×512 (64 vision tokens)
    • Small: 640×640 (100 vision tokens)
    • Base: 1024×1024 (256 vision tokens)
    • Large: 1280×1280 (400 vision tokens)
    • Dynamic mode(=Gundam): 자유 해상도(n×640×640 + 1×1024×1024)
  • PDF, 이미지에 대한 병렬 추론 및 빠른 처리 속도
    • A100 GPU 기준 PDF 처리~2,500 토큰/초 가능
  • 기술적 배경 및 생태계 연계
    • Python 100%로 구현되어 있음
    • vLLM·Transformers 두 가지 주요 인퍼런스 환경 모두 지원
    • OpenChart, Fox, OminiDocBench와 같은 주요 벤치마크 및 평가 프레임워크 활용
    • GOT-OCR2.0, PaddleOCR, Vary 등의 선행 모델과 연동, 아이디어 차용, 성능 보강
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 이 논문은 단순히 OCR을 위한 또 다른 VLM에 그치지 않고 압축 등 더 흥미로운 주제로 넘어감
    예를 들어, "우리는 비전-텍스트 압축의 경계를 탐구하는 초기 연구를 진행하여, 텍스트 토큰을 해독하기 위해 몇 개의 비전 토큰이 필요한지 살펴봄. 예비 결과로 DeepSeek-OCR은 거의 무손실 OCR 압축을 약 10배 비율로 달성했고, 20배로 압축해도 60%의 정확도를 유지함"이라는 인용문이 있음
    직관적으로 비전 토큰 하나가 텍스트 토큰 10개만큼의 정보를 담는 셈임
    정보 이론적으로 왜 이런 결과가 나오는지 초보자가 이해할 수 있게 설명 부탁함
    텍스트 토큰이 아직 너무 세분화되어 있거나(중복적이거나) 엔트로피 코딩에 미치지 못하기 때문인지, 아니면 비전 토큰 방식으로 넘어가면서 '단어 단위'의 한계를 벗어나서 엔트로피에 근접할 수 있는 것인지 궁금함(아리스메틱 인코딩과 허프만 코드의 차이처럼)
    그리고 논문에서는 대용량 컨텍스트를 다룰 때 이미지를 실제로 다운스케일해서, 텍스트 도메인과 이미지 도메인에서의 정보 손실의 대응 관계도 논의함

    • 텍스트 토큰은 양자화된 하위 단위(서브워드)이고, 비전 토큰은 임베딩 공간에만 존재함
      LLM에서 텍스트 토크나이즈 방식은 (작은) 토큰 ID와 (큰) 벡터 임베딩의 룩업 테이블 구조임
      텍스트를 LLM에 넘길 때는 문자열을 토큰 경계로 자르고, 토큰 ID로 변환한 뒤, 룩업 테이블에서 벡터들을 불러와 행렬(context matrix)을 만듦
      실제 텍스트 토큰 시퀀스 전송은 효율적임. 왜냐하면 그저 숫자 배열(ID)만 넘기면 됨(보통 ~10만 개의 고유 토큰 ID 정도)
      반대로 임베딩 행렬 자체를 전송하려면 비효율적인데, 임베딩은 수천 개의 플로트 숫자로 구성됨
      이미지는 다르게 인코딩됨. 이미지 데이터를 전처리하고, 바로 뉴럴 네트워크 기반 이미지 인코더에 넣어서 벡터로 변환하고 이 벡터들을 컨텍스트에 합침
      즉, 이미지 토큰은 토큰 ID도 없고, 룩업 테이블도 없고, 데이터에서 바로 임베딩으로 넘어감
      결과적으로 이미지 토큰을 전송하려면 임베딩 자체를 보내야 해서 비효율적임
      이미지가 더 적은 토큰으로 인코딩되어도 각 토큰의 용량이 훨씬 큼
      요약하면, 텍스트 토큰은 정수(0~n)로 벡터 매핑이 확실히 되어 있고, 그래서 ‘n’가지 선택지가 있음
      반면, 이미지 토큰은 m차원 플로트 배열(벡터)이므로 훨씬 더 큰 토큰 공간을 가짐
      패턴 면에서도 텍스트 토큰은 연속된 UTF-8 바이트에 직접 대응하며, 대부분 단어 경계까지 벗어나지 않기 때문에 글로벌 패턴(예: “이 대사는 햄릿의 것”, “이 부분은 스페인어임”)은 토큰 하나로 표현 불가임

    • 멀티모달 LLM에서 이미지 입력을 어떻게 임베딩하는지는 확실히 알지 못하지만, 기본적으로 이미지를 그리드로 잘라서 각 영역을 인코딩한다고 이해함
      DeepSeek의 실험에서 정보 이론적 특성이 나오기보다는, 얼마나 해상도를 낮추거나 그리드(패치) 크기를 줄여도 여전히 충분한 디테일을 담아서 정확하게 OCR을 할 수 있는지가 핵심 같음
      Karpathy가 NanoChat을 멀티모달로 확장해서 이런 인코딩 프로세스 노하우를 공유해줬으면 좋겠음

    • 적정 압축 비율은 결국 한 글자의 해상도와 각 비전 토큰 패치 크기의 상대적 크기에 따라 달라질 수밖에 없음
      이래야만 결과적으로 OCR로 추출된 텍스트 토큰 수도 이미지 해상도와 독립적으로 유지될 수 있음

    • 각 텍스트 토큰은 대부분 subword 단위지만, VLM의 비전 토큰은 의미 공간(semantic space)에 놓임
      의미 공간은 subword 쪼개기보다 훨씬 더 강력하게 정보를 압축할 수 있음
      참고: 전문가 아님, 즉석에서 생각한 내용임

    • LLM은 토큰 개수에 따라 연산량이 제곱으로 늘어나는 구조임
      그래서 VLM에서는 텍스트 토큰을 비전 토큰으로 압축하려고 함
      아마 텍스트를 먼저 이미지로 렌더링한 후 토크나이즈해서 연산 비용을 줄이는 시도를 하는 것 같음

  • NVIDIA Spark(ARM64)에서 PyTorch가 다소 까다로운데, Claude Code를 루트 권한으로 새 Docker 컨테이너에서 실행시켰더니 동작시킬 수 있었음
    자세한 노트는 여기에서 볼 수 있음
    실제 결과물은 이 링크에서 확인 가능하고, OCR 이미지 원본(여기)를 대상으로 테스트함

    • OCR 결과가 전반적으로 매우 탄탄함
      다만 인용문 바로 아래 단락에서 불필요한 내용을 덧붙여 할루시네이션을 보였고, 그 다음 컬럼과 연결시켜버림
      빠른 테스트 추진에 감사함

    • 텍스트 시작 부분의 "A"를 놓친 것도 이해는 됨 (아마 데이터셋에 뉴스 기사 비중이 낮았을 것 같음)
      하지만 "Hallucination is a risk and..." 전체와 저자 옆 주제("theme") 및 마지막 이메일 부분도 완전히 빠진 점이 더 흥미롭다고 느낌

    • 이 실험 자체만으로도 별도의 게시글로 올릴 가치가 있다고 생각함

    • "Claude Code를 새 Docker 컨테이너에서 루트로 실행"
      루트 권한으로 실행하게 하는 설정 방법 구체적으로 궁금함
      (혹시 설명되어 있다면 본문에서 확인하겠음)

  • 논문에서 Anna’s Archive에 관한 언급이 없음
    DeepSeek가 OCR 연구자에게 750만 권(350TB) 중국 논픽션 컬렉션 액세스를 허용한다는 Anna 측 제안을 실제로 활용했을 수도 있다고 생각함
    이 양은 Library Genesis보다도 큰 규모임
    참고 블로그

    • DeepSeek의 지난 논문에서는 Anna’s Archive를 직접 언급함
      "Anna’s Archive에서 860K권의 영어, 180K권의 중국어 전자책 및 K-12 교육용 시험문제 수백만 개를 정제함"
      DeepSeek-VL 논문 참고

    • 남의 책을 보관하고 있다는 이유로 액세스 권한을 굳이 받아야 하는지 의문임

    • 나 역시 바로 Anna’s Archive가 떠올랐고, 언제쯤 OCR로 처리된 데이터셋이 공개될지 궁금함

    • 데이터셋을 영원히 공개하지 않게 되는 의미이기도 함

    • 이런 상황이면 Anna’s Archive도 결국 LLM 회사들에게 남용되어 사라질까 걱정임
      META가 library genesis에서 70TB를 토렌트로 긁어간 것도 모자란 상황임

  • 현재와 다른 벤치마크의 실제 수준에 대한 경험 공유임

    • OmniAI 벤치마크는 별로임

    • 대신 OmniDocBench 추천함

    • Mistral OCR은 오픈소스 OCR 모델들, 그리고 Gemini에 비해 현저히 떨어짐

    • E2E OCR은 여전히 매우 어려움

    • 파이프라인 방식(레이아웃 감지 → 읽기 순서 결정 → 각 요소 OCR)이 더 잘 동작함

    • 복잡한 테이블 파싱은 여전히 큰 난제임

    • Apple Vision Framework도 이런 모델들과 벤치마킹 비교한 사례가 궁금함
      거의 모든 애플 기기에 내장돼 있고, 실제로 고품질·빠른 OCR을 뽑아내는데(특히 PDF 변환 용도), 사람들이 잘 모르는 듯함
      벤치마크에서 어디쯤 위치하는지 무척 궁금함

    • OmniAI 벤치마크에 따르면 Omni OCR이 최고 성능을 보임
      다들 이런 결과에 아무 의문도 못 품을 것 같음

  • LLM 기반 OCR이 Azure AI Document Intelligence(링크), Google Vision API(링크) 같은 서비스와 비교해서 어떤 장점과 차이가 있는지 궁금함

    • OmniAI에서는 자사 LLM과 클라우드 OCR을 서로 벤치마크함
      OmniAI 블로그 벤치마크(2025년 2월 기준)
      그 이후로 LLM이 빠르게 발전했음
      Qwen3-VL 계열, 특히 Qwen3-VL-235B-A22B-Instruct의 결과가 최근 들어 가장 좋게 나옴

    • 내 예상으로는 상용/독점 OCR 모델이 실제 문서에서 계속 더 우수할 듯함
      많은 양질의 프라이빗 트레이닝 데이터셋 덕분임
      퍼블릭 LLM은 arxiv, 이북 등 논문 중심 데이터로 훈련되었으니 실제 업무 문서에서는 떨어질 수밖에 없음
      LLM 방식이 문자 대체 오류(오타, 변형)는 줄이지만 한 페이지 전체 수준의 일관성은 오히려 낮음
      비 OCR LLM처럼 완전히 엉뚱한 결과를 낼 수도 있음

    • CJK 문자에서는 기존 방식의 OCR이 여전히 부적절한 치환을 많이 만들어냄
      너무 비슷한 문자가 너무 많아서 현미경이나 바이너리 레벨로만 구별 가능한 경우도 있음
      LLM은 가능한 문자 시퀀스에 더 제약을 주기 때문에 더 정확한 결과를 기대할 수 있음
      적어도 이런 고민 자체가 LLM 기반 OCR 도입에 대한 동기 부여가 됨

    • 다른 모델은 모르겠지만, 우리 회사는 Azure AI Document Intelligence로 이력서 파싱 시스템을 돌리고 있는데 꽤 만족함
      처음에 튜닝만 좀 신경 쓰면 되고, 최근 1년 동안은 거의 손볼 일 없음

  • 여러 VLM(Granite, Qwen 등 작은 모델부터 대형 모델까지) 테스트해봤는데, 기존 OCR 완전 대체에는 실망스럽다는 결론임
    우리 시스템은 고객 문서를 받아서, 요청한 대로 마크업된 표준 문서(래스터 방식의 다중 페이지 비트맵)를 돌려주는 구조임
    우리는 데이터에서 개별 문자나 단어 수준까지의 좌표 추출 정밀도가 중요한데, 실제로 VLM의 위치 정보는 지나치게 들쭉날쭉하거나, 완전 허상(hallucinated) 또는 너무 애매해서 원하는 정확도/세분성을 보장 못함
    현재까지는 Tesseract 기반에 결과물 정제(clean-up) 루틴을 쓰고, 구조화된 데이터셋이 없을 때만 VLM의 텍스트 출력을 가끔 보조적으로 활용함
    우리 케이스가 굉장히 적은 니즈이고, 대부분 사람에게는 그냥 텍스트 덤프나 Markdown/HTML 변환만 된다면 문제가 없을 것으로 추정함
    하지만 이런 모델들이 'OCR을 완전히 해결했다'는 주장과 실제 경험에는 꽤 큰 괴리가 있다고 느낌

    • moondream 3 preview 모델을 시도해봤는지 제안함
      블로그 포스트에서 여러 VLM의 성능을 능가한다고 하며, 가벼운 모델임
      메인 페이지, 모델, 블로그 참고

    • 고객 문서에 수기로 쓴 텍스트는 없는지 궁금함

    • CNN으로 먼저 텍스트의 바운딩 박스를 찾아내고, 각 박스마다 VLM을 수행하는 방법도 가능함

  • 개인적인 인상으로는 OCR이 어느 정도 해결된 문제라고 느꼈음
    OmniAI 벤치마크도 최근 모델로 업데이트되지 않았는데, 그 이유는 범용 LLM이 해당 벤치마크 자체 OCR보다 나아졌기 때문이라고 생각함
    실제로 각 페이지 이미지를 Gemini 2.5 Flash Lite에 넣고 Markdown 형식으로 추출하게 하면, 약 1000페이지당 20센트 정도 비용이 들고 결과물도 매우 좋았음
    요즘 OCR이 어려운 점이 뭔지 궁금함

    • 대부분 OCR/LLM(특히 Gemini Pro 2.5)조차도 복잡한 테이블 → Markdown/HTML 변환에서 여전히 힘들어함
      복수 헤더, 병합된 셀, 체크박스 있는 컬럼 등 문제가 빈번하고, 여러 페이지에 걸친 테이블도 제대로 이해 못함
      Llamaindex도 마찬가지로 심하게 실패함
      어떤 OCR/LLM이 이런 문제에서 더 나은지 궁금함
      예제 복잡 테이블, ICAO 체크리스트 전체 예시

    • 사실 OCR이 아니라 HTR(수기 필사/인식)은 여전히 까다로움
      LLM 덕분에 정확성이 많이 좋아졌지만, 실수는 사람이 찾기도 매우 어려워짐(못 읽는 부분을 아예 맘대로 지어내버림)

    • 인식이 안 되는 부분을 "모르겠다"고 알려주지 않고, 아예 임의로 상상해서 채우는 결과를 수용할 수 있다면야 문제없이 해결된 것임
      (비꼬는 게 아니라, 일부 상황에서는 실제로 괜찮기도 함)

    • 내가 OmniAI 벤치마크의 저자임
      최신 모델 업데이트가 없는 이유는 OCR API 자체를 제품에서 축소해서임
      내부적으로는 여전히 쓰고 있고 벤치마크는 게을러서 최신화 안 됨
      Gemini는 OCR에 가장 뛰어남
      단, 훈련 데이터와 너무 근접한 결과가 나오면 10% 정도 출력이 갑자기 끊겨버리는 'recitation' 오류가 자주 발생함
      PDF 믹스에서 빈 페이지가 들어가면 엉뚱한 내용을 새로 만들어내는 웃긴 할루시네이션도 있음
      OpenAI도 썩 나쁘진 않지만, GPT5는 GPT-4o나 4.1과 성능차 X
      헤더/푸터 등의 일부 내용이 자주 증발하고, 페이지가 옆으로 돌아간 경우 미쳐버림
      신분증, 의료서류, PII 위험 많은 내용을 스스로 거부하는 경우도 잦음

    • 절대 해결된 문제 아니라고 느낌
      독특한 레이아웃을 가진 잡지를 OCR하려 해보면 불가능함
      빈티지 잡지 모으면서 늘 최신 기술로 OCR 시도하지만, 항상 엄청난 사람 손이 들어가야만 됨

  • 작은 'OCR 모델' 없을지 궁금함
    공정 현장 사진에서 시리얼 번호만 뽑아내고, 전체 문서 파싱은 필요 없는 상황임
    30억 파라미터 모델로 이 정도 작업하는 건 너무 과함

  • DeepSeek-OCR이 Tesseract(링크)와 비교해 어떤지 궁금함
    나는 ocrmypdf(링크)를 애용하고, 로컬에서 너무 잘 쓰고 있음

    • 요즘 대다수의 벤치마크가 LLM/VLM 기반 대체품 위주로 언급됨
      실제로 tesseract가 80% 성능, 최신 모델이 95%까지 오른다 쳐도
      그 대가로 하드디스크 100배, 쿠버네티스/도커, GPU 16GB VRAM 등 인프라 요구에 치이는 구조면 그건 고려의 가치가 충분함

  • 최신 연구를 못 따라가는 입장에서 이게 뭔지, 왜 중요한지 ELI5(5살에게 설명하듯)로 쉽게 정리해줄 사람 있는지 궁금함
    github이나 논문의 제목은 OCR인데, 요약과 readme.md에는 LLM 컨텍스트 압축 얘기라 헷갈림
    어떻게 이 둘이 연결되는지, 상위 맥락에서 설명해줄 사람을 찾음

    • 예를 들어, 이미지에 1000단어(각 단어가 1토큰)가 있다고 가정하겠음
      이미지는 ‘1000 토큰’ 어치 정보를 담는 것임
      실제로는 이미지를 feature/임베딩으로 변환(디코딩)해야 하니까
      이미지가 만약 100개의 ‘이미지 토큰’으로 처리되고, 그 이미지 토큰이 1000개의 ‘텍스트 토큰’으로 변환됨
      순수히 디코딩 관점에서 봤을 때, 출력 정보를 10배로 압축해 전달한 거임
      LLM 입장에서는, 만약 10배 더 작은 잠재(latent) 표현으로 미리 압축할 수 있다면, 1000개의 토큰/임베딩 없이도 그 이상의 결과를 만들 수 있음을 의미함
답변달기