코딩스뮤

[Claude code] 클로드 코드 사용량 모니터링 claude-monitor

계속지나가기 — Fri, 15 May 2026 13:34:43 +0900

이전 글에서는 cluade를 설치 및 기본적인 사용 방법에 대해 알아봤다:

https://codingsmu.tistory.com/185

[Claude code] 설치 및 사용법 Vscode, Terminal

드디어 회사 정책이 바뀌어서 claude code를 개발 서버에서 사용할 수 있게 되었다.(지금까지 계속 chatgpt에 무지성 코드 복사 붙여넣기 했던거는 안 비밀...) 돈을 지원해주진 않지만 그래도 허용해

codingsmu.tistory.com

본 글에서는 claude code 사용량을 편하게 모니터링 할 수 있는 claude-monitor에 대해 소개하고자한다.

claude 토큰 사용량을 모니터링 하고 싶다면, claude-monitor 강추

claude 공식 web에서도 사용량을 트래킹할 수 있지만 꽤나 번거롭다. claude-monitor를 이용한다면, 터미널에서 실시간 사용량을 확인할 수 있다. (gpu/cpu 사용량 모니터링 도구인 htop과 비슷한 느낌이다)

먼저 claude-monitor를 사용하기 위해서는 패키지 설치부터 해야한다. pip로 설치 후 claude-monitor를 입력하면, 실시간 claude code토큰 사용량, 비용 등을 모니터링 할 수 있다.

pip install claude-monitor
claude-monitor

만약 Pro플랜이고, 시간을 한국 타임으로 보고 싶다면 아래 커맨드를 입력하면 된다

claude-monitor --plan pro --timezone Asia/Seoul

claude-monitor 화면 UI

각 상태창이 의미하는 바는 아래와 같다:

항목	설명
Cost Usage	비용 사용량으로 현재까지 사용한 금액과 설정된 예산 한도에 해당 (Time Reset후 초기화 됨) (이미지상에서는 총 $18.00 중 $0.14(0.8%)를 사용했음을 보여줌)
Token Usage	토큰 사용량으로 현재 기간 내에 사용된 토큰 수에 해당 (Time Reset후 초기화 됨) 100%가 넘어도 동작은 하나, 속도가 굉장히 느려짐 (300~400% 까지 사용하면 time reset 전까지 사용 제한이 걸림) (19,000 토큰 중 2,818개(14.8%)를 소비한 상태임)
Messages Usage	메시지 횟수로 Claude와 주고받은 메시지 수에 해당
⏱️ Time to Reset	초기화까지 남은 시간으로 사용량 제한(위의 지표)이 리셋되기까지 남은 시간임. (Pro-Plan의 경우 4h 1m~5h 리밋임)
Model Distribution	모델 분포로 사용 중인 Claude 모델의 종류와 비중을 나타냄 (/model을 입력하면 호출 모델을 변경할 수 있다. 기본은 Sonnet)
Burn Rate	소모 속도로 분당 토큰 소모량(tokens/min)입니다. 현재 분당 47.0개의 토큰을 쓰고 있으며, 옆의 달팽이( ) 아이콘은 소모 속도가 매우 낮음을 의미
Cost Rate	비용 발생 속도로 분당 발생하는 비용($/min)임. 현재 분당 약 $0.0027의 비용이 발생
Predictions	예측값으로 현재의 소모 속도를 유지할 경우, Tokens will run out(토큰 소진 시간)은 오전 5시 6분으로 예상되며, Limit resets at(한도 리셋 시간)은 오후 6시 정각임을 알려줍니다.

이 외에 추가 옵션과 자세한 내용이 궁금하다면 다음 github를 참고:

https://github.com/Maciek-roboblog/Claude-Code-Usage-Monitor

GitHub - Maciek-roboblog/Claude-Code-Usage-Monitor: Real-time Claude Code usage monitor with predictions and warnings

Real-time Claude Code usage monitor with predictions and warnings - Maciek-roboblog/Claude-Code-Usage-Monitor

github.com

[머신러닝 시스템 설계] 3 유튜브 동영상 검색

계속지나가기 — Sat, 25 Apr 2026 15:17:00 +0900

본 게시글은 알렉스 쉬, 알리 아미니안(최종일 옮김)의 "가상면접 사례로 배우는 머신러닝 시스템 설계 기초"를 읽고 정리한 내용에, 개인적인 이해를 추가한 글입니다.

Overview

머신러닝 시스템 설계 문제에서는 단순히 모델을 만드는 것이 아니라, end-to-end 관점에서 문제를 어떻게 정의하고 풀어가는지가 중요합니다.

이번 글에서는 그 중 하나인 유튜브 동영상 검색 시스템을 예시로,
텍스트 쿼리를 기반으로 관련 동영상을 찾는 ML 시스템 설계 관점에서 정리해보겠습니다.

1️⃣ 요구사항 명확화

문제: 사용자 검색어에 따라, 관련 있는 유튜브 영상을 추천하시오.

쇼미더머니 + 랩신두 키워드로 검색하면 -> 쇼미 12에 출연한 라프산두의 하이라이트가 나온다

사용자의 텍스트 쿼리를 입력으로 받아, 관련있는 유튜브 동영상을 반환하는 검색 시스템을 만들어야 합니다.

즉, 아래와 같은 시스템을 설계하는 것이 목표입니다.

입력: 텍스트 쿼리
출력: 관련 동영상 리스트(ranking된 결과)

고려해야 할 포인트들

아래의 목표를 고려하여 사용자과 관심있어 할 유용한 동영상 검색 시스템을 설계하는 것이 최종 목표입니다.

비즈니스 목표	관련있는 동영상을 제공하여 조회수를 높이는 것
시스템 기능	텍스트 쿼리 기반으로 관련 동영상을 검색하는 것
데이터	모델 학습을 위한 천만 개의 <동영상, 텍스트 쿼리> 쌍으로 구성된 데이터 셋이 있음.
제약 조건	영어만 지원, 개인화 없음
시스템 규모	대규모 사용자
성능 요구사항	정확도 vs latency trade-off 고려

2️⃣ ML 문제로 구조화

비즈니스 문제를 ML 문제로 재정의해봅시다.

ML 목표로 재정의: 텍스트 쿼리와 동영상 간의 관련도를 기반으로 ranking 하는 문제

시스템 입출력 정의:

이 경우, I/O는 다음 처럼 생각할 수 있습니다:

Input: 텍스트 쿼리 → Output: 관련도 순으로 정렬된 동영상 리스트

이 시스템은 단순 classification이 아니라, 관련도가 높은 동영상을 출력하는 Ranking 문제 (Information Retrieval) 입니다.

적합한 ML 접근 방식 선택:

동영상과 텍스트 쿼리간의 관련성을 결정하기 위해서는 시각적 콘텐츠와, 동영상 텍스트 데이터를 모두 활용해야 합니다. 즉, 텍스트/시각 검색이 모두 이루어져야 합니다.

개략적인 검색 시스템의 개요

1. 시각 검색 (Visual Search)

먼저, 텍스트 쿼리와 동영상의 시각적 콘텐츠 간 유사성에 따라 동영상의 순위를 매기는 시각 검색이 필요합니다.

일반적으로 표현 학습(Represantation Learning)을 사용하여 시각적 콘텐츠를 처리하며, 이를 동영상 검색하는데 사용합니다.

이 때, 텍스트와 동영상은 각각의 개별 인코더를 사용해 인코딩을 해야 하며, 둘 간의 유사도 점수는 개별 인코더를 통과해서 나온 값인 동영상, 텍스트 임베딩 값의 dot product를 사용하여 계산합니다. 이 값은 유사도 값이 되며, 이를 기준으로 동영상의 순위를 매깁니다.

2. 텍스트 검색 (Text-based Search)

다음으로, 텍스트 쿼리가 들어오면 텍스트 검색어와 가장 유사한 제목/설명/태그 등을 가진 동영상을 검색할 수 있도록 합니다. 이 때는 따로 모델을 사용하지 않고 아래와 같이 구축된 DB 테이블에서 검색하는 방식을 사용할 수 있습니다.

동영상 ID	TITLE	TAG
1	우리 집 강아지 실내에서 놀기	개, 실내, 놀이
2	중학교 수영 대회	수영장, 어린이
3	일본에 있을 때 촬영한 영상 보기	여행, 일본, 브이로그
4	스포츠카 속도 비교	자동차, 경주, 속도
5	내 원격 작업 설정	컴퓨터, 마우스, 대화
6	어젯밤 우리 집에서 개들이 파티를 즐긴 방법	고양이, 개, 가족

텍스트 기반 검색 구성요소를 생성하는 대표적인 기법으로 Elastic Search에 Inverted Index가 있습니다.

일반적으로 아는 인덱스(Forwad Index)는 "doc ID-내용"을 매핑하여, 특정 'term'이 있는 문서를 찾고 싶다면, 문서 전체를 linear search(O(n)) 하며 특정 'term'이 있는지 찾아야 합니다.

반대로 역 인덱스(Inverted Index)는 "특정 단어-[doc ID List]"를 매핑하여, 특정 'term'이 있는 문서를 찾고 싶다면 term을 키값으로, 문서 ID를 바로 찾을 수 있기 때문에 (O(1)) 훨씬 빠른 속도로 원하는 결과값을 찾을 수 있습니다.

추가적인 내용은 다음 자료를 참고하시면 좋습니다: https://esbook.kimjmin.net/06-text-analysis/6.1-indexing-data

3️⃣ 데이터 준비

ML 모델 성능을 결정짓는 가장 중요한 단계 중 하나입니다.

데이터 준비 프로세스

데이터 준비 단계는 크게 (1) 데이터 엔지니어링, (2) 피처 엔지니어링으로 나눌 수 있습니다.

(1) 데이터 엔지니어링

데이터를 수집하고, 저장하고, 검색하고, 처리하는 전체 파이프라인을 설계하는 단계입니다.

이 문제에서는 이미 다음과 같은 데이터가 존재한다고 가정하기 때문에, 수집 및 정제 과정은 별도로 다루지 않겠습니다.

동영상 데이터 (raw video)
텍스트 쿼리
동영상 메타데이터 (제목, 설명, 태그)
<동영상, 텍스트 쿼리> 매칭 데이터 (학습용)

(2) 피처 엔지니어링

모델 학습을 위해서는 text, video 같은 비정형 데이터를 수치 벡터 형태로 변환하는 과정이 필수적입니다.

1. Text 데이터 처리

텍스트 데이터 전처리를 위한 workflow는 다음과 같습니다. raw text에 해당하는 값은 소문자 변환, 불필요한 공백 제거, 어간 추출 등의 정규화 과정은 거치고, 토큰화를 진행한 후, lookup table, hashing trick 방법등을 통해 ID로 변환하는 과정을 거쳐 숫자 벡터 값을 얻을 수 있습니다.

text → [정규화 → 토큰화 → ID 변환] → 숫자 벡터
ex: text = "A person is walking in Montreal"
- 정규화: "a person walk in montreal"
- 토큰화: ["a", "person", "walk", "in", "montreal"]
- ID 변환: [33, 28, 4, 16, 99]

2. Video 데이터 처리

동영상 전처리를 위한 workflow는 다음과 같습니다.

video → [프레임 디코딩 → 샘플 프레임 → 크기 조정 → 스케일리, 정규화와 색상 모드 보정 ] → 프레임 단위의 .npy

동영상 전처리 워크플로우

4️⃣ 모델 개발

text, video 데이터를 모두 처리해야 되기 때문에, 개별 인코더를 사용해 각각을 임베딩(embedding)으로 변환하는 과정이 필요합니다. 즉, 텍스트와 동영상을 동일한 벡터 공간으로 매핑한 뒤, 두 벡터 간의 유사도를 계산하여 검색을 수행하는 구조를 사용합니다.

(1) 텍스트 인코더

