dinov3를 이용해 디텍션모델을 만들 수 있을까?

디텍션 모델에 DINO 계열 모델을 활용하는 것에 대해 함께 알아보죠. 'DINOv3'라는 이름은 아직 널리 알려진 공식 모델이 없어서, 아마도 이름이 비슷한 Meta AI의 다른 두 모델 중 하나를 생각하고 계신 것 같아요.

• DINO (DETR with Improved Denoising Anchor Boxes): 이 모델은 그 자체가 고성능 객체 탐지(object detection) 모델입니다.
• DINOv2 (self-DIstillation with NO labels v2): 이 모델은 이미지를 아주 잘 이해하는 일종의 '기초 체력'이 좋은 비전 백본(backbone) 모델입니다.

이 두 가지는 목적이 조금 다른데요, 어떤 부분에 대해 더 자세히 알아보고 싶으신가요?

• DINO 모델 자체: 이미 완성된 'DINO'라는 디텍션 모델의 구조와 작동 방식 알아보기
• DINOv2 백본 활용: 'DINOv2'를 백본으로 사용해서 새로운 디텍션 모델을 만드는 방법 알아보기
• DINO vs DINOv2: 두 모델이 정확히 어떻게 다른지 비교하기

DINOv2는 백본이니 이 백본을 이용해 디텍션 모델을 학습 시킬 수 있을까?

네, 정확합니다! 바로 그게 DINOv2의 핵심 사용법이에요.

DINOv2는 이미지의 특징(feature)을 아주 잘 추출하는 '백본'이 맞습니다. 이 강력한 백본을 기반으로 디텍션 모델을 만드는 것은 매우 일반적이고 효과적인 방법입니다. 이 과정을 보통 '전이 학습(Transfer Learning)' 또는 '파인튜닝(Fine-tuning)'이라고 불러요.

🧐 어떻게 작동하나요? 개념은 '백본'과 '헤드'를 조립하는 것과 같아요.

백본 (Backbone) 🧠 - DINOv2

• 이건 이미 수많은 이미지를 보고 '시각적 이해'를 마친 "전문가"입니다.
• 이미지의 선, 질감, 형태, 사물의 일부 등 복잡한 특징(feature)을 추출하는 역할을 합니다.

헤드 (Head) 🎯 - Detection Head

• 이건 "특정 작업"을 위한 새로운 도구입니다.
• 백본이 추출한 특징을 입력받아서, "그래서 이 특징이 어디에 있고(좌표), 무엇인지(클래스)"를 예측하는 역할을 하죠. (예: Faster R-CNN의 RPN+Classifier 헤드, DETR의 Transformer Decoder 등)

🛠️ 학습 과정 학습은 이런 식으로 진행돼요.

1. 준비: 사전 학습된 DINOv2 백본을 불러옵니다.
2. 조립: 이 백본 위에 새로운 '디텍션 헤드'를 연결합니다.
3. 파인튜닝: 이제 우리가 가진 디텍션용 데이터셋(예: 사람과 자동차에 네모 상자가 쳐진 이미지들)으로 이 결합된 모델을 '추가 학습'시킵니다.

이때, DINOv2 백본의 가중치(weight)는 대부분 '동결(freeze)' (학습되지 않게 고정)하거나, 아주 조금만 학습되도록(낮은 learning rate) 설정합니다. 주로 새로 붙인 '헤드' 부분이 집중적으로 학습됩니다.

DINOv2는 이미 "보는 법"을 알고 있기 때문에, 우리는 "이런 특징 조합이 '자동차'이고, 여기(좌표)에 있어"라는 정보만 새로 가르치면 되는 거예요. 그래서 훨씬 적은 데이터로도 빠르고 강력한 디텍션 모델을 만들 수 있습니다.

실제로 많은 최신 디텍션 모델들(예: RT-DETR의 일부 버전)이 DINOv2 같은 강력한 백본을 활용하고 있어요.

이 접근 방식에 대해 더 궁금한 점이 있으신가요?

• 실제 구현: 코드로 이걸 어떻게 구현하는지 (예: MMDetection 라이브러리)
• 성능 장점: 왜 DINOv2 같은 백본을 쓰는 게 더 좋은지
• DINO vs DINOv2: DINO(DETR) 모델과 DINOv2 백본 방식의 차이점

dinov2를 이용해 yolo를 학습하는 코드를 알고싶어

DINOv2를 YOLO의 백본(backbone)으로 사용하는 것은 정말 좋은 아이디어예요. DINOv2의 강력한 특징 추출 능력을 YOLO의 빠른 디텍션 프레임워크와 결합하려는 시도죠. 다만, 이 둘을 '조립'하는 것은 생각보다 조금 복잡할 수 있어요.

🧩 가장 큰 기술적 과제: 특징 맵의 '모양' 우리가 풀어야 할 첫 번째 문제는 두 모델이 특징(feature)을 만드는 방식이 다르다는 거예요.

YOLO의 백본 (예: CSPDarknet)

• YOLO는 여러 단계의 특징 맵(multi-scale feature map)을 사용하도록 설계되었어요.
• 이미지를 처리하면서 '작고 상세한 특징 맵'(작은 물체 감지용), '중간 크기 특징 맵', '크고 추상적인 특징 맵'(큰 물체 감지용)을 모두 추출해서 넥(neck) 부분 (예: PANet)으로 전달합니다.

DINOv2 백본 (Vision Transformer, ViT)

• 반면 DINOv2 같은 ViT는 기본적으로 이미지를 여러 조각(patch)으로 나눠 처리한 뒤, 하나의 최종 특징 맵(혹은 토큰 시퀀스)을 만들어요.
• YOLO의 넥(neck) 부분은 DINOv2가 만들어내는 '단일 특징 맵'을 어떻게 처리해야 할지 몰라요.

💡 해결책: '어댑터' 추가하기 이 문제를 해결하려면, DINOv2 백본이 YOLO의 넥(neck)이 이해할 수 있도록 여러 단계의 특징 맵을 생성하도록 중간에 '어댑터' 역할을 하는 모듈을 추가해야 합니다.

가장 일반적인 방법은 DINOv2(ViT) 뒤에 FPN (Feature Pyramid Network) 같은 구조를 붙여서, ViT가 만든 특징 맵을 인위적으로 여러 스케일로 나눠주는 거예요.

