Llama-OCR: 문서를 Markdown으로 변환하는 기술

 (llamaocr.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 문서 이미지를 텍스트로 옮긴 뒤 다시 정리해야 하는 작업을 구조화된 Markdown 변환으로 줄여주는 웹 도구임
  • 현재 웹 입력은 이미지 업로드 중심이며, PDF 지원은 곧 제공될 예정이라고 안내함
  • 서비스는 npm 패키지 llama-ocr와 Together AI를 기반으로 동작함
  • JavaScript에서는 ocr 함수에 filePath와 TOGETHER_API_KEY를 넘겨 Markdown 결과를 받을 수 있음
  • 웹 업로드와 코드 호출을 모두 지원해, 문서 이미지 변환을 수동 작업이나 개발 흐름에 맞춰 시도할 수 있음

이미지 문서를 Markdown으로 변환

  • LlamaOCR.com은 업로드한 문서를 Markdown으로 바꾸는 도구임
  • 웹 페이지는 “Upload an image to turn it into structured markdown”이라고 안내하며, 이미지 업로드로 구조화된 Markdown을 생성함
  • PDF 지원은 “soon”으로 표시되어 있어, 현재 제공 범위는 이미지 중심임

코드에서 사용하는 방법

  • npm 패키지 llama-ocr를 사용하면 JavaScript 코드에서 OCR을 실행할 수 있음
import { ocr } from 'llama-ocr';

const markdown = await ocr({
  filePath: './trader-receipt.jpg',
  apiKey: process.env.TOGETHER_API_KEY
});
  • 예시는 filePath에 이미지 파일 경로를 넣고, apiKey에 TOGETHER_API_KEY 환경변수를 전달함
  • 서비스는 llama-ocr와 Together AI를 기반으로 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • llama-ocr 만든 사람임. 공유와 좋은 반응에 감사함. 간단한 OCR API가 필요해서 이번 주 초에 만들었고, Together.ai에서 호스팅되는 Llama 3.2 Vision으로 이미지를 구조화된 Markdown으로 파싱함
    npm 패키지로도 제공 중임. PDF 파싱, JSON 응답 같은 기능도 추가할 계획이고, 질문이 있으면 답해보겠음

    • 동일한 항목 3개가 있는 청구서를 넣었더니 평소처럼 글머리표 3개로 내보내지 않고, 원본 종이에 없는 quantity 열이 있는 표를 만들어냈음
      이런 정도의 큰 변환이 기대하거나 바람직한 동작인지 궁금함. 출력이 어떤 때는 글머리표 목록이고 어떤 때는 표라서, 이후 자동 처리가 조금 더 어려워짐
    • 포스터 PDF에서 과학 콘텐츠를 뽑아내는 데 어려움이 있었고, 예를 들어 Nougat은 레이아웃이 달라지면 무너지는 경우가 많았음
      이런 사용 사례도 고려해봤는지 궁금함
    • “Need an example image? Try ours.”는 좋은 아이디어임. 더 많은 서비스가 비슷한 기능을 제공하면 좋겠음
    • 정확도가 어느 정도인지 궁금함
      기존 OCR 시스템과 비교했을 때 어떤 종류의 실수를 하는지 알고 싶음
    • 로컬 LLM을 쓰는 옵션도 가능할지 궁금함

  • 이건 이미지를 Llama 3.2 Vision에 보내서 텍스트를 읽어달라고 하는 것뿐임
    다른 LLM 출력과 마찬가지로 환각에 취약함. 픽셀에서 문자 모양을 읽는 게 아니라, 학습한 이미지와 캡션을 바탕으로 그림을 설명하면서 텍스트를 판단하기 때문임. 특히 읽기 어려우면 단어를 완전히 지어낼 수 있음

    • 다른 OCR 시스템도 마찬가지였고, 다만 이 맥락에서는 그런 오류를 환각이라고 부르지 않았을 뿐임

  • 멋져 보임. 최근 OCR을 많이 하고 있어서 이 분야에 새 도구가 생긴 게 반가움. PDF→Markdown 분야의 현재 강자는 아마 Facebook의 Nougat[1]이고, 이걸 DSPy에 연결해서 철학책에는 어느 쪽이 더 나은지 비교해보고 싶음
    이 저장소가 링크한 스타트업의 Zerox[2] 프로젝트도 좋아 보이고, 적어도 Nougat보다 홍보는 훨씬 매끄러움. 실제 전문가가 지나간다면 정정이나 조언을 듣고 싶음
    궁금한 점은 두 가지임. 1) Together.ai가 무엇이고 이 모델이 오픈소스인지 궁금함. 웹사이트는 호스팅 서비스처럼 보이고 “Custom Models” 페이지[3]는 자체 독점 모델 학습보다는 맞춤 미세조정에 가까워 보임. HuggingFace 프로필이 있는 것 같지만 진짜 그들 것인지는 애매함 https://huggingface.co/TogetherAI
    2) GitHub에는 “hosted demo”라고 되어 있는데, 호스팅되는 부분은 작은 깔끔한 WebGUI뿐인 것 같음. 이 기능은 지금도 앞으로도 API 호출로만 사용할 수 있다는 뜻인지 궁금함
    추신: 데스크톱 브라우저에서 헤더 링크가 깨져 있고 onClick이 트리거되지 않음
    [1] https://facebookresearch.github.io/nougat/
    [2] https://github.com/getomni-ai/zerox
    [3] https://www.together.ai/products#custom-models

    • 프로젝트 작성자는 Together.ai DevRel임. 그래도 개발자 도구를 홍보하는 방식으로는 훌륭함
    • together.ai가 데모를 적어도 일부 후원하고 있을 것 같음
    • 개인정보 보호와 비용 때문에 자가 호스팅할 수 있는 걸 기대했음
    • together.ai는 멀티모달 Llama 3.2를 포함해 오픈소스 모델 100개 이상을 OpenAI 호환 API로 제공함

  • 특이한 점이 있었음. 예시로 웹코믹을 올렸는데 모든 대사가 대문자였지만, 출력은 패널마다 문장형 대소문자와 제목형 대소문자가 일관되지 않게 섞였음
    실제로 OCR을 쓰고 싶은 문제도 시험해봤음. 디지털화가 필요한 오래된 슬라이드가 있고 대부분 라벨이 붙어 있는데, 하나를 올리니 슬라이드나 필름 프레임 사진처럼 보인다며 오래되어 누렇게 변했고 중앙에 어두운 직사각형 컷아웃이 있으며, 텍스트는 “Once Upon a Time”, 숫자는 “1069”라고 설명했음
    불필요하게 반복적인 슬라이드 설명도 문제지만, 실제 글자는 필기체도 아니고 “Once Uniquitous.”였으며 숫자는 106g였음. ‘9’가 아니라 ‘g’가 아주 명확했음
    흥미로운 건 모델 편향의 사례일 수 있다는 점임. 슬라이드를 너무 골동품처럼 본 나머지 완전히 진부한 제목을 환각했고, 검은 사각형은 투명 부분이 보이지 않도록 앞에서 빛을 비춘 결과였는데 그걸 놓쳤음
    추가로 API 자체에 문서화되지 않은 파일 크기나 해상도 제한이 있는 것 같음

  • 최근 자선 경매용 종이 입찰 시트를 처리하는 데 llama3.2-vision을 써봤고, 꽤 형편없는 손글씨도 상당히 정확했음. 내년 행사에도 쓰고 싶음
    다만 CSV를 일관되게 출력하게 만들기 어려운 점은 꽤 짜증남. ChatGPT와 Gemini가 그 부분은 더 나아 보이지만 자동화까지 해보진 않았음
    규모는 입찰 시트 약 100쪽이라 어느 정도 수작업 정리는 괜찮음. 자원봉사자 시간을 태우는 것보다는 확실히 나음
    https://github.com/philips/paper-bidsheets

    • 이 작업에 Handwriting OCR(https://www.handwritingocr.com)이 어느 정도 비교되는지 듣고 싶음
      무료는 아니지만 손글씨 문서 정확도는 최고 수준임. 내가 창업자라 편향은 있지만, 지금 정확도 수준이 정말 기대됨. 100쪽 프로젝트라면 12달러밖에 들지 않아 시간을 아낄 수 있음
    • OCR 부분은 llama3.2-vision에 맡기고, CSV 변환은 ChatGPT에 넘기는 방식은 어떨까 싶음

  • 최근 OCR을 많이 했고, 주로 가족사진 속 텍스트를 디지털화하는 작업이었음. 일반 OCR 모델은 형편없고 LLM이 훨씬 잘했음. 테스트한 모델 중에서는 Gemini Flash가 압도적으로 좋았지만, 그래도 실패와 환각이 충분히 많아서 손으로 입력하는 게 더 빨랐음
    거의 될 것처럼 느껴지는데 안 되는 게 짜증남. 이 도구는 더 나빠 보임. 어떤 때는 텍스트만 답하고, 어떤 때는 “The image is a scanned document with handwritten text...” 같은 전체 설명을 내놓음. Gemini Flash를 이길 수 있게 미세조정 같은 게 있길 기대했는데, 그러면 시간을 많이 아낄 수 있었을 텐데 아쉬움

    • 이미지를 다운스케일해봤는지 궁금함. 낮은 해상도 이미지에서 더 나은 결과가 나오기 시작했음. 휴대폰 카메라로 만든 스캔을 사용했음
      convert -density 76 input.pdf output-%d.png
      https://github.com/philips/paper-bidsheets
    • 일반 모델 기준으로는 오픈소스 OCR의 상태가 꽤 형편없음. 안타깝게도 Microsoft, Google 같은 비공개 옵션이 훨씬 나음. 그런 것도 써봤는지 궁금함
      Flash가 흥미로운데, 어떤 LLM들을 테스트했는지도 궁금함
    • 최근 gpt-4o로 이미지 말뭉치에 OCR을 돌려 꽤 좋은 결과를 얻었음. 깨달은 가장 중요한 점은 화려한 LLM을 쓰더라도 평범한 데이터 준비가 여전히 중요하다는 것임
      이미지를 텍스트 부분만 남기도록 자르고 테두리를 제외한 뒤 대비를 높였더니 엄청나게 도움이 됐음. 2015년에 쓴 글인데 GPT에도 여전히 잘 들어맞음: https://www.danvk.org/2015/01/07/finding-blocks-of-text-in-a...
      GPT에는 한 번에 전체 페이지보다 몇 문단 이하만 주는 편이 더 나았음. 텍스트가 짧을수록 환각 가능성이 줄어듦
    • 나도 지금 정확히 같은 일을 하려는 중이라 아쉬움. 가족사진을 디지털화하고 있고, 일부는 뒷면에 독일어가 있음
      최근 화제가 된 OCR은 형편없었고, 이건 더 낫길 바랐음. 개별 이미지를 채팅에 붙여넣을 때는 ChatGPT 4o가 좋았지만 API는 아직 안 써봤음. 6500장 사진을 처리하면 비용이 얼마나 들지 모르겠고, 그중 빈 사진도 많지만 쉽게 걸러낼 방법도 없음
    • Claude를 써봤는지 궁금함
      텍스트 위치를 반환하는 건 아직 좋지 않지만, 내가 테스트한 범위에서는 OCR 성능이 엄청났음

  • 이게 “Show HN” 게시물이어야 하는지 의문임. 그냥 프론트엔드처럼 보이고, 이름의 Llama와 직접 연결 지을 만한 부분도 없어 보임. together.ai가 클라우드 공간을 제공했을 수도 있겠음

  • 유전 알고리즘으로 원 500개를 배치해 문장을 만들고, 실제 물리적인 원으로 그린 문장을 넣어봤음
    https://www.instagram.com/marekgibney/p/BiFNyYBhvGr/
    흥미롭게도 원들은 잘 인식하지만 문장은 못 봄. “이미지에는 Markdown으로 표현할 수 있는 텍스트나 요소가 없고, 원들의 시각적 구성일 뿐 Markdown으로 번역할 정보가 없다”는 식으로 답했음

    • 눈을 가늘게 뜨면 읽힌다는 점에 착안해 이미지에 가우시안 블러를 적용했더니, 흐릿한 텍스트가 “STOP THINKING IN CIRCLES.”라고 읽힌다는 응답을 받았음
      응답이 결정적이지 않아서 원본 이미지도 여러 번 시도했지만 한 번도 성공하지 않았음. 반면 적용한 모든 저역통과 필터 효과는 높은 성공률로 작동했음
      https://imgur.com/q7Zd7fa
    • 나도 이건 못 읽겠음
      멀리서 보면 더 읽기 쉬움
    • 원래 LLM이 이런 원본 소재로 학습된 적이 있었을까 싶음
      유전 알고리즘 사용 방식은 꽤 멋짐. 코드나 최소한 보상 함수를 보고 싶음
    • 정답을 보기 전에는 나도 “stop” 말고는 아무것도 못 읽겠음
    • 왜 흥미로운지 모르겠음. 이미지는 아무것처럼 보이지 않고, 글자를 보려면 각도를 틀어 봐야 겨우 보임

  • 웃겼음. 긴 문서의 스크린샷 3장을 넣었더니 비교적 잘 처리했지만, 교정하면서 보니 AI가 원문에 없는 문단을 만들어냈음
    아마 스크린샷 특성상 일부 문장이나 문단이 중간에서 잘렸고, 그게 LLM의 빈칸 채우기 성향을 자극한 듯함. 끝나지 않은 문단을 그대로 두지 못했고, 원본 문서에는 전혀 없던 짧은 결론 문단까지 넣었음

    • 무언가를 지어낼 가능성이 조금이라도 있는 기술이 실제 세상에서 사용 대상으로 고려된다는 게 이해가 안 됨

  • 1997년 Asus P3B-F 메인보드 회로도의 오래된 스캔을 넣어봤음
    제목 블록의 일부 텍스트, 예를 들어 프로젝트명과 날짜 정도만 추출했고, 글꼴이 뚜렷한데도 8/B와 1/I를 모두 섞어버렸음
    실제로 유용한 정보는 “Tables / Table 1: [Insert table 1 here] / Other Elements / [Insert other elements here]” 같은 식으로 바뀌었음

답변달기