Unlimited OCR - 원샷 장기 범위 파싱

꽤 흥미로움. 이해한 바로는 연구진이 긴 문서를 읽을 때 AI가 메모리를 계속 쌓아두지 않게 하는 아키텍처 해킹을 찾은 것 같음
보통 AI가 100페이지 PDF를 전사할 때 이미 읽은 모든 단어를 기억하려고 하고, 이 단기 기억인 KV 캐시가 O(N)으로 선형 증가해서 VRAM이 바닥나거나 제한에 걸림. 그래서 개발자는 PDF를 페이지별로 쪼개 처리한 뒤 다시 붙이는 조잡한 코드를 만들게 됨
Unlimited OCR은 Reference Sliding Window Attention(R-SWA)으로 초점을 두 경로로 나눔. 하나는 원본 문서 이미지를 온전히 보는 전역 참조이고, 다른 하나는 모델이 직접 생성한 텍스트 기억을 최근 128단어 같은 좁은 이동 창으로 제한하는 지역 생성임. 로컬 AI에 꽤 흥미로울 것 같고, 커뮤니티가 뭘 만들고 확장할지 기대됨

대화에도 딱 맞는 지점이 있는 것 같음. 꽤 오래전부터 긴 대화 캡슐화를 실험해 왔는데, 잘 변하지 않는 상위 맥락과 사실이 있고, 참가자 이름이나 배경 같은 정보가 여기에 해당함
반면 오늘 아침에 뭘 먹었는지 같은 아주 세밀한 사실은 지금은 유용할 수 있지만 장기적으로는 일반적인 경향 외에는 별 의미가 없음. 대화를 재구성하려면 지금까지 논의된 모든 것을 끌어오지 않으면서 적절한 균형을 찾아야 해서, 이 방식은 더 살펴볼 가치가 있어 보임

논문 전체는 아직 안 읽었지만 지역 생성 창이 조금 작아 보임. 특히 이미지 입력은 토큰을 많이 쓰기 때문에, 지역 주의 층이 어디에 있느냐에 따라 최소 4096단어 정도로 더 크면 좋겠음

이미지 OCR을 할 때 정확히 이렇게 함. 큰 이미지 하나를 여러 작은 이미지로 잘라서 LLM에 보내면 매번 완벽했지만, 전체 이미지를 넣으면 결과가 형편없었음

주요 LLM 도구들은 이미 슬라이딩 윈도우 주의를 지원하는 줄 알았음

이래서 LeetCode가 쓸모 있음. LeetCode를 계속 풀다 보니 이런 기법들이 왜 존재하고 실제로 어떻게 쓰이는지 보게 됨. 흥미로운 게 많음

최근 악보용 태블릿을 샀는데, 주로 잼 세션에서 재즈 Real Book 묶음을 대체하려는 목적이었음. 휴대폰 카메라로 스캔한 것은 그럭저럭 괜찮지만 크기가 고정돼 있고 잡티가 많음
Bb나 Eb 악기용으로 즉석 조옮김을 할 수 있으면 좋겠지만, 스캔본이라 당연히 불가능함. 광학 악보 인식 상태를 파보니 음악은 AI 관점에서 거의 미개척지에 가깝다는 결론이 나옴. 광학 악보 인식은 꽤 형편없고, AI의 음악 이론 이해도 실제 악보를 보는 영역에서는 형편없음. LLM은 온라인 텍스트가 학습에 들어갔을 법한 이론 개념의 텍스트 설명은 그럭저럭 잘함
문제는 음악가가 읽는 종이 위 점들을 제대로 인코딩하는 디지털 형식이 아직 부족하다는 데 있는 것 같음. 악보 표기는 꽤 풍부함. MIDI는 주로 재생이나 연주에 필요한 측면을 담기 위해 만들어져서 상징적 이해에 필요한 모든 것을 담지 못함. MusicXML이 음악가가 원하는 정보를 담는 디지털 형식에 가장 가까워 보이지만, MusicXML 표현과 악보 이미지나 오디오를 연결하는 좋은 학습 말뭉치가 부족함. MusicXML만으로는 악보 조판에 필요한 정보가 충분하지 않기 때문인 듯함
MuseScore 같은 도구는 MusicXML로 표현할 수 없는 레이아웃 정보를 많이 추적해야 함. LilyPond 형식은 MusicXML보다 덜 장황하고 악보 제작자에게 유용한 정보를 조금 더 담지만, 대부분은 LilyPond로 악보를 만들지 않음. 덧붙이면 재즈 글꼴 상태 때문에 LilyPond가 아쉬움. 재즈 맥락에서 “클래식식” 악보를 보는 게 싫음. OCR은 꽤 좋아 보이는 incremental 개선을 볼 때마다 OMR의 처참함이 떠오름