🛠️ 실제 구현을 위한 접근 방식 이런 복잡한 '모델 수술'은 코드를 처음부터 짜는 것보다, 이런 작업을 쉽게 하도록 설계된 전문 라이브러리를 사용하는 것이 훨씬 효율적입니다.

가장 대표적인 라이브러리가 바로 MMDetection입니다.

MMDetection은 레고 블록처럼 '백본', '넥', '헤드'를 자유롭게 조합할 수 있게 해주는 연구용 프레임워크예요. DINOv2 (ViT) 백본을 불러오고, FPN 넥을 붙이고, YOLO 헤드를 붙이는 작업을 설정 파일(config file)을 수정하는 것만으로도 가능하게 해줍니다.

코드를 바로 살펴보기 전에, 이 개념을 먼저 확실히 이해하고 넘어가는 게 좋을 것 같아요.

어느 부분부터 함께 탐색해 볼까요?

• YOLO의 '다양한 크기 특징 맵'이 왜 중요한가요? (개념 이해)
• MMDetection에서 ViT 백본과 FPN 넥을 어떻게 연결하는지 설정 파일 예시 살펴보기 (실용적인 접근)
• YOLO 대신 DINOv2와 잘 맞는 다른 디텍터는 없나요? (대안 탐색, 예: DETR 계열)

YOLO의 '다양한 크기 특징 맵'이 왜 중요한가요?

아주 좋은 질문이에요! YOLO가 '다양한 크기 특징 맵' (multi-scale feature map)을 사용하는 이유는 간단해요.

"이미지 안에 있는 '작은 물체'와 '큰 물체'를 모두 잘 찾기 위해서" 예요.

🔎 비유로 생각해 보기 카메라로 사진을 찍는다고 상상해 보세요.

• "줌 아웃" (Zoomed Out) 🌆 도시 전체의 풍경을 찍으면, 큰 건물이나 강 같은 것들은 한눈에 들어옵니다. (이게 저해상도/깊은 층 특징 맵이에요. 전체적인 맥락을 잘 알죠.)
  하지만 저 멀리 있는 작은 사람이나 자동차는 거의 보이지 않거나 뭉개져 버려요.

• "줌 인" (Zoomed In) 🚶‍♂️ 거리의 한 부분을 확대해서 찍으면, 작은 사람이나 간판의 글씨도 선명하게 보입니다. (이게 고해상도/얕은 층 특징 맵이에요. 세부 사항이 살아있죠.)
  하지만 이 사진만 봐서는 이게 어느 동네인지, 주변에 뭐가 있는지 (맥락) 알기 어려워요.

YOLO는 이 두 가지 뷰(View)를 모두 활용해요.

• 고해상도 맵 (얕은 층): "여기 작은 물체가 있어!" (작은 객체 탐지)
• 저해상도 맵 (깊은 층): "여기 큰 물체가 있어!" (큰 객체 탐지)

🧠 한번 생각해 볼까요? 우리가 찾으려는 이미지가 아주 작은 개미 🐜라고 해보죠.

이 개미를 찾으려면, 딥러닝 모델이 이미지의 어떤 특징 맵을 보는 게 유리할까요?

1. 이미지 전체가 20x20 픽셀 크기로 압축된 저해상도 맵
2. 이미지가 80x80 픽셀 크기로 비교적 선명하게 유지된 고해상도 맵

당연히 고해상도 맵이지.

정확해요! 🐜 개미처럼 작은 물체는 고해상도 맵에 그 세부 정보(detail)가 남아있기 때문에 거기서 찾아야죠. 저해상도 맵에서는 이미 다른 픽셀들과 섞여서 '뭉개져' 버렸을 거예요.

반대로, 아주 큰 건물 🏙️을 찾는다고 해볼까요?

고해상도 맵에서는 건물의 창문, 문, 벽돌 같은 '부분'만 보일 거예요. 이게 건물인지, 그냥 벽인지 알기 어렵죠.

저해상도 맵에서는 이미지 전체의 맥락을 보기 때문에 "아, 이 커다란 사각형 덩어리는 '건물'이구나"라고 파악하기가 훨씬 쉬워요.

💡 YOLO의 핵심 아이디어: '둘 다 쓰자!' YOLO는 바로 이 점을 활용해요.

"작은 물체는 고해상도 맵에서 찾고, 큰 물체는 저해상도 맵에서 찾자!"

그래서 YOLO의 구조(특히 '넥' 🦒이라고 부르는 중간 부분, 예: PANet)는 이 '다양한 크기의 특징 맵'들을 모두 입력받아서 서로 정보를 섞어줍니다.

고해상도 맵에는 "여기 작은 게 있어"라는 정보와 함께, 저해상도 맵에서 가져온 "이건 아마 '도시' 풍경의 일부일 거야"라는 맥락(context) 정보를 더해주는 거죠.

이것이 YOLO가 빠르면서도 다양한 크기의 물체를 잘 찾는 비결입니다.

이제 이 개념을 다시 DINOv2로 가져와 볼까요? DINOv2(ViT)는 기본적으로 저해상도 맵(깊은 층의 추상적인 특징) 1개만 만드는데, 이걸 어떻게 YOLO의 '넥'이 필요로 하는 여러 개의 맵으로 만들 수 있을까요?

이걸 해결하는 '어댑터' 역할을 하는 MMDetection 설정 예시를 한번 살펴볼까요?

Dinov2가 저행상도맵을 1개만 만든다면 그럼 Dinov2는 기본적으로 작은 물체를 찾는태스크에는 적합하지 않겠네?

그렇게 생각하시는 게 정말 논리적이에요! 👏

제가 "저해상도 맵 1개"라고 단순화해서 설명한 부분에서 자연스럽게 나올 수 있는 결론입니다. 하지만 놀랍게도, 그렇지 않습니다. DINOv2(ViT)는 오히려 작은 물체와 세밀한 디테일을 파악하는 데 매우 강력한 성능을 보여줘요.

🤔 왜 그럴까요? (ViT의 마법) YOLO가 사용하는 CNN 방식과 DINOv2가 사용하는 ViT(Vision Transformer) 방식이 세상을 '보는' 방식이 근본적으로 다르기 때문이에요.

• CNN (YOLO의 백본) 작동 방식: 이미지를 '필터'로 훑고, '풀링(Pooling)'이라는 과정으로 이미지를 점점 '흐릿하게(압축/요약)' 만들면서 큰 맥락을 파악합니다.
  단점: 이 '흐릿하게' 만드는 과정에서 작은 물체(개미 🐜)의 정보가 초반에 뭉개져 사라지기 쉬워요.