텍스트 인코더는 입력된 쿼리를 벡터 형태로 변환하는 역할을 하며, 크게 통계적 방법과 머신러닝 기반 방법으로 나눌 수 있습니다.

통계적 방법

BoW(Bag of Words)는 문장 내 각 단어의 등장 빈도를 기반으로 벡터를 생성하는 방식으로, 구현이 간단하고 직관적이라는 장점이 있습니다. 하지만 단어의 순서를 고려하지 않기 때문에 문맥을 이해하지 못하고, 벡터가 희소(sparse)해지는 문제가 있습니다. 예를 들어, “watch TV after work”와 “work after watch TV”는 의미가 다르지만 동일한 BoW 표현을 갖게 됩니다. 자세한 내용은 다음 게시글에서 확인할 수 있습니다: https://codingsmu.tistory.com/98

[NLP] 단어 표현 방법 : Bag-of-Word Model(Bow)

Bag-of-Word(BoW) Model 기계학습 알고리즘(MLA)을 자연어 처리 테스크에 사용할 때, 입력값인 텍스트는 그 자체로는 사용할 수 없다. 이산적인(discrete)한 텍스트 즉, 문자열을 연속적인(continuous) 모델이

codingsmu.tistory.com

TF-IDF는 이러한 BoW의 단점을 일부 보완하기 위해 등장한 방법으로, 단어의 빈도뿐만 아니라 해당 단어가 전체 문서에서 얼마나 중요한지를 반영합니다. 자주 등장하지만 의미가 약한 단어(예: the, a 등 관사)의 가중치는 낮추고, 특정 문서에서만 자주 등장하는 단어의 가중치는 높이는 방식입니다. 하지만 이 역시 단어의 순서를 고려하지 못하기 때문에 문맥을 이해하는 데 한계가 있습니다.

머신러닝 기반 방법

이러한 한계를 극복하기 위해 실제 서비스에서는 머신러닝 기반 방법이 주로 사용됩니다. 주로 모델을 사용하여 문장을 단어 임베딩으로 변환하고, 두 임베딩 사이의 거리로 유사도를 계산하는 방법을 사용합니다.

Word2Vec은 단어 주변의 문맥 정보를 활용하여 의미적으로 유사한 단어들을 가까운 벡터 공간에 위치시킵니다. Word2Vec은 주변 단어로 중심 단어를 예측하는 CBOW 방식과, 중심 단어로 주변 단어를 예측하는 Skip-gram 방식으로 학습됩니다. 자세한 내용은 다음 게시글에서 확인할 수 있습니다: https://codingsmu.tistory.com/100

[NLP] 워드투벡터(Word2Vec)

Word2Vec Model Word2Vec는 단어 간 유사도를 반영할 수 있도록 단어의 의미를 벡터화할 수 있는 방법이다. Word2Vec의 주요 아이디어는 "비슷한 분포를 가진 단어라면 비슷한 의미를 가질 것"이다 즉, 자

codingsmu.tistory.com

Transformer 기반의 모델을 활용하는 것이 최근 가장 널리 사용되는 방법입니다. 이 방식은 문장 전체의 문맥을 고려하여 단어 임베딩을 생성할 수 있기 때문에, 기존 방법들보다 훨씬 풍부한 의미 정보를 담을 수 있습니다. 특히 검색 시스템에서는 쿼리의 의미를 정확히 이해하는 것이 중요하기 때문에, 이러한 문맥 기반 임베딩 방식이 필수적으로 사용됩니다.

(2) 동영상 인코더

동영상 인코더는 영상 데이터를 벡터로 변환하는 역할을 합니다. 텍스트와 달리 동영상은 시간 축을 포함한 고차원 데이터이기 때문에 처리 방식이 더 복잡합니다. 동영상 인코딩 방식은 크게 동영상 전체를 처리하는 방법과 프레임 단위로 처리하는 방법으로 나눌 수 있습니다.

동영상 수준 모델: 동영상 전체를 입력으로 사용하는 방식은 시간적 흐름까지 반영할 수 있다는 장점이 있지만, 계산 비용이 매우 크다는 단점이 있습니다.
프레임 수준 모델: 반면, 프레임 단위 방식은 동영상을 여러 프레임으로 나눈 뒤 각 프레임을 독립적으로 처리하는 방식입니다. 일반적으로 일정 간격으로 프레임을 샘플링한 뒤, 각 프레임을 CNN이나 ViT(Vision Transformer) 모델에 입력하여 임베딩을 생성합니다. 이후 이 프레임 임베딩들을 평균(mean pooling)이나 최대값(max pooling) 등의 방식으로 집계하여 하나의 동영상 임베딩으로 변환합니다.

이 두 가지 방식 모두 계산 효율성이 높고 구현이 비교적 간단하지만, 시간적 정보(동작의 흐름)를 충분히 반영하지 못한다는 한계가 있습니다. 따라서 액션 인식과 같이 시간 정보가 중요한 경우에는 3D CNN이나 Transformer 기반의 시계열 모델을 추가로 사용하는 방법도 고려할 수 있습니다.

(3) 모델 학습

텍스트 인코더와 동영상 인코더를 학습하기 위해서는 두 임베딩 공간을 잘 정렬시키는 것이 중요합니다. 이를 위해 일반적으로 Contrastive Learning 방식이 사용됩니다.

{text, video} 데이터 셋의 모델 학습 방법

핵심 아이디어는 간단합니다. 정답 쌍은(positive pair)은 임베딩 공간에서 가깝게 만들고, 관련 없는 쌍(negative pair) 은 멀어지도록 학습하는 것입니다. 이러한 방식으로 학습하면, 모델은 자연스럽게 텍스트와 동영상 간의 의미적 관계를 학습하게 됩니다.

5️⃣ 평가

모델 성능 평가는 크게 (1) 오프라인 평가, (2) 온라인 평가로 나눌 수 있습니다.

(1) 오프라인 평가

오프라인 평가는 수집된 데이터셋을 기반으로, 모델의 성능을 사전에 측정하는 단계입니다.

특히 이 문제는 단순히 맞고 틀림을 판단하는 classification이 아니라, 결과의 “순서”가 중요한 ranking 문제이기 때문에 이에 맞는 지표를 사용하는 것이 중요합니다. 대표적인 평가 지표는 다음과 같습니다.

Precision: 모델이 예측한 결과 중 실제로 관련 있는 비율
Recall: 실제 관련 있는 동영상 중 모델이 맞춘 비율

Precision과 Recall은 기본적인 지표이지만, 검색 시스템에서는 순서를 반영하지 못한다는 한계가 있습니다. 따라서 ranking 문제에서는 추가적인 지표가 필요합니다.

MRR (Mean Reciprocal Rank):
첫 번째 정답이 얼마나 상위에 위치하는지를 평가하는 지표입니다.
예를 들어, 정답이 1번째에 있으면 1, 3번째에 있으면 1/3의 값을 가지게 됩니다.
즉, 사용자가 원하는 결과가 얼마나 빠르게 등장하는지를 측정합니다.
mAP (Mean Average Precision):
여러 개의 정답이 존재할 때, 전체 ranking 품질을 종합적으로 평가하는 지표입니다.
다양한 threshold에서 precision을 계산하고 평균을 내어, 모델의 전반적인 성능을 확인할 수 있습니다.

(2) 온라인 평가

오프라인 지표가 높다고 해서 실제 서비스에서도 좋은 성능을 보장하는 것은 아닙니다. 따라서 실제 사용자 환경에서의 성능을 측정하는 온라인 평가가 반드시 필요합니다. 온라인 평가는 주로 A/B 테스트를 통해 이루어지며, 실제 사용자 행동 데이터를 기반으로 시스템의 효과를 판단합니다. 대표적인 지표는 다음과 같습니다.

CTR (Click Through Rate):
검색 결과로 노출된 동영상 중 실제로 클릭된 비율 → 사용자가 결과를 얼마나 매력적으로 느끼는지 판단 가능
Watch Time (시청 시간):
사용자가 동영상을 얼마나 오래 시청했는지 → 단순 클릭이 아닌 실제 만족도를 반영
Completion Rate (시청 완료율):
사용자가 영상을 끝까지 시청했는지 여부 → 콘텐츠의 품질 및 추천의 적합성을 평가

[머신러닝 시스템 설계] 2 구글 스트리트 뷰 블러링 시스템

계속지나가기 — Sun, 19 Apr 2026 20:49:45 +0900

본 게시글은 알렉스 쉬, 알리 아미니안(최종일 옮김)의 "가상면접 사례로 배우는 머신러닝 시스템 설계 기초"를 읽고 정리한 내용에, 개인적인 이해를 추가한 글입니다.

Overview

머신러닝 시스템 설계 문제에서는 단순히 모델을 만드는 것이 아니라, end-to-end 관점에서 문제를 어떻게 정의하고 풀어가는지가 중요합니다.

이 글에서는 그 중 하나인 구글 스트리트 뷰 블러링 시스템을 예시로, 개인정보 보호를 위한 ML 시스템 설계 과정을 단계별로 정리해보겠습니다.

1️⃣ 요구사항 명확화

문제: 구글 스트리브 뷰에서 개인정보 보호를 위한 블러링 시스템을 설계하시오.

구글 스트리트 뷰 예시 (TMI: 생각보다 한국 구글맵은 blur 처리가 잘 안되고 있다..)

스트리트 뷰에서는 거리 이미지가 그대로 노출되기 때문에, 사람 얼굴이나 차량 번호판과 같은 개인 정보는 반드시 가려야 합니다.

즉, 아래와 같은 시스템을 설계하는 것이 목표입니다.

입력: 스트리트 뷰 이미지
출력: 얼굴 / 번호판이 블러 처리된 이미지

고려해야 할 포인트들

즉, 아래의 목표를 고려하여 사용자의 개인정보를 보호할 수 있는 블러링 시스템을 설계하는 것이 최종 목표입니다.

비즈니스 목표	사용자의 개인정보 보호 (privacy preservation)
시스템 기능	- 이미지 내 객체(얼굴, 번호판) 탐지 - 해당 영역에 대해 자동 블러링 처리
데이터	- 약 100만 개의 라벨링 데이터 (얼굴, 번호판 bounding box 포함) - 데이터 편향(인종, 성별 등) 은 고려하지 않는다고 가정
제약 조건	- 실시간 처리 필요 없음 (오프라인 처리 가능) - 정확도가 latency보다 중요
시스템 규모	글로벌 사용자 대상 (대규모 이미지 처리 필요)
성능 요구사항	- 민감 정보는 놓치지 않는 높은 recall - 과도한 블러링 방지를 위한 precision도 중요

2️⃣ ML 문제로 구조화

비즈니스 문제를 ML 문제로 재정의해봅시다.

ML 목표로 재정의: 이미지에서 관심있는 객체를 정확하게 감지하는 것

시스템 입출력 정의:

이 경우, I/O는 다음 처럼 생각할 수 있습니다: Input: 이미지, Output: 객체 감지 결과 (bounding box + object class)

이 시스템은 단순 classification이 아니라, "어디에 무엇이 있는지"를 찾는 객체 감지(Object Detection) 문제입니다.

적합한 ML 접근 방식 선택:

객체 감지 문제는 일반적으로 두 가지 단계로 구성됩니다.

Step 1: 객체 위치 예측 (Bounding Box) → 회귀 문제
Step 2: 객체 종류 분류 → 분류 문제

모델 구조 선택:

객체 감지 모델은 크게 1단계/2단계 네트워크 두 가지로 나뉩니다.

2단계 네트워크: 두 개의 개별 모델을 사용하는 네트워크로, 속도는 더 느리지만 bounding box 감지 후, 객체 클래스를 할당하므로 정확도가 더 높습니다.

크게 (1단계) Region Proposal Network (RPN)로, 후보 영역을 생성하는 단계와 (2단계) 제안된 각 영역을 처리하여 객체 클래스로 분류하는 classification 단계로 구분됩니다.