“음악은 AI가 볼 때 거의 어디나 미개척지”라는 말이 정말 맞음. 여자친구가 음악학을 공부하는데, 신체장애 때문에 가끔 필기가 어렵다 보니 AI 기반 TTS/OCR 같은 앱을 조금씩 만들어 도와주고 있음
그러다 보면 음악이 어떤 AI 학습 데이터셋에서도 중요한 부분으로 고려된 적이 없다는 게 고통스러울 정도로 분명해짐. 요즘 Opus 4.8이 음악 이론을 이해하고 설명하는 능력은 꽤 놀랍지만, 악보를 전사하거나 OCR/OMR 하라고 하면 자신 있게 MusicXML/LilyPond 버전의 “2 + 2 = 말” 같은 결과를 내놓음. 이 무시된 영역도 커지는 AI 물결에 휩쓸리길 바라지만, 아직은 부당할 정도로 저평가되어 있음

음악 OCR 영역을 지켜보면 지금까지 정말 괜찮은 해법은 soundslice뿐인 것 같음. 스캔한 뒤 일부 엣지 케이스만 검토하면 결과가 아주 좋음. 작은 회사의 유료 서비스인데 충분히 후원할 만함

“Deepseek-OCR, Deepseek-OCR-2, PaddleOCR의 가치 있는 모델과 아이디어에 감사한다”고 적은 건 품격 있는 태도임

왜 비꼬는 건지 이해가 안 됨

참고로 “Unlimited OCR Works”는 Fate/stay night의 Unlimited Blade Works 패러디임. 원래 Unlimited Blade Works는 다른 사람이 만든 무기를 복제하는 마법이라는 설정임

논문은 https://arxiv.org/abs/2606.23050에 있음
참고로 책에서 읽은 인용문을 위한 작은 RAG 용도로 로컬 OCR을 하고 있고, 나도 RAM을 아끼려고 입력을 청크로 나누는데, 이런 자연스러운 접근이 스트리밍 모델에서도 통한다는 점이 흥미로움

Mistral이 방금 출시한 것보다 더 유망해 보임. 우연이라고? 아닐 것 같음
이 접근은 이미지 생성에도 어떤 조합으로 쓸 수 있을 듯함. 이미지를 읽거나 본 뒤 Illustrator/Inkscape 같은 도구나 SVG로 그리기 시작하고, 빠진 부분을 나중에 채우는 식으로 가능해 보임

내가 세상 물정 모르는 사람처럼 들리겠지만, 회사들이 진짜 좋은 소프트웨어를 오픈소스로 공개하는 실제 이유가 뭘까?
Baidu나 Google이라면 경쟁사가 따라 하지 못하게 혼자 보유해서 가치를 뽑아내야 하는 것 아닌가?

대기업 안에도 오픈소스의 이상을 믿고 고용주를 설득해 프로젝트 공개를 허락받는 사람들이 있음
회사는 명성을 얻고, 이는 채용 퍼널에 도움이 됨. 때로는 Meta가 Ollama를 공개한 것처럼 전략적으로 경쟁사를 흔들 수도 있음

오픈소스 모델 공개는 미국 AI 연구소들의 매출을 빼앗을 수 있음. 그 연구소들이 장기 경쟁에서 이기기 위해 재투자할 돈을 줄이면 중국에 도움이 될 수 있음

AI로 OCR을 해본 시도는 항상 지어낸 결과물이 섞였고, 그래서 프로덕션에 쓰기 어려웠음. 이것도 그런 문제가 있는지 궁금함
간단한 예로 다른 언어로 남아 있어야 할 단어들이 자동으로 영어로 번역되어 효과를 망치는 경우가 있음

거의 단어보다 큰 수준의 기계학습, 즉 단어쌍·구·문장·문서·말뭉치 수준은 원하지 않게 됨
전사에서는 거의 확실한 결과를 원하거나, 확실히 읽을 수 없었다는 표시를 원함. 문맥으로 추측할 수는 있지만, 어떤 OCR에서는 글자들이 순서대로 모여 단어를 이룬다는 사실 외의 근거로 추측한 것인지 알아야 함
예를 들어 familysearch.com의 인구조사 문서에서 전사자가 이름을 Joseph으로 “교정”했는데, 손글씨 문서의 실제 글자는 Josepth였고, 실제로 그 지역 변형 철자였음. 다른 문서에서는 작성자가 “Joh”를 약어로 썼고, 아마 인간 전사자가 John으로 옮겼는데, 가장 그럴듯하긴 해도 실제로는 틀렸음. 어떤 때는 추측이라는 사실이 중요하고, 어떤 때는 그냥 최선의 추측이 필요함

100% 인식 결과를 원한다면 이 방법에 원본 문서 재구성 이미지 모델을 결합하겠음. 전사 텍스트와 레이아웃을 맞춰 원본 문서를 다시 만들게 하는 방식임
테스트하려는 페이지나 문단만 제외하고 나머지 문서를 사용하면, 이미지 아티팩트에서 시험 대상 구절을 그대로 재생성하는 걸 피할 수 있음. 재구성 뒤에는 어긋난 문자를 특정해 맞춰보는 광학 비교를 해서 오류를 찾고 반복하면 됨. 비싸겠지만 100% 인식을 보장할 수 있음

4090에서 이 모델로 일본어 문법 PDF를 전사해보고 있음. 영어로 쓰였고 일본어 예문이 많은 문서인데, 내가 일부 대조해본 범위에서는 꽤 잘 작동함
출력은 필요한 곳에 한자/히라가나와 영어를 적절히 유지하고, 번역하려고 하지 않음. 한 시간에 약 200페이지를 변환했음