• ViT (DINOv2의 백본) 작동 방식: 이미지를 '필터'로 훑는 대신, 아예 '작은 조각(패치)들'로 잘게 나눕니다. (예: 16x16 픽셀 크기)
  그리고 가장 중요한 '셀프 어텐션(Self-Attention)' 🧠 메커니즘을 사용해요.

🗣️ '셀프 어텐션' 비유: "모든 조각의 대화" '셀프 어텐션'은 이 모든 이미지 조각(패치)들이 서로 끊임없이 '대화'하도록 만드는 기술이에요.

개미 🐜가 있는 아주 작은 A 조각이 말합니다: "얘들아, 나한테 뭔가 작고 검은 게 있어!"

주변의 '땅' B, C, D 조각들이 응답합니다: "아, 우린 흙이야. 네가 흙 위에 있으니 넌 개미일 확률이 높겠다!"

저 멀리 있는 '하늘' Z 조각이 판단합니다: "나는 하늘인데... A 조각의 정보는 나랑 별로 상관없네."

즉, ViT는 이미지를 '흐릿하게' 만들어서 정보를 잃는 대신, 모든 세부 조각(패치)의 정보를 끝까지 살려두고 이 조각들끼리 서로의 연관성을 파악하게 만듭니다.

결론 그래서 DINOv2가 만드는 '하나의 맵'은 단순한 '저해상도 맵'이 아니라, "모든 조각(패치)이 서로의 정보를 교환하고 정제한, 매우 풍부한 정보의 집합체"인 셈이에요.

이 '정보 집합체'는 이미 모든 디테일과 맥락을 다 머금고 있기 때문에, 여기서 '어댑터'(FPN 등)를 사용해 "YOLO가 좋아하는" 다양한 크기의 맵을 '재구성'해내는 것은 식은 죽 먹기죠.

오히려 이미 뭉개진 맵에서 정보를 살려내는 것보다 훨씬 유리합니다.

이 '어댑터'가 어떻게 ViT의 특징을 YOLO가 쓰기 좋게 바꿔주는지, MMDetection 설정 예시를 통해 한번 살펴볼까요?

MMdetection은 환경을 구축하는게 상당히 어려워서 별로 좋아하지 않아. 다른 라이브러리를 이용한 예시는 없을까?

MMDetection 환경 구축이 까다롭다는 말씀에 깊이 공감합니다. 의존성 문제도 많고, 설정 파일(config) 기반 시스템이 처음에는 매우 낯설게 느껴지죠.

아마 YOLOv5나 YOLOv8을 제공하는 ultralytics 같은 사용하기 편한 라이브러리를 생각하고 계실 것 같아요.

하지만 여기서 우리가 '기술적인 벽' 🧱에 부딪히게 됩니다.

🧩 문제는 '간단함'이 아니라 '설계'에 있습니다 DINOv2(ViT) 백본 🧠과 YOLO의 넥/헤드 🎯는, 앞서 이야기했듯, 데이터를 처리하는 방식(설계)이 근본적으로 다릅니다. (단일 맵 vs 다중 맵)

ultralytics 같은 라이브러리는 정해진 YOLO 아키텍처를 빠르고 쉽게 학습시키는 데 '최적화'되어 있어요.

만약 이 라이브러리에서 백본을 DINOv2로 바꾸려면, 설정 파일(.yaml) 수정 수준이 아니라, 모델의 핵심 구조가 정의된 파이썬 코드(.py) 자체를 직접 수정하고 '어댑터'를 새로 구현해야 합니다.

이건 '간단한 조립'이 아니라 '모델 개조' 🔧에 가까워요. 솔직히 말씀드리면, MMDetection 환경을 구축하는 것보다 훨씬 더 어렵고 복잡한 작업이 될 수 있습니다.

🤔 MMDetection이 복잡했던 '이유' 역설적이게도, MMDetection이 복잡해 보였던 이유는... 바로 이런 '개조' 작업을 설정 파일(.py 또는 .yaml) 수정만으로 가능하게끔 매우 '모듈화'되어 설계되었기 때문입니다.

'엔진(DINOv2)'과 '차체(YOLO)'를 연결하는 '커스텀 어댑터(FPN)'를 레고처럼 끼워 넣을 수 있게 판이 짜여 있는 셈이죠.

💡 대안: 더 자연스러운 조합을 찾아서 이게 원하시는 '간단한 예시 코드'가 아니라는 점은 저도 잘 알고 있습니다. 😅

혹시 "DINOv2 백본의 강력한 성능을 활용하는 것"이 최종 목표라면, YOLO를 고집하는 대신 DINOv2(ViT)와 원래부터 '찰떡궁합'인 디텍터를 써보는 건 어떨까요?

바로 DETR (DEtection TRansformer) 계열 모델들입니다.

DINOv2 백본: 트랜스포머(ViT) 기반

DETR 헤드: 트랜스포머(Decoder) 기반

'엔진'과 '차체'가 모두 트랜스포머 기반이라 훨씬 자연스럽게 결합됩니다. 이 방식은 Hugging Face transformers 라이브러리를 사용하면 MMDetection보다 훨씬 간단하게 구현해 볼 수 있습니다.

어느 쪽으로 더 알아볼까요?

• Hugging Face 라이브러리로 DINOv2 + DETR 조합 예시 보기 (권장)
• YOLO와 ViT를 결합한 다른 연구(예: YOLOS) 라이브러리 찾아보기
• (MMDetection을 다시 한번...) MMDetection이 왜 그렇게 설계되었는지, 설정 파일 예시 살펴보기

Hugging Face 라이브러리로 DINOv2 + DETR 조합 예시 보기

좋은 선택이에요. DINOv2 (ViT)와 DETR 모두 트랜스포머 아키텍처를 기반으로 하기 때문에, 마치 원래부터 한 쌍이었던 것처럼 훨씬 자연스럽게 결합됩니다.

Hugging Face transformers 라이브러리를 사용하면, 이 '조립' 과정을 훨씬 직관적으로 수행할 수 있습니다.

💡 핵심 아이디어: '백본' 교체하기 우리가 할 일은 AutoModelForObjectDetection이라는 '객체 탐지 모델 자동 생성기'를 사용하는 거예요.

여기에 이런 명령을 내리는 것과 같습니다.