일반적으로 사용하는 2단계 network로는 R-CNN, Fast R-CNN, Faster-RCNN이 있습니다.

1단계 네트워크: 위의 두 단계를 개별 모델이 아닌, 한 모델로 통합한 버전으로 좀 더 최근 방식입니다.

영역 제안을 명시적으로 감지하지 않아도, 바운딩 박그와 객체 클래스를 동시에 생성할 수 있습니다.

일반적으로 사용되는 1단계 network로는 YOLO, SSD등이 있습니다.

이 문제에서는

실시간성이 중요하지 않고
개인정보 보호가 핵심이므로

이 문제에서는 실시간성이 중요하지 않고, 개인정보 보호가 핵심이므로 느리지만 더 정확한 2-stage 방식 (Faster R-CNN 등)을 선택하는 것이 합리적입니다.

3️⃣ 데이터 준비

ML 모델 성능을 결정짓는 가장 중요한 단계 중 하나입니다.

데이터 준비 프로세스

데이터 준비 단계는 크게 (1) 데이터 엔지니어링, (2) 피처 엔지니어링으로 나눌 수 있습니다.

(1) 데이터 엔지니어링

데이터를 수집하고, 저장하고, 검색하고, 처리하는 전체 파이프라인을 설계하는 단계입니다.

이 시스템에서 사용할 수 있는 데이터 소스는 다음과 같습니다.

- 스트리트 뷰 이미지
- bounding box 라벨 (얼굴, 번호판)
- 메타데이터 (위치, 시간 등)

(2) 피처 엔지니어링

이 시스템에서는 입력이 이미지이기 때문에, 이미지 전처리가 필수적으로 수행되어야 합니다.

대표적인 전처리 과정은 다음과 같습니다.

- resizing
- scaling
- z-score normalization
- 이미지 색상 모드 통일 (RGB 등)

이미지 전처리 관련해서 좀 더 상세한 내용이 궁금하다면 아래 글을 참고하면 좋습니다 :)

- [패턴인식] 영상 처리(1) : 디지털 영상, 히스토그램: https://codingsmu.tistory.com/102
- [패턴인식] 영상 처리(2) : 이진영상, 영상 처리의 세가지 기본 연산: https://codingsmu.tistory.com/103

[패턴인식] 영상 처리(2) : 이진영상, 영상 처리의 세가지 기본 연산

Digital Image Processing목차0. Preview1. 디지털 영상이란?2. 히스토그램3. 이진 영상4. 영상 처리의 세가지 기본 연산5. 다해상도6. 모폴로지7. 컬러 은 이전 게시글을 참고해주세요https://codingsmu.tistory.co

codingsmu.tistory.com

추가로, 수집한 데이터 수에 따라 다음의 (opt.) 데이터 증강 기법을 사용할 수도 있습니다.

random crop
brightness / saturation 변화
noise 추가

단, 회전 혹은 뒤집는 경우 바운딩 박스의 ground truth 값도 함께 변환되어야 합니다.

4️⃣ 모델 개발

모델 개발 단계에서는 (1) 모델 선택, (2) 학습 방식 (w/ loss function)을 결정합니다.

(1) 모델 선택

2단계 네트워크를 선택해야 됩니다.

2단계 객체 감지 네트워크

convolutional layers

input image를 처리하고 feature map을 출력

Region proposal network (RPN)

객체를 포함할 수 있는 후보 영역을 제안
NN을 아키텍처로 사용하고, feature map을 입력으로 받아 이미지의 후보 영역을 출력

classifier

각 후보 영역의 객체 클래스를 결정함.
input으로 feature map과 제안된 후보 영역을 입력으로 받아 각 영역에 객체 클래스를 할당함.
일반적으로 NN 기반

(2) 모델 학습

훈련시 일반적으로 다음 세 단계를 포함합니다: forward propagation, backward propagation, loss function

첫 번째 네트워크인, 객체 감지 모델의 loss function은 예측된 객체의 bounding box가 ground truth와 얼마나 일치하는지로 계산합니다. 이 때, regression loss로 MSE와 같은 표준 회귀 손실 함수를 사용하게 됩니다. L_reg

두 번째 네트워크인, 객체 분류 모델의 loss function은 앞 단계에서 감지된 bounding box에 객체 클래스를 예측해야 합니다. 이 때, classification loss로 cross entropy와 같은 표준 분류 손실 함수를 사용하게 됩니다. L_cls

최종 Loss Function

모델의 전반적인 성능을 측정하기 위해, 최종 loss function으로는 균형 매게변수 lambda로 가중치를 부여한 분류 손실과 회귀 손실의 결합값을 사용합니다.

5️⃣ 평가

모델 성능 평가는 크게 (1) 오프라인 평가, (2) 온라인 평가로 나눌 수 있습니다.

두 평가 메트릭을 살펴보기 전에, 객체 감지 평가 관련한 핵심 개념인 IoU에 대해 먼저 알아보고자 합니다.

Intersection over Union (IoU)는 예측 박스와 GT 박스의 겹침 정도를 나타내는 값으로 1에 가까울 수록 예측값이 GT와 완전히 일치함을 말합니다. 1은 드물게 나타나는 값으로 보통은, threshold 값을 정해, 해당값을 기준으로 넘는 값에 대해서는 정답, 이하 값은 오탐으로 분류하게 됩니다.

IOU 공식

(1) 오프라인 평가
객체 감지에서는 단순 accuracy보다 다음 지표를 사용합니다.

Precision / Recall

Precision: 예측 중 정답 비율
Recall: 실제 정답 중 맞춘 비율

이 문제에서는 개인정보가 유출되는 것이 더 문제가된는 상황이므로, 특히 Recall이 중요합니다.

ML의 기본 평가 매트릭 관련해서는 아래 글을 참고하면 좋습니다 :)

- [ML] 모델 성능을 측정하는 네가지 지표: https://codingsmu.tistory.com/88

[ML] 모델 성능을 측정하는 네가지 지표

기계학습(ML : Mahine Learning) 모델의 성능을 측정하는 통계적 지표로는 다음과 같이 네 가지 종류가 존재한다 인식 성능 측정 Accuracy: 정확도 혼동 행렬(Confusion Matrix)을 이용한 방식 (또는 오차행렬

codingsmu.tistory.com

Average Precision (AP)

다양한 IoU threshold에서 precision 평균입니다. P(r)은 임계값 'r'에서의 정밀도를 나타냅니다.

Mean Average Precision (mAP)

모든 클래스(AP)의 평균이며 모델의 전반적인 성능을 보여줄 수 있습니다. C는 모델이 감지하는 객체 클래스의 총 수 입니다.

(2) 온라인 평가

실제 서비스에서는 다음을 확인해야 합니다. “이 시스템이 정말 개인정보를 잘 보호하고 있는가?”

대표적인 지표:

사용자 신고 수
개인정보 노출 관련 이슈 발생 빈도
블러링 오류 (미탐 / 과탐)

[머신러닝 시스템 설계] 1 시각 검색 시스템

계속지나가기 — Fri, 10 Apr 2026 22:13:20 +0900

본 게시글은 알렉스 쉬, 알리 아미니안(최종일 옮김)의 "가상면접 사례로 배우는 머신러닝 시스템 설계 기초"를 읽고 정리한 내용에, 개인적인 이해를 추가한 글입니다.

Overview

머신러닝 시스템 설계 문제에서는 단순히 모델을 만드는 것이 아니라, end-to-end 관점에서 문제를 어떻게 정의하고 풀어가는지가 중요합니다.

이 글에서는 그 중 하나인 시각 검색 시스템 (visual search) 을 기준으로, 전체 설계 과정을 정리해보았습니다.

1️⃣ 요구사항 명확화

문제: 핀터레스트와 유사한 시각적 검색 시스템을 설계하시오

왼쪽 상단 이미지: 쿼리 이미지, 오른쪽은 유사한 이미지 결과들

주어진 기본 과정은 다음과 같다고 고려합니다.

입력: 이미지
출력: 유사 이미지 리스트 (ranking 포함)
개인화: 고려하지 않음
텍스트/동영상 쿼리: 제외

고려해야 할 포인트들

즉, 아래의 목표를 고려하여 빠르고 정확하게 유사한 이미지를 찾아주는 시스템을 만드는것이 최종 목표입니다.

비즈니스 목표	검색 시스템이 얼마나 잘 동작하는지 판단 (CTR, 사용자 수, 체류 시간 등)
시스템 기능	사용자 선호도 수집 (좋아요/싫어요 등) → 학습 데이터 라벨로 활용
데이터	이미지 기반 (동영상/텍스트 제외), 기본적으로 픽셀 정보 사용 (확장 시 메타데이터 고려)
제약 조건	컴퓨팅 자원, 클라우드 vs 온디바이스, 모델 자동 개선 여부
시스템 규모	사용자 수 및 트래픽 규모
성능 요구사항	목표 정확도 및 검색 속도 (대규모 이미지 DB: 100B~200B)

2️⃣ ML 문제로 구조화

비즈니스 문제를 ML 문제로 재정의해봅시다.

ML 목표로 재정의: 쿼리 이미지와 시각적으로 유사한 이미지를 정확하게 찾는다

이 경우, I/O는 다음 처럼 생각할 수 있습니다: Input: 이미지 (pixel) , Output: 유사 이미지 리스트 (ranking)

입력된 쿼리 이미지와 유사한 이미지를 검색하여, 이를 보여주는 것이 목표이므로,

단순 분류 문제가 아니라, ranking 문제로 보는 것이 자연스럽습니다.

여러 ML이 답이 될 수 있으나, 여기서는 표현 학습(representation learning) 접근방식으로 문제를 풀려고 합니다.

표현학습이란, 이미지와 같은 입력 데이터를 임베딩이라는 표현으로 변환하도록 모델을 훈련하는 것으로, 유사한 이미지끼리는 서로 근접한 임베딩을 갖도록 학습하는 것이 핵심입니다.

표현 학습을 사용해 이미지 순위를 매기는 방법으로는, (1),(2)가 존재합니다.

(1) 임베딩 공간의 거리를 측정해 쿼리 이미지와, 다른 이미간의 유사도 점수를 계산해 이미지 순위를 매김.

(2) 유사성 정의, 모델 훈련 방법, 유사한 이미지를 가깝게 하는 방법 등

처음 이 문제를 봤을 때, 개인적으로 떠올랐던 방법은 크게 두 가지 입니다: (1) from scratch, (2)기존 임베딩 모델을 활용

(1) 처음부터 학습하고 싶다면, contrastive learning을 떠올릴 수 있습니다.

- simCLR, MoCo 등 다양한 self-supervised 방식

- 그 중, simCLR 관련해서는 이전에 정리한 게시글이 있습니다.

https://codingsmu.tistory.com/163

simCLR을 통해 Contrastive Learning 이해하기

해당 게시글은 Ekin Tiu님의 Understanding Contrastive Learning글을 참고하여 번역 및 요약한 글입니다. What is Contrastive Learning? Contrastive learning is a machine learning technique used to learn the general features of a dataset w

codingsmu.tistory.com

(2) 기존에 잘 학습된 임베딩 모델을 활용할 수도 있습니다. hugginface에서 다운로드 수가 높은 임베딩 모델을 참고하세요

3️⃣ 데이터 준비

ML 모델 성능을 결정짓는 가장 중요한 단계 중 하나입니다.

데이터 준비 프로세스

데이터 준비 단계는 크게 (1) 데이터 엔지니어링, (2) 피처 엔지니어링으로 나눌 수 있습니다.

(1) 데이터 엔지니어링

데이터를 수집하고, 저장하고, 검색하고, 처리하는 전체 파이프라인을 설계하는 단계입니다.

이 시스템에서 사용할 수 있는 데이터 소스는 다음과 같습니다.

- 이미지 데이터
- 사용자 데이터
- 사용자 ↔ 이미지 상호작용 데이터

각 데이터를 조금 더 구체적으로 보면:

- 이미지: 픽셀 정보 외에도, 소유자, 업로드 시간, 태그 등의 메타데이터를 포함할 수 있음
- 사용자: 나이, 성별 등 기본적인 프로필 정보
- 상호작용: 사용자별 노출 수, 클릭 수, 좋아요/싫어요 등

특히, 상호작용 데이터는 이후 모델 학습 시 중요한 supervision signal로 활용될 수 있습니다.

(2) 피처 엔지니어링

수집된 데이터 중에서 모델 입력으로 사용할 피처를 정의하고, 전처리하는 단계입니다.

이 시스템에서는 입력이 이미지이기 때문에, 이미지 전처리가 필수적으로 수행되어야 합니다.

대표적인 전처리 과정은 다음과 같습니다.

- resizing
- scaling
- z-score normalization
- 이미지 색상 모드 통일 (RGB 등)

이미지 전처리 관련해서 좀 더 상세한 내용이 궁금하다면 아래 글을 참고하면 좋습니다 :)