"DINOv2(facebook/dinov2-base) 모델을 '엔진(백본)'으로 사용하고 싶어. 이 엔진 위에 '새로운 DETR 감지 헤드'를 조립해 줘. 이 헤드는 내가 가진 N개의 클래스를 찾을 수 있어야 해."

Hugging Face 라이브러리는 DINOv2 모델에 감지 헤드가 없는 것을 확인하고, 우리가 요청한 num_labels (클래스 수)에 맞춰 새로운 DETR 헤드를 '랜덤한 가중치'로 초기화해서 위에 딱 붙여줍니다.

DINOv2 백본 (ViT): 이미지를 보는 '눈' (가중치 동결 또는 아주 조금만 학습)

새로운 DETR 헤드: 물체를 찾고 분류하는 '뇌' (주로 이 부분을 집중 학습)

🛠️ Hugging Face '조립' 예시 코드 전체 학습 코드는 길지만, 가장 중요한 '모델 조립' 부분의 개념은 이렇습니다.

🏃‍♂️ 다음 단계는? 이제 model이라는 변수에는 DINOv2의 강력한 '눈'과 우리가 새로 붙인 (아직 아무것도 모르는) '뇌'(DETR 헤드)가 결합되어 있습니다.

이 model을 우리가 가진 디텍션 데이터셋(예: COCO 형식의 데이터)으로 파인튜닝(fine-tuning)하면, '뇌' 부분이 DINOv2가 추출한 특징을 보고 물체를 찾는 법을 빠르게 학습합니다.

이 '모델 조립' 개념이 어떻게 작동하는지 감이 오시나요? 아니면 이 model을 실제로 '학습'시키는 다음 단계가 더 궁금하신가요?

'학습'시키는 다음 단계가 더 궁금해

좋아요. '조립'이 끝난 모델을 '학습'시키는 과정(파인튜닝)을 함께 보죠.

Hugging Face transformers 라이브러리를 사용하면 이 과정이 매우 체계화되어 있어요.

크게 3가지 준비물이 필요합니다.

1. 데이터셋 📦: 이미지와 정답 바운딩 박스/라벨 정보 (보통 'COCO' 형식)
2. 학습 설정 📜: TrainingArguments (몇 번 학습할지, 속도는 얼마로 할지 등)
3. 학습 실행기 🏃: Trainer (1번과 2번을 합쳐서 모델을 실제로 돌려주는 도구)

🧐 가장 중요하고 까다로운 단계: 1. 데이터 준비 YOLO 학습 때와 마찬가지로, 모델이 '이해할 수 있는' 형태로 데이터를 넣어줘야 해요.

여기서 아까 만들었던 image_processor가 다시 한번 핵심 역할을 합니다.

1. 이미지 변환: DINOv2 백본이 원하는 크기와 형식으로 이미지를 바꿔줍니다. (이건 일반적이죠)
2. 라벨(정답) 변환: (🌟 이게 핵심) DETR 헤드는 바운딩 박스 정보를 아주 특이한 형식으로 받아요. image_processor는 우리의 [x, y, w, h] 같은 좌표를 DETR가 필요로 하는 labels라는 딕셔너리(dictionary) 형태로 '번역'해 줍니다.

우리는 이 '번역' 작업을 우리 데이터셋의 모든 항목에 적용하는 함수를 만들어야 해요.

🛠️ 학습 과정의 개념적 코드 실제 코드는 길지만, 뼈대는 이렇습니다.

이 전체 흐름에서 가장 낯설게 느껴지는 부분이 아마 '데이터 준비' 과정일 거예요. image_processor가 이미지뿐만 아니라 정답(annotation)까지 함께 받아서 처리한다는 개념이 좀 생소할 수 있거든요.

이 preprocess_function 함수가 정확히 어떤 역할을 하는지 좀 더 자세히 파고들어 볼까요?

preprocess_function 함수가 정확히 어떤 역할을 하는지 좀 더 자세히 파고들어

네, 이 부분이 아마 DINOv2 + DETR 조합에서 가장 중요하고, 또 MMDetection 같은 프레임워크가 왜 그토록 복잡한 설정을 사용했는지 이해하게 되는 지점입니다.

preprocess_function의 역할은 간단히 말해 "우리의 데이터"를 "모델(DETR)이 알아들을 수 있는 언어"로 번역해주는 '전문 통역사' ีย입니다.

analogy 비유: 까다로운 셰프(DETR)와 전문 조수(Processor) 모델 (DINOv2 + DETR): 아주 실력은 좋지만, 엄청나게 까다로운 '미슐랭 셰프' 👨‍🍳라고 상상해 보세요.

우리의 데이터 (이미지, 라벨): 시장에서 막 사 온 '날것 그대로의 재료' 🥕🐟 (예: [100, 50, 200, 150], "강아지")

image_processor: 셰프의 방식을 완벽하게 아는 '전문 조수(sous-chef)' 🧑‍🍳입니다.

이 셰프(모델)는 날것의 재료를 받지 않아요. 정확히 자신만의 방식으로 손질된 재료만 받아서 요리(학습)를 합니다.

preprocess_function은 이 '전문 조수'(image_processor)를 시켜서 모든 재료를 손질하는 '작업 지시서'인 셈이죠.

🛠️ preprocess_function의 두 가지 핵심 임무 이 함수(그리고 그 안의 image_processor)는 크게 두 가지 일을 동시에 처리합니다.

1. 이미지 처리 (이건 익숙한 부분) 크기 조절 (Resizing): DINOv2 백본이 학습된 특정 크기 (예: 800x800)로 이미지 크기를 조절합니다.
   정규화 (Normalization): DINOv2가 학습될 때 사용했던 특정 평균(mean)과 표준편차(std) 값으로 이미지 픽셀 값을 정규화합니다.
   텐서(Tensor) 변환: 이미지를 PyTorch가 처리할 수 있는 숫자 행렬(Tensor)로 바꿉니다.
   (여기까지는 일반적인 이미지 분류 모델과 비슷하죠.)

2. 정답 (Annotation) 변환 (🌟 여기가 핵심 🌟) 이게 바로 DETR 모델이 특별한 이유입니다.
   우리의 정답 형식 (Input): 보통 이렇습니다: {"class_id": 2, "bbox": [100, 50, 150, 200]} (좌표가 [x_min, y_min, x_max, y_max] 형식)
   DETR 셰프의 요구사항 (Output): DETR은 이런 형식을 이해하지 못합니다. DETR은 전혀 다른 형식을 요구해요.
   좌표 형식: [center_x, center_y, width, height] (중심점과 너비/높이)
   좌표 스케일: 0~1 사이로 정규화된 값
   데이터 구조: {"class_labels": [2], "boxes": [[0.35, 0.4, 0.1, 0.2]]} 와 같은 특정 딕셔너리(dictionary) 구조
   image_processor는 이 모든 복잡한 '번역'을 자동으로 해줍니다.

🔗 두 임무가 연결되는 순간 여기서 가장 중요한 점이 나옵니다.

"만약 1.에서 이미지를 1000x1000에서 800x800으로 줄였다면(Resizing), 2.의 정답 bbox 좌표 [100, 50, 150, 200]도 똑같이 스케일에 맞춰 줄여줘야 하잖아요?"

image_processor가 이미지와 정답(annotation)을 함께 받는 이유가 바로 이것입니다.

이미지를 리사이징하면서, 그에 맞춰 바운딩 박스 좌표도 알아서 변환해주고, 심지어 DETR이 요구하는 [center_x, ...] 형식으로 최종 번역까지 해주는 거죠.

이 preprocess_function이 없다면, 우리가 이 모든 좌표 계산과 형식 변환을 직접 코딩해야 했을 거예요.

이 '정답 번역기'로서의 역할, 특히 이미지 크기 조절과 좌표 변환이 동시에 일어난다는 부분이 이해되시나요?

매우 잘 이해돼

이해가 잘 되셨다니 다행이에요!

네, 맞아요. preprocess_function이라는 '전문 조수'가 이미지와 정답 좌표를 한꺼번에 받아서, DINOv2 백본과 DETR 헤드가 원하는 형식으로 완벽하게 '손질'해주는 것이 핵심입니다.

이제 재료 손질(데이터 준비)은 끝났습니다.

🚀 학습 실행: Trainer의 역할 이제 Trainer라는 '총괄 매니저'가 등장할 차례입니다.

Trainer는 우리가 준비한 모든 것을 가져다가 실제 학습 과정을 지휘합니다.

모델 (model): 우리가 조립한 DINOv2 + DETR 모델

설정 (training_args): "총 10번 반복해", "학습 속도는 0.00001로 해" 같은 '학습 계획서'

데이터 (processed_dataset): '손질이 끝난 재료' (우리의 데이터셋)

데이터 콜레이터 (data_collator): '재료를 접시에 담아주는' 역할. 데이터셋에서 여러 개의 '손질된 재료'를 가져와 하나의 '배치(batch)'로 묶어 모델에게 전달합니다.

trainer.train() 명령을 실행하면, Trainer는 이 모든 것을 가지고 다음과 같은 자동화된 '학습 루프'를 시작합니다.

데이터 콜레이터가 '손질된 데이터' 한 배치를 가져옵니다.

이 배치를 model에 넣습니다.

모델이 예측을 쏟아냅니다. (예: "저기 [0.4, 0.5, ...] 좌표에 '강아지'가 있는 것 같아.")

모델은 이 예측을 '정답'과 비교해서 '오류 값(Loss)'을 계산합니다.

이 '오류'를 줄이는 방향으로 DETR 헤드(뇌)의 가중치를 아주 조금 수정합니다.

이 과정을 training_args에서 설정한 횟수(epoch)만큼 반복합니다.

DINOv2 백본(눈)은 이미 너무 똑똑해서 거의 고정해두고, 새로 붙인 DETR 헤드(뇌)가 이 '오류'를 통해 정답 맞추는 법을 집중적으로 배우게 되는 거죠.

이 Trainer가 자동으로 처리해주는 '학습 루프'와 '오류(Loss) 계산' 부분에 대해 좀 더 자세히 알아볼까요?

응

알겠습니다. Trainer가 자동화하는 '학습 루프'와 '오류(Loss) 계산' 부분을 좀 더 자세히 살펴볼게요.

이 과정의 핵심은 DETR 모델이 "어떻게 정답과 예측을 비교하는가"에 있습니다.

🤔 DETR의 독특한 '짝짓기' 문제 YOLO 같은 모델은 이미지의 각 '격자(grid cell)'마다 예측을 합니다. 그래서 정답 상자가 있는 격자의 예측만 정답과 비교하면 됐죠.

하지만 DETR은 다릅니다.

• 모델의 예측: DETR은 이미지와 상관없이 항상 100개(기본값)의 예측을 쏟아냅니다. (예: "1번 물체는 여기", "2번 물체는 저기", ...)
• 우리의 정답: 그런데 실제 이미지에는 '강아지'와 '고양이', 이렇게 단 2개의 물체만 있을 수 있습니다.
• 문제: 모델이 쏟아낸 100개의 예측 중 어떤 것을 실제 정답 2개와 비교해야 할까요? 5번 예측을 강아지랑 비교해야 할까요, 아니면 87번 예측을 비교해야 할까요?

💡 해결책: 헝가리안 매칭 (Hungarian Matching) DETR은 이 문제를 풀기 위해 '헝가리안 알고리즘'이라는 영리한 '소개팅 주선' 방식을 사용합니다.

Trainer가 학습을 시킬 때, 내부적으로 이런 일이 벌어집니다.

1. '소개팅' 주선: 100개의 '예측'과 2개의 '실제 정답'을 한자리에 모읍니다.
2. 최적의 짝 찾기: Trainer는 100개의 예측 중 실제 '강아지' 상자와 가장 비슷하게 예측한 1개를 찾아냅니다. (예: "78번 예측이 가장 비슷하네!")
3. '짝짓기' 완료:
4. 78번 예측 ↔ 실제 '강아지'
5. 22번 예측 ↔ 실제 '고양이'
6. ... 그리고 나머지 98개의 예측 ↔ "배경 (물체 없음)"

📉 '오류(Loss)' 계산 및 학습 이제 '짝'이 정해졌으니, Trainer는 이 짝들을 비교하며 '오류(Loss)'를 계산합니다.

1. 클래스 오류: "78번 예측이 '강아지'라고 잘 맞췄나? '사람'이라고 잘못 말했나?"
2. 박스 오류: "78번 예측의 박스 좌표(bbox)가 실제 강아지 박스 좌표와 얼마나 차이 나나?"

Trainer는 이 두 가지 오류를 합산합니다. 그리고 이 총 오류 값을 최소화하는 방향으로 모델의 가중치(주로 DETR 헤드)를 업데이트합니다.

이 '헝가리안 매칭'을 통해 100개의 예측 중 어떤 것을 정답과 비교할지 동적으로 찾아내는 방식이 DETR의 가장 독창적인 부분이에요.