- [패턴인식] 영상 처리(1) : 디지털 영상, 히스토그램: https://codingsmu.tistory.com/102
- [패턴인식] 영상 처리(2) : 이진영상, 영상 처리의 세가지 기본 연산: https://codingsmu.tistory.com/103

[패턴인식] 영상 처리(2) : 이진영상, 영상 처리의 세가지 기본 연산

codingsmu.tistory.com

4️⃣ 모델 개발

모델 개발 단계에서는 (1) 모델 선택, (2) 학습 방식, (3) loss function을 결정합니다.

(1) 모델 선택

기본적으로 이미지 데이터를 다루기 때문에, Neural Network 기반 모델을 사용합니다.

대표적으로는 다음과 같은 구조가 있습니다.

- CNN 기반: ResNet 등
- Transformer 기반: ViT (Vision Transformer)

최근에는 transformer 기반 모델이 많이 사용되는 추세이지만, 여전히 CNN 기반 모델도 안정적으로 많이 활용됩니다.

(2) 모델 훈련 (Contrastive Learning)

이 문제에서는 유사한 이미지를 가깝게, 다른 이미지를 멀게 학습해야 하므로 contrastive learning 방식이 적합합니다.

훈련 데이터 포인트

학습 데이터는 다음과 같이 구성됩니다.

Query 이미지 (q)
Positive 이미지 (1개)
Negative 이미지 (n-1개)

여기서, Positive 데이터를 어떻게 구성할지가 중요한 포인트입니다.

대표적인 방법은 다음과 같습니다.

1) 사람 라벨링
- 가장 정확하지만 비용이 큼

2) 사용자 상호작용 기반
- 클릭, 좋아요 등을 활용
- 확장성은 좋지만 noise가 존재 → 필터링 필요

3) 데이터 증강 (self-supervised)
- crop, rotation, color 변환 등
- simCLR, MoCo 등의 방식

이 중, 초기 cold-start 상황에서는 simCLR 기반 augmentation을 사용할 수 있고,
이후에는 실제 사용자 데이터를 활용하는 방향으로 발전시킬 수 있습니다.

단, augmentation 기반 데이터는 실제 semantic 유사성과 차이가 있을 수 있다는 한계가 있습니다.

(3) Loss Function

목표는 다음과 같습니다: 유사한 이미지는 임베딩 공간에서 가깝게, 다른 이미지는 멀어지도록 학습하는 것

이를 위해 일반적으로 다음 과정을 거칩니다.

1. 임베딩 간 유사도 계산
2. softmax를 통해 확률로 변환
3. cross entropy로 loss 계산

복잡한 수식보다도, 아래 그래프를 보면 이해가 빠릅니다.

(좌) softmax , (우) cross entropy function

softmax는 0~1로 값을 정규화 해주는 작업으로, cross entropy는 loss 값을 계산해준다고 생각하면 됩니다.

예로, 레이블이 3개 (긍정, 중립, 주정)인 모델이 있다고 합니다. 예측1,2의 결과는 softmax를 거쳐 합이 1인 값으로 나온다고 했을 때, loss 값은 다음처럼 계산될 수 있습니다. 모델은 loss가 최소화되는 방향으로 학습됩니다.

- (예시1) GT=긍정일 때, 모델의 예측값→ [긍정, 중립, 부정] → [0.6, 0.1, 0.3] → -log(0.6) = 0.51 (loss 값. 낮음)

- (예시2) GT=중립일 때, 모델의 예측값→ [긍정, 중립, 부정] → [0.6, 0.1, 0.3] → -log(0.1) = 2.3 (loss 값. 높음)

5️⃣ 평가

모델 성능 평가는 크게 (1) 오프라인 평가, (2) 온라인 평가로 나눌 수 있습니다.

(1) 오프라인 평가
대표적으로 다음과 같은 지표를 사용합니다.

- MRR
- Recall@K
- Precision@K
- mAP (mean Average Precision)
- nDCG (normalized Discounted Cumulative Gain)

검색/추천 시스템에서는 단순 accuracy보다 ranking metric이 중요합니다. 따라서 MRR, mAP, nDCG 메트릭을 주로 평가 지표로 사용됩니다.

각 지표를 다음의 예시로 계산해보겠습니다.

후보 이미지: [a, b, c, d, e]
GT 유사도: [5, 4, 1, 0, 2] (threshold ≥ 3 → a, b가 정답)
예측값이 정답일 때 ✅, 예측값이 오답일 때⏺️

MRR (Mean Reciprocal Rank) : 첫 번째 정답이 얼마나 빠르게 등장하는지를 측정합니다.

a(혹은 b)를 첫번째 시도에 예측했을 때 → 1

- ✅⏺️⏺️⏺️⏺️

- ✅⏺️⏺️✅⏺️

a(혹은 b)를 세 번째 시도에 예측했을 때 → 1/3

- ⏺️⏺️✅⏺️⏺️

- ⏺️⏺️✅✅⏺️

Recall@K: 정답을 얼마나 많이 찾았는지를 평가합니다.

- recall@1: [a] → 1/2 = 0.5
- recall@2: [a, b] → 2/2 = 1

단, 정답 개수가 많은 경우 값이 낮아지는 경향이 있어 검색 시스템에서는 한계가 있습니다.

Precision@K: 예측한 결과 중 정답 비율을 측정합니다.

- precision@5: 2/5 = 0.4

순서 정보가 반영되지 않기 때문에 ranking 품질을 평가하기에는 부족한 지표입니다.

mAP (Mean Average Precision)

이진 관련성 (relevant / non-relevant) 기준으로 평가하는 지표입니다.
정답이 등장할 때마다 precision을 계산하고 평균을 냅니다.

즉, 정답이 등장하는 위치가 앞쪽일수록 점수가 높으며, binary relevance 기준에서는 잘 동작합니다.

계산 시 먼저 AP를 구합니다. 즉, 정답이 등장할 때마다 precision을 계산해서 평균냄.

: k개의 항목에서 precision@k의 평균을 구함 (AP) → (4개 AP의 합)/4=0.37 → mAP

- 예측 1: ⏺️⏺️✅→ 1/3 → AP → (1/3)/1 = 0.33

- 예측 2: ✅, ✅⏺️⏺️✅ → 1, 2/4 → (1+2/4)/2=0.75

- 예측 3:⏺️⏺️✅, ⏺️⏺️✅✅ → 1/3, 2/4 → (1/3+2/4)/2=0.41

- 예측 4: ⏺️⏺️⏺️⏺️⏺️ → 0

nDCG (Normalized Discounted Cumulative Gain)

연속적인 relevance score (예: 0~5)를 반영하는 지표입니다.
이상적인 순위와 비교하여, 현재 결과가 얼마나 좋은지 평가합니다.

예시로 다음 상황을 가정해봅시다.

GT: [5, 4, 1, 0, 2]
예측: [d, a, c, b, e]

먼저, DCG를 계산합니다. (실제 예측 값 기반)

다음으로 IDCG를 계산합니다. (이상적인 순서)

이를 DCG/IDCG로 하면, 실제 예측값이 얼마나 이상적인 순서에 가까운지를 계산할 수 있습니다.

(2) 온라인 평가

모델을 실제 서비스에 배포한 이후에는, 비즈니스 지표 기반으로 성능을 평가합니다.

확인해야 할 포인트는 다음과 같습니다. : “이 모델이 실제로 사용자 경험을 개선했는가?”

대표적인 지표로는 클릭률 (CTR), 체류 시간 (dwell time), 재방문율 등이 있습니다.

[Claude code] 설치 및 사용법 Vscode, Terminal

계속지나가기 — Fri, 10 Apr 2026 21:48:39 +0900

드디어 회사 정책이 바뀌어서 claude code를 개발 서버에서 사용할 수 있게 되었다.

(지금까지 계속 chatgpt에 무지성 코드 복사 붙여넣기 했던거는 안 비밀...)

돈을 지원해주진 않지만 그래도 허용해준 것만으로도 감지덕지하다.

관련해서 처음 세팅하면서 헤맸던 부분들 위주로 정리해봤다.

본 게시글은 vscode에서 처음 claude code를 세팅하고 사용해보는 사람들을 위한 글이다. 이미 세팅을 완료해서, 몇 번의 사용 경험이 있다면 이 글은 패스해도 좋다.

1. vscode에 claude code를 사용하려면 최소 pro는 구독

- 수수료 포함해서 매달 22달러, 매년은 220달러다. 맛보기용으로 22$ 매월 결제로 설정했다.

- 가입만 하면, 연동은 쉽다. vscode를 열어 extension에서 설치 후, terminal을 열어서 claude를 입력하면 아주 귀여운 창이 나온다.

Pro 플랜 구독료

(Opt.) 가끔 무료 크레딧을 준다 (20$~)

- 본인은 5일 차이로 놓쳤지만, 비정기적으로 무료 크레딧을 뿌리니 잘 모니터링 하도록 하자.

- 이전 무료 크레딧 이벤트 참고:

https://neonomadj.com/%ED%81%B4%EB%A1%9C%EB%93%9Cclaude-%EC%9C%A0%EB%A3%8C-%EC%82%AC%EC%9A%A9%EC%9E%90-%EC%A3%BC%EB%AA%A9-%EB%AC%B4%EB%A3%8C-%ED%81%AC%EB%A0%88%EB%94%A720200-%EC%8B%A0%EC%B2%AD-%EB%B0%A9%EB%B2%95/

클로드(Claude) 유료 사용자 주목! 무료 크레딧($20~$200) 신청 방법 및 주의사항 – 4월 17일까지 | Neon

최근 앤스로픽(Anthropic)에서 Claude 사용자를 위한 파격적인 프로모션을 발표했습니다. 새로운 '사용량 번들(Usage bundles)' 출시를 기념하여, 현재 구독 중인 플랜 가격에 상응하는 일회성 추가 사용

neonomadj.com

2. 초기 설정 in Terminal

유료 결제를 완료 했다면, claude를 설치하자

설치 방법은 mac os에 home brew가 설치되어 있다는 가정으로 설명하려고 한다.