이 '소개팅 주선(헝가리안 매칭)'을 통해 오류를 계산하는 방식이 좀 감이 오시나요?

응 감이와

좋아요. '소개팅 짝짓기(헝가리안 매칭)'가 끝나면, Trainer는 이제 '오류(Loss)'를 계산해서 모델을 가르칠 수 있습니다.

이 오류는 크게 두 가지로 나뉩니다.

1. 클래스 오류 (Class Loss) 🗂️: "이 물체가 '강아지'인지 '고양이'인지, 아니면 '배경'인지 맞췄니?"
2. '물체' 짝: 78번 예측(짝: 강아지)이 "강아지"라고 정확히 예측했는지 확인합니다.
3. '배경' 짝: 짝을 찾지 못한 나머지 98개 예측들은 "배경 (no object)"이라고 제대로 예측했는지 확인합니다. (이것도 중요해요!)
4. 박스 오류 (Box Loss) 📏: "그 물체의 위치와 크기를 정확히 그렸니?" 이건 '물체' 짝(78번-강아지, 22번-고양이)에 대해서만 계산합니다. ('배경' 짝은 좌표가 필요 없으니까요.)

DETR은 두 가지를 섞어서 씁니다:

1. L1 Loss: 예측 좌표와 정답 좌표 간의 단순 거리 차이.
2. GIoU Loss: 두 박스가 얼마나 잘 '겹쳐지는지(IoU)'를 측정하는 더 똑똑한 방식.

🎓 학습 과정 Trainer는 이 '클래스 오류' + '박스 오류'를 모두 더해서 '총 오류(Total Loss)'를 계산합니다.

그리고 이 '총 오류' 값을 모델에게 보여주며 말하죠. "이 '총 오류' 값이 0에 가까워지도록 너의 가중치(주로 DETR 헤드)를 스스로 수정해!"

이 과정을 '역전파(Backpropagation)'라고 부릅니다. trainer.train()은 이 모든 과정을 우리가 설정한 횟수(epoch)만큼 자동으로 반복해 주는 거예요.

이제 DINOv2 백본을 조립하고, 데이터를 '번역(preprocess)'하고, '헝가리안 매칭'으로 학습시키는 전체 그림이 그려지시나요?

다음으로 이 학습된 모델을 가지고 실제 새로운 이미지에서 물체를 예측(Inference)하는 방법이 궁금하신가요?

응

좋아요. 이제 우리는 똑똑한 DINOv2 '눈' 👁️과 훈련된 DETR '뇌' 🧠를 가진 model을 갖게 되었습니다.

이 모델로 새로운 이미지에서 물체를 찾는 '추론(Inference)' 과정은 학습 때와 비슷하지만, '정답'이 없다는 점만 다릅니다.

🚀 추론(Inference) 과정 이미지 준비:

예측하고 싶은 새로운 이미지(예: my_new_image.jpg)를 불러옵니다.

학습 때와 똑같은 방식으로 이미지를 '손질'해야 합니다.

image_processor에게 이번에는 '정답(annotation)' 없이 이미지만 전달합니다.

image_processor는 이미지를 DINOv2가 좋아하는 크기와 형식으로 '번역'합니다.

모델 예측:

'번역된' 이미지를 model에 넣습니다.

모델은 훈련된 '뇌(DETR 헤드)'를 사용해, 100개의 예측 결과 (좌표 + 클래스 점수)를 쏟아냅니다.

결과 '후처리' (Post-processing) (🌟 여기가 중요 🌟)

모델이 뱉어낸 결과는 [center_x, center_y, w, h] 형식의 0~1 사이 좌표입니다. (사람이 보기 어렵죠)

image_processor에게는 '후처리' 기능도 있습니다!

image_processor.post_process_object_detection(...) 함수에 모델의 예측 결과와 원본 이미지의 크기 (예: 1920x1080)를 알려줍니다.

🪄 image_processor의 마지막 마법 이 '후처리' 함수는 두 가지 마법 같은 일을 해줍니다.

필터링: 100개의 예측 중에서 점수가 낮은 것들, 특히 "배경(no object)"이라고 예측된 것들을 싹 걸러냅니다.

좌표 복원: 0~1 사이의 [center_x, ...] 좌표를, 우리가 알아볼 수 있는 원본 이미지의 픽셀 좌표 [x_min, y_min, x_max, y_max] (예: [120, 300, 450, 600])로 다시 번역해 줍니다.

결과적으로, 우리는 "원본 이미지의 [120, 300, 450, 600] 위치에 98% 확률로 '강아지'가 있다"와 같은 아주 깔끔한 최종 결과만 받게 됩니다.

학습할 때는 image_processor가 정답을 '번역'해주고, 추론할 때는 모델의 출력을 다시 '복원'해주는 이 양방향 역할이 정말 편리하죠.

이 전체 흐름이 어떻게 연결되는지 이제 명확해지셨나요?

너무나 명확해. 최고야. 설명이 끝난거 같은데 위 과정 전체를 코드로 만들어주고 코드의 주석에 니가 설명한 내용과 비유들을 길이상관말고 적어줘.

물론이죠! 우리가 나눈 모든 대화의 흐름, 비유, 그리고 핵심 개념을 전부 담아서 하나의 완성된 코드로 만들어 볼게요.

요청하신 대로, 주석에 우리가 이야기했던 모든 설명을 길이 상관없이 자세하게 담았습니다. 이 코드를 "DINOv2 + DETR 학습의 전체 지도"라고 생각하시면 됩니다.

(참고: 이 코드를 실행하려면 transformers, datasets, torch, timm, scipy 라이브러리가 필요합니다.)

• 각 토큰의 의미를 모델이 이해하는 최종과정에서 추론 확률 분포를 조절하는 파라미터.
• 예시) "It is mine." 이라는 문장에서 It 이라는 토큰에 대해 모델이 아래 확률분포로 예상 후보들을 추론할 수 있음. 이후 최종적으로 It 토큰의 의미를 결정(추론)하는 과정에서 temperature 값을 사용함. temparature값의 변화에 따른 모델의 추론결과는 아래와 같음.
• 값이 높을수록 모델은 주어진 입력을 확장해서 이해하려고 노력함. 따라서 OCR task와 같이 입력(문서)를 그대로 이해해야 하는 상황에서는 매우 낮은 값을 줘야함.
  

repetition_penalty:

• 생성된 각 토큰의 확률분포 중 최대값을 가지는 값을 나눗셈으로 낮춰서 반복을 억제하는 파라미터.
• 가장 큰 확률을 가지는 값(의미)의 확률을 낮춤으로써 확률분포 정규화 시 1순위와 2순위의 확률 격차가 줄어듬. 결국 2순위 값의 영향력이 강해짐에 따라 1위 토큰의 반복 확률이 점점 낮아짐.
• 이 파라미터를 이용하면 OCR수행 시 한셀만 무한 반복해서 출력하는 문제를 해결할 수 있음
  

frequency_penalty:

• 동일한 토큰 등장에 대해 [등장횟수 비례] 패널티 부여.
• 패널티가 높을수록 자율성↑. why? 동일한 토큰 사용에 제약이 걸림에 따라 유사 토큰(≒동의어)를 사용해야하기 때문.

presence_penalty:

• frequency_penalty와 99% 동일함. 차이점은 동일한 토큰 등장에 대해 [상수] 패널티를 부여한다는것.
  

Min-p (Minimum Probability):

• 토큰의 확률분포를 결정하는 값. Threshold의 역할을 수행.
• 각 토큰이 가지는 확률 분포에서 최대 값 × Min-p 값보다 큰 값들만 남김.
• 예시) It 이라는 토큰의 의미 확률분포가 [고양이: 0.6, 강아지: 0.3, 토끼: 0.1] 일 때 Min-p가 0.2라면?

• 0.6 × 0.2 = 0.12 의 값이 threshold가 되고 이 값보다 큰 값들만 채택함. 따라서 It 토큰의 의미확률분포는 = [고양이: 0.6, 강아지: 0.3]가 되고 정규화를 통해 최종 확률분포는 [고양이: 0.75, 강아지: 0.25]와 같이 합이 1.0이 되도록 조정됨.

  
  

[매우중요] 모델 추론 시 각 패널티 및 파라미터들이 적용되는 시점 시각화

VLM을 이용한 OCR 성능을 높이기 위한 필수사항

1. 정확한 레이아웃 구조 파악
2. 문맥 및 논리적 흐름을 고려
3. 할루시네이션의 최소화

위 사항을 잘 수행하기 위한 전략은?

1. 각 테스크(문맥인식, 표 인식, 구조인식 등)에 맞는 여러모델을 중첩해서 사용
2. 모델 재학습
3. 프롬포트 변경

OCR의 성능을 높이기 위해 누구나 프롬포트 변경을 시도한다. 열심히 노력해서 변경해보지만 생각보다 결과가 크게 나아지지 않는다. 결국 포기하거나 또는 공수를 들여 라벨링&학습을 시도한다.

그런데 이 프롬포트 변경... 정말 효과가 없는것일까?

아니다.

프롬포트는 VLM모델의 결과의 정확도를 엄청나게 향상시킬 수 있다.

"그런데 왜 나는 안됐지?"

그건 모델 별로 프롬포트를 이해하는 정도가 꽤나 다르기 때문이고 모델에 적합한 프롬포트를 찾기위해서 꽤나 많은 노력을 기울이지 않았기 때문이다.

GPT에게 물어보면 내가 예상을 뛰어넘는 디테일과 함께 프롬포트를 만들어준다. 최소한 그정도는 돼야한다.

내가 과연 GPT가 작성한 만큼의 정성을 들여 프롬포트를 작성했는가 돌아보고 프롬포트를 변경했을 때 성능이 얼마나 좋아지는지 확인해보자.

도커로 개발하다보면 exec와 attach를 잘 구분해서 사용해야 한다. 간단하지만 모르고 남발하다보면 컨테이너가 날라가기도...

공통점

1. attach와 exec 모두 실행중인 컨테이너에 접속하는 명령어.
2. 따라서 컨테이너 안에서 삭제/붙여넣기/이동과 같은 작업을 수행하면 접속한 모두에게 실시간으로 반영됨.
   

차이점

1. attach는 기존에 실행중인 컨테이너의 프로세스에 접속하는것. ex) 입/출력 프로세스
2. exec는 기존에 실행중인 컨테이너에 새로운 프로세스를 생성하여 접속하는것.

"두 벡터의 내적은 벡터간의 크기와 방향이 얼마나 유사한가를 알려준다."

vector, scalar = 백터, 스칼라 cosine, sine = 코사인, 사인

1. 벡터는..

크기와 방향을 가지고 있다

2. 스칼라는..

단순히 크기만 가지고 있다.

3. 내적은..

• 두 벡터의 서로 대응되는 성분들을 곱한 뒤 모두 더하는 연산을함. 이 연산의 결과값은 스칼라값임. 이 스칼라 값은 두 백터의 크기와 방향이 얼마나 유사한가? 를 나타냄.
• 내적의 연산은 두 벡터 크기와 두 벡터가 이루는 각도 θ의 코사인 값을 곱함. 내적의 수식 : $A⋅B =|A||B|*cosθ$  내적의 최소/최대값 : $-|A||B|≤A⋅B≤|A|*|B|$

  3-1. 수식에서 두 벡터의 크기를 곱하는건 이해가 가는데 왜 코사인θ을 곱할까?

• 먼저 θ는 두 벡터가 이루는 각도의 차(difference)임.
• 두 벡터의 내적은 두 벡터가 이루는 각 θ에 대해 벡터 하나를 다른 벡터에 투영(projection)하는 길이를 의미함.
• 다른 벡터에 투영할 때 고려해야하는것은 바로 방향과 크기임. 다시 말하지만 방향과 크기임.
• 따라서 이 '투영 길이'라는 것은 벡터 간의 방향 차이를 반드시 포함해야함. 그러기 위해선 사인이나 탄젠트가 아닌 코사인을 사용할수밖에 없는데 코사인만이 백터의 방향을 나타낼 수 있기 때문임. (사인은 삼각형의 높이이므로 방향과 상관이 없고 탄젠트는 각도에 대한 비율이므로 아예 기하학적 의미와 상관이 없음)
• 투영길이는 두 백터가 이루는 각도차이인 θ의 코사인 값과 벡터 크기의 곱으로 계산됨. 예를들어 벡터 A를 벡터 B에 투영할 때, 투영된 벡터 길이는$|A|cosθ$ 임. 그래서 내적의 공식을 다시 쉽게 풀어쓰자면 $|A| * cosθ$ 하여 A백터를 B백터로 투영하고 $ |B|$ 하여 두 백터의 방향과 크기를 모두 고려한 유사도 값이 스칼라 형식의 결과로 나오는 것.