(만약 homwbrew가 아직 없다면 설치부터 하자 (참고: https://brew.sh/). claude code 외에 mac에서 개발하려면 필수템 중 하나다)

설치는 여러 루트로 할 수 있지만, 가장 간편한 cli에서 설치 방법을 추천한다.

npm install -g @‌anthropic-ai/claude-code

만약 npm이 없다면 다음 명령어로 설치가 가능하다: brew install node

이제 claude를 터미널 명령어로 입력하면, 다음 화면으로 시작할 수 있다.

초기 UI 화면

- 처음 시작하면 내가 지금 있는 위치(pwd)가 어딘지 헷갈리는데, claude 명령어를 검색하기 직전 위치에서 열린다고 보면 된다.

- 즉, claude로 수정/생성하고자 하는 폴더 위치에서 cluade를 키면 된다!

작업하고자 하는 폴더에 /init 을 하면, 프로젝트를 설명해주는 마크다운 파일을 만들 수 있다.

/init 명령어가 완수되면 CLAUDE.md 파일이 root 경로에 생긴다.

- 원하는 프로젝트로 이동 후, 첫 작업 시작전에 /init 명령어로 해당 프로젝트를 설명해주는 .md 파일을 먼저 만들어보자.

- 이후에 작업할 때, claude 가 이 .md 파일을 참고해서 작업을 더 수월하게 진행 할 수 있다. 단, AI가 작성한 초안 개념이기 때문에, .md 파일을 열어 환각 현상은 없는지, 추가에야할 정보는 없는지 반드시 확인하도록 하자.

- (주의할점 1) 코드 베이스로 .md 파일을 만들어주기때문에 빈 폴더면 작업이 불가능하다.

- (주의할점 2) 폴더명을 잘 지어야 하는데, 비슷한 폴더명이 있으면 자꾸 참고해도 되냐고 묻는다. 다 돈이기 때문에 중요한 폴더만 참고할 수 있도록 하자.

(opt.) 호출 모델을 변경할 수 있다

default는 sonnet4.6 (effort: high) 모델이다

- /model을 입력하면 대화하는 모델을 바꿀 수 있다. 모델 성능은 Opus > Sonnet > Haiku 순이다.

- 이것저것 해보니까 어지간히 복잡한 Task 아니면 기본값인 Sonnet이 제일 무난하다. Opus는 성능은 좋으나 토큰수를 두배로 잡아먹기 때문에, 몇 번 대화를 안해도 사용량을 초과하는 경우가 많아 정말 가끔만 사용하게 된다. Haiku는 응답 속도가 빨라 간단한 태스크에서 사용하기 무난하다.

3. Claude에게 일 시키기 (코드 생성, 데이터 분석 등)

- 이제 가장 기본으로 준비해야될 일은 끝났으니, 일을 시켜보도록 하자. 관련해서는 다음 블로그를 참고했다. 자주 사용하는 명령어는 기억해두도록 하자: Claude Code 완전 가이드: 터미널에서 AI와 함께 개발하기

- 시키려는 일(instruction)을 --prompt 인자에 넣어서 넘겨주면 된다. 기존 파일을 수정하거나, 새 파일을 생성하는 경우 모두 --file 인자에 입력하면 된다.

1️⃣ 코드 생성: claude-code generate --file {file_name} --prompt {instruction}

- 신규 생성 및 수정하고 싶은 파일 이름을 {file_name}에, 지시사항을 {instruction}에 넣으면 작동한다.

2️⃣ 데이터 분석: {instruction}

- 데이터 분석을 하고 싶을 때는, 대상 파일의 경로, 이름 등을 주고 chatgpt한테 질문하듯이 자연어로 검색하면 된다.

- 필요하다면 코드를 짜고, 그 코드를 돌려서 나온 결과를 cmd 창에 바로 띄어준다. 만약 코드에 실수가 있다면, 자기 스스로 수정해서 다시 생성한다.

- 아래는 특정 .jsonl 파일을 열어서 tool_type을 카운트 해달라고 시킨 결과이다. 한 번의 python code 실패 후 스스로 수정 후 결과값을 출력하는 것을 확인할 수 있다.

출력 결과가 꽤나 이쁘게 나오는걸 확인할 수 있다. 요청하지도 않은 결과 분석까지 마지막에 해준다 (code_exec is far the most...)

(opt.) 실험. 과연 복잡한 작업을 한번에 잘 수행할 수 있는가?

- chatgpt 사용 시에는 최소 5단계는 나눠서 prompt를 입력한 작업을, claude에 한번에 넣어보았다. 과연 잘 할까?

- html에 데이터(약 30개 url)를 수집 -> 정제 (html2txt) -> 카데고리 분류 까지 하는 작업을 한 입력에 다 넣어봤다. 아래처럼 Prompt도 굉장히 길다. 작업이 헛되지 않게 한글로 1차 작성 후, chatgpt를 이용해서 정제 및 영어로 번역을 부탁했다.

- token usage가 0%에서, 이 작업 한번에 310%로 초과해버렸다. 토큰을 다 사용하면 중간에 작업이 중단되는게 아닌가 걱정했지만, 다행이도 cost usage만 넘지 않으면 중간에 끊기진 않는다.

한 번의 작업으로 한달 비용 중 10% 소모. 10~15분정도 걸렸다.

- 최종 결과를 보면, 지시한대로 step-by-step으로 작업을 잘 수행한 것을 확인할 수 있다. web-fetch, html수집, 정제, 분류까지 한번에 수행해주다니 claude 최고...

- 한가지 아쉬운건, 코드로 짜달라고 할 껄 그랬다. 권한때문에 y를 중간중간에 눌러야되는게 많고, 재현해볼 코드가 없으니 다음에 같은 작업 수행 시 또 token을 사용해야 된다. 왠만하면 재현할 수 있는 파이썬 코드를 작성해달라고 프롬프트에 넣을 것.

* 사용 프롬프트 참고

[1차. 작성 한글 prompt]

./office_document' 폴더에 docx, pdf, xlsx, ppt 관련 document를 구축해야 돼. 아래 방법대로 이 document를 구축하려고 해.

먼저 './office_document/reference.txt'는 네 가지 타입과 관련이 있는 python-library 버전들을 적어두었어. 이 파일을 읽고, 각 라이브러리와 명시된 버전에 맞게 최종적으로 네 가지 타입에 대한 document를 각각 생성하려 고 해.

아래는 네가지 오피스 타입 중, pdf 관련된 document ("./office_document/pdf.txt")를 구축하는 방법이야. 아래 순서대로 나머지 오피스타입도 document를 구축하면 돼.

가장 먼저, './office_document/reference.txt'에서 네 가지 오피스 타입과 관련된 라이브러리를 분류할 것. 결과 파일은 './office_document/reference_office_type.json'으로 저장. 예시 ({"pdf":["fpdf2 2.8.3", "reportlab 3.6.12", ...])

pdf 관련된 document ("./office_document/pdf.txt")를 구축하는 방법
1. pdf와 관련된 library로 분류된 (예:fpdf2 2.8.3) 파이썬 라이브러리의 문서를 찾을 것. "https://pypi.org/project/" 웹사이트에서 "fpdf2"와 명시된 버전인 "2.8.3" 페이지를 검색
2. "https://pypi.org/project/fpdf2/2.8.3/" 페이지를 찾았다면, 해당 페이지의 html 정보를 읽어오고, "./office_document/raw_data/{office_type}_{library}_v{ver}.html"로 저장. 여기서는 "./office_document/raw_data/pdf_fdpf2_v2_8_3.html"로 저장하면 됨.
3. document의 구축 목적은, 오피스 관련 오픈데이터셋을 자동으로 생성하기 위함임. 해당 document를 참고해서 Llm이 적절한 nl2code 데이터로 생성할 수 있게 document를 해당 라이브러리 명세 형식으로 수정. 단 버전 정보는 반드시 유지되어야 하며, html에 없는 정보는 추가하지 말것. 해당 파일은 "./office_document/html2txt/{office_library}_{library}_v{ver}.txt"로 저장할 것.
4. 최종적으로, './office_document/reference_office_type.json'에 저장된 타입을 참고해서 "./office_document/html2txt/" 수집된 파이썬 라이브러리에 대한 명세를 "./office_document/{office_type}.txt"로 분류해 네 개의 파일로 생성할 것. 즉, "./office_document/pdf.txt"는 pdf와 관련된 라이브러리에 해당하는 "fpdf2 2.8.3", "reportlab 3.6.12"에 대한 내용이 들어가 있어야 함. 단, 네 가지 타입에 해당하지 않을 경우 "./office_document/others.txt"로 저장할 것.

[2차. chatgpt 정제 및 영어 번역]

You are tasked with upgrading the open dataset generation pipeline from version 2.5 to version 3.

## Background
- The current pipeline (v2.5) is located at: `./v2_5_gen_process_code`
- It includes `1_generate_loop_n.py`, which currently supports only `pdf` and `docx`.
- The goal is to upgrade this pipeline to version 3 so that it supports four office document types:
  - pdf
  - docx
  - xlsx
  - ppt

## High-Level Goal

Before modifying the generation code, you must first build structured documentation for each office type under `./office_document`.

---

## Step 1: Parse Reference File

Input:
- `./office_document/reference.txt`

Task:
- Read the file and classify all listed Python libraries (with versions) into office types:
  - pdf
  - docx
  - xlsx
  - ppt
  - others (if not applicable)

Output:
- Save the classification result as:
  `./office_document/reference_office_type.json`

Format example:
{
"pdf": ["fpdf2 2.8.3", "reportlab 3.6.12"],
"docx": [...],
"xlsx": [...],
"ppt": [...],
"others": [...]
}

## Step 2: Collect Raw HTML from PyPI

For each library in each office type:

1. Construct the PyPI URL: https://pypi.org/project/{library_name}/{version}/

2. Fetch the HTML content of the page.

3. Save the raw HTML file to: ./office_document/raw_data/{office_type}_{library}_v{version}.html

Naming rules:
- Replace dots in version with underscores (e.g., 2.8.3 → v2_8_3)
- Example:pdf_fpdf2_v2_8_3.html

Constraints:
- Do NOT modify the HTML content
- If the page does not exist, skip and log the failure

## Step 3: Convert HTML to Structured Text Specification

Goal:
Transform each HTML document into a clean, structured specification that can be used for NL2Code dataset generation.

For each HTML file:

1. Extract relevant documentation content.
2. Convert it into a structured text format describing:
- library purpose
- key classes/functions
- usage patterns

Output:
- Save to:./office_document/html2txt/{office_type}_{library}_v{version}.txt

Constraints:
- MUST preserve the exact library version
- MUST NOT add information that is not present in the HTML
- MUST NOT hallucinate or infer missing details
- Keep the format consistent across all libraries

## Step 4: Aggregate by Office Type

Using:
- `reference_office_type.json`
- files in `./office_document/html2txt/`

Task:
- Merge library specifications into one file per office type:

Output files:
./office_document/pdf.txt
./office_document/docx.txt
./office_document/xlsx.txt
./office_document/ppt.txt
./office_document/others.txt

Requirements:
- Each file must contain all corresponding library specifications
- Maintain clear separation between libraries
- Preserve version information for every library

## Final Notes

- Follow the exact directory and naming conventions
- Do not skip steps
- Ensure all outputs are reproducible and consistent
- Log any failures or missing data clearly

간단 소개

계속지나가기 — Sat, 8 Feb 2025 16:41:43 +0900

자연어처리 엔지니어로 밥벌어 먹고 있는 사람입니다.

아직 주니어 개발자라 부족함이 많습니다. 게시글에 궁금한 내용이 있거나,

잘못된 정보라고 생각하시는 부분이 있다면 언제든지 댓글로 알려주세요

블로그 관련 문의는 다음 이메일로 받고 있습니다.

als398@naver.com

*해당 티스토리는 2020년도부터 코딩스뮤라는 이름으로 CS 관련 기술 블로그로 운영되고 있습니다.

2차 전직을 AI로 해서, 최근에는 AI 특히, NLP 관련 내용을 다루고 있습니다.

[주간 LLM] LLM (1) - 딥시크(DeepSeek) 모델

계속지나가기 — Fri, 7 Feb 2025 15:40:55 +0900

주간 LLM 은 매주 LLM 관련 최신 연구, 논문을 다루는 시리즈 입니다.
2025.02 - 1주차는 최근 주목받고 있는 오픈소스 LLM인 딥시크(DeepSeek)에 대해 다룹니다.

Overview

최근 중국의 AI 스타트업인 DeepSeek가 개발한 오픈소스 LLM이 세계적으로 주목받고 있습니다. 사실, DeepSeek에서 처음 공개한 모델은 23년 11월에 공개된 코딩 특화 모델 DeepSeek Coder이지만, DeepSeek의 이름이 주목받기 시작한 것은 작년 말인, 약 670B의 거대 언어모델인 DeepSeek-V3을 80억원에 불가한 획기적인 비용으로 개발했다는 사실이 알려지면서 입니다. 또한, 바로 저번달인 25년 1월에 DeepSeek-R1모델이 공개되면서 수천억원의 비용을 들여 모델을 개발한 OpenAI와도 비교되고 있는 상황입니다. 하지만, DeepSeek의 저비용-고성능 모델 개발이 가능했던 이유를 아래의 사진처럼 보는 시각도 있긴 합니다.

(출처: @Thread)

본 글에서는 DeepSeek에서 공개한 모델의 히스토리와, 모델의 학습 기법, 최근 추론형으로 나온 DeepSeek-R1 모델을 직접 돌려보도록 하겠습니다.

*deepseek의 전반적인 이론보다는, 실제로 현업에서 deepseek를 학습/추론으로 사용하고 싶은 분께 더 적합한 내용을 다루고 있습니다.

1. DeepSeek 모델을 돌리기 위한 하드웨어 스펙

실제로 현업에서 DeepSeek를 사용하려고 한다면, 개인 혹은 회사 자원으로 DeepSeek를 돌릴 수 있을까가 가장 궁금할 것 입니다. 아래 huggingface에서 오피셜 모델들을 제공하고 있으며, 크게 Full Model과 Qunatization Model로 나누어집니다. 각각의 모델을 돌리기위한 최소 GPU 사양을 살펴보겠습니다.

https://huggingface.co/deepseek-ai

deepseek-ai (DeepSeek)

Running on Zero

huggingface.co

*아래 스펙은 가장 최신에 나온 DeepSeek-R1을 기준으로 작성되었습니다. 이전모델(ex. DeepSeek-V3)의 경우 다음 링크를 참고하시길 바랍니다(https://apxml.com/posts/system-requirements-deepseek-models)

1.1. Full Model

Model	Parameter	VRAM Requirement	Recommended GPU
DeepSeek-R1-Zero	671B	~1,543 GB	Multi-GPU setup (NVIDIA A100 80GB x16)
DeepSeek-R1	671B	~1,543 GB	Multi-GPU setup (NVIDIA A100 80GB x16)
DeepSeek-R1-Distill-Qwen-1.5B	1.5B	~3.9 GB	NVIDIA RTX 3060 12GB or higher
DeepSeek-R1-Distill-Qwen-7B	7B	~18 GB	NVIDIA RTX 4090 24GB or higher
DeepSeek-R1-Distill-Llama-8B	8B	~21 GB	NVIDIA RTX 4090 24GB or higher
DeepSeek-R1-Distill-Qwen-14B	14B	~36 GB	Multi-GPU setup (NVIDIA RTX 4090 x2)
DeepSeek-R1-Distill-Qwen-32B	32B	~82 GB	Multi-GPU setup (NVIDIA RTX 4090 x4)
DeepSeek-R1-Distill-Llama-70B	70B	~181 GB	Multi-GPU setup (NVIDIA A100 80GB x3)

모델 별 학습 파라미터와 요구되는 최소 GPU 사양을 위 표에서 구체적으로 확인할 수 있습니다. 원본 모델의 경우 멀티 GPU 세팅으로 무려 A100 80GB가 16개가 필요합니다. 개인으로는 택도 없고, 회사에서도 서버가 넉넉하지 않는 이상 돌리기 힘든 사양입니다.

따라서 공식에서는 R1 모델로 생성된 합성 데이터로 파인튜닝된 모델인 Qwen, Llama 를 이용한 'DeepSeek-R1-Distill' 모델도 함께 제공하고 있습니다. 1~8B 모델의 경우는 개인이 돌리기에도 부담스럽지 않은 요구사항을 보입니다.

추가로, VRAM Requirement는 GPU가 데이터를 저장하고 불러올 수 있는 VRAM의 최소용량을 얘기합니다. nvidia-smi 명령어를 터미널에 입력하시면 쉽게 확인할 수 있는데, 예시로 제 서버에 해당 명령어를 치면 다음과 같은 테이블이 나옵니다. 이때, 81920MiB -> 80GB의 VRAM 용량으로 최대 DeepSeek-R1-Distill-Qwen-32B 정도까지 올릴 수 있는 걸 확인할 수 있습니다.

1.2. Quantized Models

Model	Parameter	VRAM Requirement	Recommended GPU
DeepSeek-R1-Zero	671B	~436 GB	Multi-GPU setup (NVIDIA A100 80GB x6)
DeepSeek-R1	671B	~436 GB	Multi-GPU setup (NVIDIA A100 80GB x6)
DeepSeek-R1-Distill-Qwen-1.5B	1.5B	~1 GB	NVIDIA RTX 3050 8GB or higher
DeepSeek-R1-Distill-Qwen-7B	7B	~4.5 GB	NVIDIA RTX 3060 12GB or higher
DeepSeek-R1-Distill-Llama-8B	8B	~5 GB	NVIDIA RTX 3060 12GB or higher
DeepSeek-R1-Distill-Qwen-14B	14B	~9 GB	NVIDIA RTX 4080 16GB or higher
DeepSeek-R1-Distill-Qwen-32B	32B	~21GB	NVIDIA RTX 4090 24GB or higher
DeepSeek-R1-Distill-Llama-70B	70B	~46 GB	Multi-GPU setup (NVIDIA RTX 4090 24GB x2)

Full Model이 너무 부담스럽다면 다음의 경량화 모델 옵션도 고려해볼 수 있습니다. 위 표의 모델은 모두 원본 모델을 4-bit로 Quantization한 모델로, Distillation 모델의 경우 개인 컴 GPU로도 많이 사용하는 RTX3050, 3060 스펙에서도 돌아간다고 합니다. R1, R1-Zero 모델도 A100 80GB 6장으로 돌릴 수 있다고 합니다. Quntization 모델의 경우 전반적으로 요구되는 VRAM 용량이 대략 1/3로 줄어든다고 합니다.

2. DeepSeek 모델 별 학습 기법, 특징

다음으로, DeepSeek에서 공개한 모델들의 학습 기법 및 특징을 살펴보겠습니다.

모델	발표일	사이즈	비교 모델	특징
DeepSeek Coder	23.11	1B~33B	CodeLlama, GPT-3.5, 4 (Code Task Only)	코딩 특화 모델. (학습시 87% 코드, 13% 자연어 구성)
DeepSeek Math	24.02	7B	GPT-4, Gemini, Qwen (Math Task Only)	수학 문제 특화 모델
DeepSeek-VL, VL2	24.03	1.3B~7B	GPT-4V, Qwen-VL	Vision-Language 모델로, 다양한 multi-modal task 수행이 가능
DeepSeek-V2	24.05	236B	Llama3, Qwen1.5	본격적으로 100B이상의 LLM 모델 등장 시기. 비용 절감과 성능 향상에 초점을 둠 (GPT-4 대비 1/10 비용)
DeepSeek-V3	24.12	671B (37B)	Qwen2.5-72B, Lllama 3.1-405B	총 파라미터는 671B이나, 활성화되는 파라미터는 37B (MoE 아키텍처 도입)
DeepSeek-R1	25.01	671B (37B)	openai-o1, o1-mini	Deepseek-V3 모델 기반으로, 두가지 강화학습 기법을 적용한 모델(R1, R1-Zero) 공개 무료 추론이 가능한 어플 공개로, Chatgpt를 제치고 북미 앱 다운로드 1위 달성

2.11 코딩, 수학 모델: DeepSeek-Coder, Math

DeepSeek 모델의 처음 시작은 코딩과 수학 문제 해결에 초점이 맞춰진 모델입니다. DeepSeek Coder 모델의 경우 약 86개의 다양한 프로그래밍 언어를 지원합니다. DeepSeek Math에서는 7B 모델로, 용도에 따라 Base, Instruct, RL 버전을 함께 제공하며 다양한 카테고리의 수학 문제 해결을 제공합니다. 해당 모델에서는 영어와 중국어만을 지원하며 공개된 벤치마크에 의하면, 코딩 문제와 수학 문제 해결 태스크에 한해서 GPT-3.5와 GPT-4 사이의 성능을 보입니다.

2.2. Vision-Language 모델 등장: DeepSeek-VL, VL2

DeepSeek VL의 경우 Vision-Language 모델로 기존에 공개된 모델과 달리 다양한 Multi-Modal Task 수행이 가능해졌습니다. VL의 경우 1.3B, 7B 사이즈의 모델을, VL2의 경우 기존 VL1을 업그레이드한 버전으로, 1B, 2.8B, 4.5B 세 가지 모델로 구성되어 있습니다.

2.3. 저비용-고성능 모델: DeepSeek-V2, V3, R1

DeepSeek-V2는 236B 모델로 본격적으로 DeepSeek가 거대 언어모델 경쟁에 뛰어들게 된 것을 알린 모델입니다. 236B의 Base모델과 함께 16B의 Lite, V2-Chat (RL) 버전 모델을 함께 공개했습니다. V3는 V2 대비 추론 속도가 약 3배 빨라졌으며, gpt-4o와 유사한 성능을 보이나 2048개의 H800(H100의 저가형 모델)을 이용해 671B의 거대 언어 모델을 학습했다고 공개하면서 큰 파장을 일으킨 모델입니다.

가장 최근에 공개된 강화학습 기반의 추론 모델인 DeepSeek-R1 모델의 경우, R1, R1-Zero, 자체적으로 파인튜닝한 Distillation 모델(llama, Qwen)을 공개했습니다. R1 모델 시리즈의 경우, 이전 모델인 V3 기반으로 671B 파라미터를 가진 MoE(Mixture of Experts) 구조를 가집니다. 여기서 MoE 구조란, 각 분야에 특화된 sub-network를 의마하는 전문가의 조합을 통해 입력 데이터를 처리하는 기술로 언어 모델의 고속 추론을 위해 사용되는 기법 중 하나입니다. 먼저 R1-Zero의 경우 V2모델에 SFT(Supervised Fine-Tuning) 없이 직접 강화학습을 적용한 모델로 추론 성능은 크게 향상되나 낮은 가독성, 반복 문장 생성, 언어 혼용 등 한계점이 발생합니다. R1은 이러한 문제점을 극복하기 위해 고안된 Training Recipe로 학습된 모델이며, 적은 양의 cold-start data(초기 데이터)를 활용합니다. 이 방법을 통해 초기 학습 단계의 불안정성을 감소시키며 가독성을 향상시킨다고 합니다. R1 모델은 다양한 태스크에서 o1-mini를 뛰어넘고, o1과 유사한 성능을 보입니다. 또한 기존에는 영어, 중국어만을 지원했으나 한국어 등 다른 언어에 대한 지식도 어느정도 보유합니다. 추가로, R1 모델에서 학습된 지식을 작은 모델(Qwen, Llama)에 증류하여 추론 능력을 기존 모델 대비 크게 향상시킨 Distillation 모델도 함께 공개했습니다.

*분량이 길어질 것 같아, 다음 주간 LLM 편에서 딥시크(DeepSeek) 모델의 실습 파트를 다루도록 하겠습니다.

References

GPU system Requirements for Running DeepSeek-R1: https://apxml.com/posts/gpu-requirements-deepseek-r1
huggingface(official model): https://huggingface.co/deepseek-ai

[주간 LLM] LLM Evaluation (2) LLM-as-a-Judge

계속지나가기 — Mon, 20 Jan 2025 19:30:02 +0900

주간 LLM 은 매주 LLM 관련 최신 연구, 논문을 다루는 시리즈 입니다.
2025.01 - 4주차는 LLM을 활용하여 LLM 성능을 평가 할 수 있는 model-based evaluation 기법에 대해 다룹니다.

Overview

최근 점점 더 다양한 영역에서 높은 성능을 내고 있는 LLM을 평가하는 것은 굉장히 어려운 과제 중 하나입니다. 이를 위해 다양한 벤치마크, 휴먼 평가를 수행하고 있으나, 모델의 광범위한 능력(broad capabilities)을 기존의 방법만으로 평가하기는 적합하지 않습니다.

이를 해결하기 위해, 역으로 LLM의 능력을 활용하여 LLM을 평가하는 방법론들이 최근 많이 연구되고 있습니다. 이 중 NeurIPS 2023에 소개된 "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" 논문을 소개하고자 합니다. 줄여서, LLM-as-a-Judge로 많이들 알고계신 해당 논문은 2025년 1월 현재 2319회의 인용수를 보이며 후속 논문들도 많이 발표된 연구입니다.

Abstract

본 논문에서는, strong LLM을 judge로 사용하여 opend-ended questions에 대해 평가하는 방법을 연구하였으며 LLM judge의 사용과 한계(position, verbodity, self-enhancement)및 제한된 추론 능력을 검토하고, 이를 완화하기 위한 해결책을 제안했습니다.

실험을 통해 GPT-4를 이용한 LLM Judge 모델이 인간 선호도와 80% 이상의 높은 일치도를 보이며 LLM을 Judge로 사용하는 것이 인간 선호도를 추정하는 확장 가능(scalable)하고 설명 가능한 방법임을 보였습니다.

추가로 본 논문에서는, LLM judge와 인간 선호도의 일치(agreement)를 확인하기 위해 다음의 벤치마크도 함께 소개합니다.

1. MT-bench(multi-turn question set)

- 총 8개의 카테고리(수학, 글쓰기 등)에서 multi-turn 질문을 통해 LLM의 대화 능력을 평가할 수 있는 벤치마크

- 데이터: https://huggingface.co/datasets/lmsys/mt_bench_human_judgments

2. Chatbot Arena(crowdsourced battle platform)

- 두 개의 LLM(chatbot)과 대화하며 실제 사용자가 개인 선호도에 따라 더 나은 답변을 고른 데이터 (크라우드 소싱 방식으로 수집)

- 데이터: https://huggingface.co/datasets/lmsys/chatbot_arena_conversations

1. Types of LLM-as-a-Judge

Llm-as-a-judge(이하 llm-judge) 에는 평가하고자 하는 답변 유형에 따라 다음과 같이 나눌 수 있습니다.

1. pairwise comparison

- LLM judge에 입력으로 하나의 질문과 두 개의 정답을 주고, 어느 답변이 나은지 (무승부 포함) 판별하게 함.

2. single answer grading

- 하나의 답변에 대해 직접 점수(1~10)를 매기도록 함.

3. reference-guided grading

- 채점 시, reference를 함께 제공하는 경우. 특정 경우(수학 문제, 계산 과정 참고)에서는 reference를 제공하는 것이 적절한 채점을 하는데 도움을 줄 수 있음.

2. Advantages & Limitations of LLM-as-a-Judge

Advantages

LLM Judge는 확장성(scalability)과 설명가능성(expainability)이라는 두 가지 주요 이점을 제공합니다. 또한, 평가시 사람의 개입이 필요하지 않아 빠른 평가가 가능하며, 평가 시 점수뿐만 아니라 설명도 제공해주기 때문에 결과물을 해석할 수 있다는 장점이 있습니다.

Limitations → Adressing Limitations

하지만, 단점 역시 존재합니다. 다음의 단점 네 가지와 함게 이를 극복할 수 있는 방안에 대해서 함께 얘기해보겠습니다.

1. Position Bias → Swapping Positions

LLM Judge는 특정 위치에 있는 답변을 선호하는 경향이 있습니다. 실제로, 유사한 답변 여러개를 순서대로 나열하고 가장 적절한 답변을 고르라고 할 때, 대부분의 LLM이 첫번째 위치를 선호합니다. (유사한 답변들이 입력으로 들어왔으므로, 순서에 편향되게 결과가 나타나면 안됨) →이는, 답변의 위치 변경을 통해 해결할 수 있습니다. 예로, 두 개의 답변을 위치를 바꾸어가며 2번 질문하였을 때, llm-judge가 똑같은 선호도를 보이는지 확인하면 됩니다.

2. Verbosity Bias → few-shot judge, Fine-tuning a judge model

LLM Judge는 더 정확하고, high-quality의 짧은 답변보다 더 길고, 장황한 답변을 선호하는 경향이 있습니다. 실제로, 답변1과 답변1을 열번 반복한 문장을 입력으로 넣었을 때, 동일한 문장이 반복되는 더 긴 답변을 선호하는 경향을 보입니다. →이는, few-shot으로 올바를 예시를 judge-message로 함께 넣어주거나, high-quality의 짧은 답변을 선호하도록 judge model을 fine-tuning하여 사용하는 것으로 해결할 수 있습니다.

3. Self-enhancement Bias → few-shot judge, Fine-tuning a judge model

LLM Judge는 자신이 생성한 응답을 더 선호하는 경향이 있습니다. 실제로, GPT-4를 llm-judge로 사용하고, 다른 모델이 생성한 답변과 함께 GPT-4의 답변을 입력으로 주었을 때, 10%정도 본인이 생성한 답변을 더 선호하는 경향을 보였습니다. (실제 답변 퀄리티는 확인해봐야 함) →이는, 마찬가지로 few-shot 및 judge model을 fine-tuning 하여 사용하는 것으로 개선할 수 있습니다.

4. Limited capability in grading math and reasoning questions → few-shot judge, cot & reference-guided judge, Fine-tuning a judge model

마지막으로, 기존 LLM이 다른 태스크보다 특히 추론 문제와 수학 문제에 약하기 때문에, 마찬가지로 llm-judge 시에도 해당 도메인에 약하다는 점입니다. 특히, LLM이 문제를 개별적으로 풀었을 때는 정답을 맞출 수 있어도, 제공된 답변에 의해 잘못된 판단을 내릴 수 있습니다.

→이는, few-shot 및 fine-tunining judge model 외에도, 기존 LLM의 수학 & 추론 능력을 향상시키키 위해 사용했던 CoT(chain-of-thought) 기법을 사용해 단계별 평가 방식, 혹은 수학 공식등을 함께 입력으로 주는 reference-guided judge 방식으로 개선할 수 있습니다.

Practice (by FastChat)

지금까지 "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" 논문에서 소개한 LLM-judge의 등장 배경과, 사용 방법, 장단점에 대해 알아봤습니다. 이제 실습을 통해 실제로 어떤 과정으로 LLM을 활용하여 llm이 생성한 답변들을 평가할 수 있는지 간단한 실습을 통해 알아보겠습니다.

먼저 코드는 다음의 깃 레포를 참고하시면 됩니다.

https://github.com/lm-sys/FastChat/tree/main/fastchat/llm_judge

FastChat/fastchat/llm_judge at main · lm-sys/FastChat

An open platform for training, serving, and evaluating large language models. Release repo for Vicuna and Chatbot Arena. - lm-sys/FastChat

github.com

1. 환경설정 및 평가 셋 다운로드

먼저, 평가를 위한 환경설정과 평가 셋을 다운로드해줘야 합니다.

git clone https://github.com/lm-sys/FastChat.git
cd FastChat/
pip install -e ".[model_worker,llm_judge]"

cd fastchat/llm_judge
python download_mt_bench_pregenerated.py

2. LLM 모델 답변 생성

다음으로, 원하는 모델의 답변을 생성해주면 됩니다. 위에서, mt-bench를 평가셋으로 다운받아주었으므로, mt-bench의 Question을 입력으로 넣어주고, LLM의 답변을 얻게 됩니다. llama-3.2 1B 모델의 답변을 한번 얻어보겠습니다.

# python gen_model_answer.py --model-path [MODEL-PATH] --model-id [MODEL-ID]
python gen_model_answer.py --model-path meta-llama/Llama-3.2-1B --model-id llama3.2-1b

모델의 답변은 다음의 경로에 저장됩니다. ./data/mt_bench/model_answer/[MODEL-ID].jsonl

3. LLM-Judge 모델 답변 평가

마지막으로, 생성된 모델을 LLM-judge로 평가해주면 됩니다. 여기서 설정할 주요 옵션은 다음과 같습니다.

1) LLM-judge 모델로 어떤 모델을 사용할지?

- 기본값으로 gpt-4가 설정되어 있습니다.

- 다른 모델을 사용하고 싶다면, --judge-model [JUDGE-MODEL] 옵션을 추가해주면 됩니다.

2) Judge message는 어떻게 할지?

- 기본옵션으로 "pairwise-baseline", "pairwise-all", "single" 있습니다.

- custom-message를 사용하고 싶다면, 아래 경로에 custom-prompt를 추가해주면 됩니다. ./data/judge_prompts.jsonl

export OPENAI_API_KEY=XXXXXX  # set the OpenAI API key
python gen_judgment.py --model-list [LIST-OF-MODEL-ID] --parallel [num-concurrent-api-call]

Judge 결과는 다음의 경로에 저장됩니다. ./data/mt_bench/model_judgement/[JUDGE-MODEL]_[JUDGE-TYPE].jsonl

(** 논문에서 소개한 MT-bench나 chatbot arena를 평가하고 싶다면, 위에 코드를 사용하는 것이 좋습니다. 하지만, 개별 모델의 개별 벤치마크를 llm-judge로 평가하고 싶다면, 사실상, 1. answer-generate, 2. judge 하는 두 코드만 생성하면 되는 것이라, 커스텀 코드를 스크래치부터 짜는 것도 추천합니다. )

References

- paper: https://arxiv.org/pdf/2306.05685

- code: https://github.com/lm-sys/FastChat/tree/main/fastchat/llm_judge

[주간 LLM] LLM Evaluation (1) - Ifeval

계속지나가기 — Mon, 13 Jan 2025 19:00:17 +0900

주간 LLM 은 매주 LLM 관련 최신 연구, 논문을 다루는 시리즈 입니다.
2025.01 - 3주차는 LLM의 instruction-following 능력을 평가할 수 있는 ifeval benchmark에 대해 다룹니다.

Overview

23년 11월에 Google과 Yale Univ에서 공개한 벤치마크 데이터 셋으로, LLM의 지시사항 준수 능력을 평가하기 위해 설계된 벤치마크로 검증 가능한 지시사항(verifiable instructions)을 포함합니다. 비교적 이전에 나온 논문이지만 LLM의 Instrcution 성능이 최근 더 중요해지면서 가장 유명한 LLM leaderboard 중 하나인, open llm leaderboard v2(24.10)에 추가된 벤치마크 입니다.

총 25개의 지시문 카테고리로, 여러 카테고리를 조합해 다양한 지시문을 생성할 수 있습니다. 총 541개의 데이터 셋이 있습니다.

- No capital letters are allowed(대문자 금지), You are not allowed to use any commas in your response. (콤마 금지)

각 프롬프트는 하나 이상의 구체적인 지시사항을 제공하며, 모델 응답이 이를 얼마나 정확히 수행하는지 평가합니다.

Dataset Detail & Eval metric

Dataset Detail

key	prompt	instruction_id_list
1000	I am planning a trip to Japan, and I would like thee to write an itinerary for my journey in a Shakespearean style. You are not allowed to use any commas in your response.	[ "punctuation:no_comma" ]
1258	I have a dime. What can I do with this dime? Give me advice in the style of a President of the United States and make sure it has at least 600 words.	[ "length_constraints:number_words" ]
1132	Write the lyrics to a hit song by the rock band 'The Gifted and The Not Gifted'. To make it rocky, the response should be in all capital letters. The word "rock" should not appear in your response.	[ "change_case:english_capital", "keywords:forbidden_words" ]

데이터 셋은 key, prompt, instruction_id_list, kwargs로 구성되어 있습니다. 상단 표에는 앞에 세 개의 컬럼만 가지고 왔습니다. 전체 데이터 셋을 확인하고 싶다면 아래 링크로 들어가시면 확인할 수 있습니다.

https://huggingface.co/datasets/google/IFEval

google/IFEval · Datasets at Hugging Face

[ { "num_highlights": null, "relation": null, "num_words": null, "num_placeholders": null, "prompt_to_repeat": null, "num_bullets": null, "section_spliter": null, "num_sections": null, "capital_relation": null, "capital_frequency": null, "keywords": null,

huggingface.co

prompt에는 다양한 시나리오(계획짜기, 조언, 가사 작성)와 함께 볼드체에 해당하는 다양한 지시문이 포함되어 있습니다. instruction_id_list에서는 각 지시문의 분류와 개수를 확인할 수 있습니다.

Evaluation Metric

논문에서는 다음과 같이 총 prompt-level과 instruction-level로 평가 매트릭 나누어 소개합니다.

- Prompt-level (strict acc/loose acc): The percentage of prompts that all verifiable instructions in each prompt are followed

- Inst-level (strict acc/loose acc): The percentage of verifiable instructions that are followed.

개별 지시문으로 따랐는지 확인

위의 설명을 해석해보자면, prompt-level은 지시문을 모두 따랐는지를, inst-level은 개별 지시문을 따랐는지를 확인하는 매트릭으로 설명이 되나, 이는 직관적으로 이해하기 어렵습니다. 이해를 위해 평가 코드를 살펴보면 다음과 같이 각각의 평가 매트릭을 정의하는 것을 확인할 수 있습니다.

def process_results(doc, results):
    # (..중략..)

    return {
        "prompt_level_strict_acc": out_strict.follow_all_instructions,
        "inst_level_strict_acc": out_strict.follow_instruction_list,
        "prompt_level_loose_acc": out_loose.follow_all_instructions,
        "inst_level_loose_acc": out_loose.follow_instruction_list,
    }

prompt-level의 경우 follow_all_instructions을, inst-level의 경우 follow_instruction_list을 가집니다. 이 두개의 차이는 다음 코드에서 확인할 수 있습니다.

def test_instruction_following_strict(inp,response,):
    """Tests response to see if instructions are followed."""
    instruction_list = inp.instruction_id_list
    is_following_list = []
    
    # (..중략..)
    
    for index, instruction_id in enumerate(instruction_list):
    
        # (..중략..)
        
        if response.strip() and instruction.check_following(response):
            is_following_list.append(True)
        else:
            is_following_list.append(False)
            
     return OutputExample(
        instruction_id_list=inp.instruction_id_list,
        prompt=inp.prompt,
        response=response,
        follow_all_instructions=all(is_following_list),
        follow_instruction_list=is_following_list,
    )

코드에서 확인할 수 있듯이, prompt-level의 경우, is_following_list에 저장된 값이 모두 True여야 1을, inst-level은 list를 전달받아 개별 지시문을 확인하는 것을 알 수 있습니다. 전체 코드는 아래 링크를 참고하시면 됩니다.

https://github.com/EleutherAI/lm-evaluation-harness/blob/main/lm_eval/tasks/ifeval/utils.py

이해를 위해 앞서 소개한 데이터 셋 중 key: 1132를 예시로 들자면, prompt-level의 경우 주어진 두 개의 지시문인 [ "change_case:english_capital", "keywords:forbidden_words" ]을 모두 지켜야 1점을, inst-level의 경우 개별 지시문의 수행여부를 보기 때문에 모두 지켰을 경우 1점, 하나만 지켰을 경우 0.5점, 모두 지키지 못했을 때 0점을 주게 됩니다. key 1000, 1258은 지시문이 한 개 이므로 prompt-level과 inst-level이 동일하게 점수를 부여합니다.

앞서 설명드린 내용은 prompt-level, inst-level의 strict acc에 대한 설명입니다. 그러면 loose acc는 어떻게 계산될까요? 논문에서는 다음의 방식으로 loose acc를 정의하고 있습니다.

LLM의 원본 응답을 resp라고 할 때, transform함수를 사용해 응답을 t 번 변형하여, 그 중 한 번이라도 지시문을 만족할 경우 점수를 주는 방식입니다. 변형 방식은 응답에서 흔히 사용되는 마크다운 태크(*,**) 제거, 서두/결론 제거 등이 있습니다.

최종적으로, Ifeval을 벤치마크로 사용하여 LLM을 평가할 경우 총 네개의 매트릭이 나오게 됩니다. prompt-level 보다는 inst-level이, strict-acc보다는 loose-acc가 더 높은 점수가 나오게 됩니다. Openleaderboard-v2에서는, strict-acc의 평균값(prompt, inst-level)을 최종 점수로 사용하고 있습니다.

Practice (by lm-eval-harness)

지금까지 ifeval의 데이터 셋 구성과 평가 매트릭을 살펴봤습니다. 마지막으로, 모델의 ifeval 성능을 실제로 어떻게 확인할 수 있는지 간단한 실습을 해보겠습니다. 물론, 논문대로 스크래치부터 구현할 수도 있지만, 다양한 모델과 데이터 셋 별로 매번 짜기는 번거로운 부분이 있습니다. 그래서 이러한 평가를 자동화해주는 툴로 가장 많이 활용되는 lm-eval-harness에서 ifeval을 돌려보겠습니다. (이후의 평가 관련 실습에도 해당 툴을 계속 이용할 예정입니다)

먼저 lm-eval-harness를 github를 통해 필요한 라이브러리를 설치해줍니다. 자세한 코드, README가 궁금하시면 아래 링크를 참고하시면 됩니다.

pip install git+https://github.com/EleutherAI/lm-evaluation-harness.git

https://github.com/EleutherAI/lm-evaluation-harness

설치가 정상적으로 되었다면, 아래의 명령어로 원하는 모델의 ifeval 성능을 확인할 수 있습니다.

lm_eval --model hf\
    --model_args pretrained={MODEL_NAME} \
    --tasks ifeval \
    --batch_size {BS} \
    --output_path {OUTPUT-PATH-FOR-RESULT} \
    --log_samples

평가하고 싶은 모델 이름에 {MODEL_NAME}을, 각자 환경에 맞는 batch size를 {BS}에 (몇으로 돌리실지 모르신다면, auto로 돌리시면 됩니다, 대신 시간이 오래걸립니다), 마지막의 output_path와 log_sampled은 자세한 평가 결과가 json 파일로 따로 저장될 수 있게하는 코드로 추후 디버깅에 유용합니다(추천 argument). 이 외에 argument는 아래 링크를 참고해서 사용을 원하면 추가해주시면 됩니다.

https://github.com/EleutherAI/lm-evaluation-harness/blob/main/docs/interface.md

평가가 끝나면, 다음과 같이 log에 점수가 나오게 됩니다. 위에서 소개한 총 네개의 매트릭의 결과가 출력되는 것을 확인할 수 있습니다.

References

paper: https://arxiv.org/abs/2311.07911
dataset: https://huggingface.co/datasets/google/IFEval

[백준] 12865번: 평범한 배낭 - 파이썬(Python)

계속지나가기 — Mon, 10 Jun 2024 20:02:46 +0900

https://www.acmicpc.net/problem/12865

해당 문제의 주어진 입력과 목표를 먼저 살펴봅시다.

1. 문제 입력 & 목표

해당 문제의 주어진 입력과 목표를 먼저 살펴봅시다.

문제 입력

N: 물품의 수 (1 ≤ N ≤ 100)
K: 버틸 수 있는 최대 무게 (1 ≤ K ≤ 100,000)
w,v : 물건의 무게, 물건의 가치 (1 ≤ W ≤ 100,000 / 0 ≤ V ≤ 1,000)

문제 목표

배낭이 버틸 수 있는 최대 무게인 K가 넘지 않는 선에서, 담을 수 있는 물건의 최대 가치를 구해라

2. 접근 방식

문제의 첫 번째 예제를 시각화하면 다음과 같습니다.

편의상 물건의 인덱스를 1부터 시작한다고 할 때,

왼쪽의 배열은 i번째 물건의 무게(w), 가치(v)이며, 오른쪽은 최대 배낭이 버틸 수 있는 무게인 7kg입니다.

이를 다음과 같이, 최대 i번째 물건, j무게까지 담을 수 있을 때의 최대 가치를 이차원 배열(arr)을 통해 표현해봅시다.

먼저, 첫 번째 물건만 담을 수 있다고 할 때 다음과 같이 값을 저장할 수 있습니다.

첫 번째 물건의 무게는 6kg로, arr[1][0]~arr[1][5] 는 물건을 담을 수 없어 최대가치가 0, arr[1][6]~arr[1][7] 부터는 물건을 담을 수 있으므로 첫 번째 물건의 가치인 13이 저장됩니다.

다음으로, 최대 두 번째 물건을 담을 수 있다고 했을 때는 arr[2][0]~arr[2][3] 까지는 0, arr[2][4] 부터는 두 번째 물건을 담을 수 있으므로 두 번째 물건의 가치인 8이 저장됩니다.

최대 6kg까지 배낭에 담을 수 있을 때는, 첫 번째 물건과 두 번째 물건 중 하나만을 선택해 담을 수 있으므로 두 물건의 가치를 비교해서 더 큰 가치를 가진 물건을 넣어주면 됩니다. 첫 번째 물건의 가치가 13으로 더 크므로, arr[2][6]~arr[2][7]는 13을 저장해줍니다.

이와 같은 방식으로, 최대 세 번째 물건을 담을 수 있다고 했을 때, 다음과 같이 값을 저장할 수 있습니다.

하지만, 최대 7kg까지 담을 수 있을 때 최대 가치는 첫 번째 물건을 하나만 담는 것이 아닌, 두 번째 물건과 세 번째 물건을 함께 담았을 때 입니다. 이는 현재 담을 수 있는 최대 무게인 7에서 세 번째 물건의 무게인 3을 뺐을 때의 최대가치와 세 번째 물건의 가치를 더한 값으로 구할 수 있습니다.

네 번째 물건까지 담을 수 있을 때를 모두 계산한 결과는 다음과 같습니다.

문제의 정답은 최대 네 번째 물건을 담을 수 있고 최대 7kg 무게까지 담을 수 있을 때의 최대 가치가 저장된 arr[4][7] 에 해당됩니다.

2.1) 2차원 DP로 풀어보기

위에서 전개한 내용을 2차원 DP로 풀어보도록 하겠습니다.

dp[i][j]에 저장되는 값은 최대 i번째 물건을 사용하여 최대 j무게까지 담을 수 있을 때의 최대 가치입니다.

wv = [(0,0)]
for i in range(1, N+1):
    w, v = map(int, input().split())
    wv.append((w,v))

dp = [[0]*(K+1) for _ in range(N+1)]

for i in range(1, N+1):
    w, v = wv[i]
    for k in range(1, K+1):
        if k >= w: # 현재 무게가, k 보다 작거나 같을 때
            dp[i][k] = max(dp[i-1][k], dp[i][k-1], dp[i-1][k-w] + v)
        else: # 현재 무게가, k 보다 클 때
            dp[i][k] = max(dp[i-1][k], dp[i][k-1])

print(dp[N][K])

2.2) 1차원 DP로 풀어보기

위의 코드보다 더 적은 메모리, 시간을 사용하고 싶다면 1차원 DP로도 풀이가 가능합니다.

매 반복마다 tmp = dp.copy()를 해두어 이전 물건들 값의 최대가치를 참고할 수 있게 코드를 수정해줍니다.

N, K = map(int, input().split())
wv = []
for _ in range(N):
    w, v = map(int, input().split())
    wv.append((w, v))

dp = [0] * (K+1)
ans = 0
for w, v in wv:
    tmp = dp.copy()
    for k in range(K+1):
        if dp[k] and k + w <= K and dp[k+w] < tmp[k] + v:
            dp[k+w] = tmp[k] + v
    if w <= K:
        dp[w] = max(dp[w], v)

print(max(dp))