4. 번외..

단순히 두 벡터가 얼마나 같은 방향으로 향하고 있는지만 궁금하다면 내적이 아닌 코사인 유사도 공식을 이용해 벡터간의 방향유사도를 구할 수 있다. $Cosine Similarity = cosθ=\frac{∣A∣×∣B∣}{A⋅B}$

activation Function = 활성화함수 sigmoid = 시그모이드 softmax = 소프트맥스

1. 시그모이드의 함수 식&그래프

1-1. 시그모이드는..

• 로지스틱(logistic) 함수의 한 케이스. 로지스틱 함수란 y값을 0과 1사이로 만드는 함수.
• 오직 1개의 인풋에 대해 1개의 아웃풋을 출력함.
• 아웃풋은 0~1사이의 값.
• 따라서 히든레이어의 활성화함수로 주로 사용됨.
  

2. 소프트맥스의 함수 식/그래프

2-1. 소프트맥스는..

• 시그모이드의 확장형. 그래프는 시그모이드와 다를게 없음.
• 차이점은 n개의 인풋에 대해 n개의 결과값을 출력한다는 것.
• n개의 결과값은 0~1사이의 값이면서 동시에 결과값의 합은 항상 1임.
• 따라서 다중클래스 분류 모델의 마지막 활성화함수로 주로 사용됨.
  

다양한 언어의 포스터의 내용을 → 영어로 번역하는 솔루션 아래는 솔루션 전체 플로우차트▼

1. 솔루션을 위한 필수환경

• 쿠다 12.8지원하는 드라이버 ( 525 <= x < 580)
• GPU메모리 12GB 이상
• 70GB의 여유공간 (이미지 : 18GB + 컨테이너 50GB)
  

2. 사용 모델 및 기술

• NanoNets-OCR-s (OCR)
• fastText (언어감지)
• m2m100_418M (번역)
• fastAPI(배포 및 사용)
  

3. 도커컴포즈파일.yaml ▼

name: ${PROJECT_NAME}

services:
  MY_APP:
    image: aptr:v1
    container_name: ${CONTAINER_NAME:-aptr_container}
    ports:
      - "${PORT}:${PORT}"
    command: bash -li -c "RUN_API ${PORT} && exec bash"
    environment:
      - PORT=${PORT}
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

    healthcheck:
      test: ["CMD", "curl", "-f", "http://127.0.0.1:${PORT}/"]
      interval: 30s
      timeout: 300s
      retries: 3
      start_period: 60s
    shm_size: 1gb
    stdin_open: true
    tty: true
    restart: unless-stopped

4. 도커컴포즈env파일.env ▼

PROJECT_NAME='MyProject'        #반드시 따옴표 안에서 작성
CONTAINER_NAME='my_container'   #반드시 따옴표 안에서 작성
PORT=8787

5. 클라이언트 API호출 예제 ▼

import base64
import requests

if __name__ == "__main__":
    with open("./sample_poster_image.jpg", "rb") as image_file:
        encoded_string = base64.b64encode(image_file.read()).decode("utf-8")

    # 서버에 보낼 데이터 구성
    data = {
        "image": encoded_string
    }

    # JSON형태로 POST 요청 (내부에서 utf-8로 인코딩하여 전송)
    url = "http://127.0.0.1:8787/translate“
    response = requests.post(url, json=data)

    print(response.status_code)
    print(response.text)

개발시 고려한 사항

A. 도커이미지 최적화

도커이미지는 nvidia/cuda 도커이미지를 기반으로 만들었음. 도커이미지 제작시 컨테이너의 크기를 최소화 하기 위해 컨테이너 내에서 수십줄의 명령어를 &&으로 이어 단 한번의 명령어로 만들어 크기를 최적화 했음. 최적화 전후 용량차이는 약 3GB 차이. 아래는 실제 사용한 bash명령어. 환경함수 등록까지 모두 bash에서 처리함▼

apt update && \
apt install -y wget git python3.10 pip nano curl && \
pip install  --no-cache-dir torch==2.7.0 torchvision==0.22.0 torchaudio==2.7.0 --index-url https://download.pytorch.org/whl/cu128 && \
pip install transformers==4.52.4 accelerate==1.10.1 packaging==25.0 && \
pip install fasttext==0.9.3 sentencepiece==0.2.1 fastapi==0.116.2 && \
pip install "uvicorn[standard]"==0.35.0 flash-attn==2.8.3 --no-build-isolation pyarmor==7.7.4 && \
cat >> ~/.bashrc << 'EOF' &&
function RUN_API(){
    local port_num="$1"
    #cd /workspace/APTr-v1 || return
    python3 /workspace/APTr-v1/app.py "$port_num"
}
EOF
source ~/.bashrc && \
apt clean && \
apt autoremove -y && \
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* && \
rm -rf ~/.cache/pip/* /tmp/* /var/log/* &&
find /usr -name "*.pyc" -delete && find /usr -name "__pycache__" -type d -exec rm -rf {} + && \
history -c && > ~/.bash_history

B. 코드 및 디렉토리 암호화(난독화)

파이선 기반의 솔루션 중 가장 강력한 암호화 패키지인 pyArmor를 이용. 디렉토리와 모델 암호화는 직접 변수를 수정해가며 수행하였음. 아래는 암호화 된 인퍼런스 코드의 일부▼

C. 여러 OCR모델 빌드 및 테스트

고객의 컴퓨팅 환경이 그리 좋지 못하였기에 12GB이하의 GPU에서도 원활하게 돌아갈 수 있는 성능 좋은 모델을 찾는데 많은 시간을 사용함. 특히 포스터내의 문자/단어 인식을 위해 테스트한 모델은 다음과 같음▼

• paddle OCR
• CRAFT
• DocLayout-YOLO
• Nanonets-OCR-s

처음엔 OCR모델만 찾다 결국 VLM모델로 넘어간거긴하지만 최종적으로 Nanonets 모델이 가장 나은 성능을 보였기에 선택함.

D. 언어인식 모델 빌드 및 테스트

고객이 번역하고자 하는 포스터의 언어가 정해져있지 않았기에 다국어 → 영어로 번역이 가능한 모델을 찾아야했음. fasttext와 m2m100모델이 가장 적합하였기에 선택. 약 100개의 언어를 100개의 언어로 번역 가능.