스토리 전처리부터 소재 제작까지의 전체 흐름
스토리 전처리의 데이터 흐름
큰 흐름은 다음과 같다. 1. 운영 DB를 미러링한 BigQuery에서 광고 후보 스토리를 가져온다. 2. 삭제·비공개·차단된 스토리와 광고 대상에서 제외할 콘텐츠를 걸러낸다. 3. 스토리와 이미지 데이터를 정리하고 소구점 전략을 저장한다. 4. 같은 전략을 입력으로 이미지, 모션, 롱폼, 플레이어블 등의 소재를 만든다. 5. 규격별 결과물을 저장하고 검수·업로드 흐름으로 넘긴다. 여기서 공통 입력을 잘 만드는 게 중요했다. 형식마다 세계관과 소구점을 다시 해석하게 하면 같은 스토리인데도 광고가 서로 다른 이야기를 할 수 있다. 그래서 훅, 타깃 감정, 소구점, CTA 방향 등을 `strategy_json`으로 저장해 후속 제작에서 재사용했다. 기존에 다른 팀에서 만들어 둔 스토리 요약과 추천용 태그도 활용했다. 처음부터 모든 정보를 새로 만들 필요는 없었다. 이미 있는 데이터가 광고 제작에서는 어떤 역할을 할 수 있는지 찾고, 없는 정보는 어떻게 처리할지를 정하는 일이 전처리의 상당 부분이었다. ## 생성 버튼 뒤에 있어야 하는 것들 실제 운영 화면은 세 서비스의 소재를 통합해서 생성할 수 있게 구성했다. 목표 편집에서 형식별 비율과 소재 개수를 조정하고, 고급 설정에서는 장르 로테이션을 바꿀 수 있다. 운영자가 매번 내부 처리 순서를 이해해야 하는 방식보다는, 그날 필요한 제작량을 조정하고 결과를 확인할 수 있는 형태가 필요했다. 세 서비스의 통합 소재 생성 화면
형식별 생성 목표와 장르 로테이션 설정
애니메이션 티저의 플랜 생성 화면
스토리보드 플랜을 확인하는 과정
모든 형식을 같은 방식으로 처리하지는 않았다. 애니메이션 티저는 스토리를 선택해 먼저 스토리보드 플랜을 만들고, 플랜을 확인한 뒤 영상 생성 모델을 호출한다. 완성된 영상은 검수 탭에 노출하고, Drive에 올려 글로벌 마케터분들이 확인할 수 있게 했다. 비싼 영상 생성 전에 수정할 수 있는 단계를 두는 편이 운영에도 맞았다. 배너 한 장을 만드는 중에도 실패할 수 있는 지점이 여럿 있었다. 원본 이미지 URL이 죽어 있거나, 생성 모델이 정책상 차단하거나, 얼굴을 못 찾아 규격 변경 때 캐릭터가 잘릴 수 있다. 실제로 클릭했을 때 원본 스토리가 살아 있는지도 확인해야 한다. 제작 당시에는 공개 상태였는데 이후 제작자가 내리거나 차단되는 경우가 있었기 때문이다. 이런 문제들은 모델 호출 하나만 잘해서 해결되지는 않았다. ## 제작량 이후의 일 후반에는 만드는 형식을 늘리는 작업과 함께, 안전성·IP 탐지, 이미지 검색, 해외 서비스 디자인, 위닝 소재 기반 후보 발굴도 고도화했다. 처음에는 소재를 만들 수 있게 하는 일이 중심이었다면, 운영을 시작한 뒤에는 어떤 소재를 만들지, 만들면 안 되는 것은 무엇인지, 실패한 결과를 어떻게 다시 처리할지가 더 구체적인 문제가 됐다. 마케터분들의 가설과 디자이너분들의 레퍼런스도 계속 입력으로 들어왔다. 나는 그 판단을 생성 규칙과 데이터 흐름으로 옮겼다. 장르별 디자인을 맞추거나 위닝 소재를 재활용할 때도, 어떤 정보를 시스템에 남겨야 다음 제작에서 반복해서 쓸 수 있을지 고민했다. 이후 글에서는 이 흐름을 이루는 작업들을 나눠서 기록하려고 한다. 데이터가 광고 기획으로 바뀌는 과정부터 시작해서, 이미지 검색과 생성, 필터링, 해외 확장, 성과를 예측하려던 실험까지. 각각을 구현하면서 선택했던 방법과 실제로 잘 안 됐던 지점을 함께 남기려고 한다. ### 스토리 데이터를 광고 소구점으로 바꾸는 파이프라인 - Canonical URL: https://hyejunl33.github.io/projects/2026-10-12-wrtn-02-story-preprocessing/ - Collection: Project - Published: 2026-10-12 - Tags: Project 캐릭터챗 스토리를 광고로 만들려면 제목과 이미지를 가져오는 것만으로는 부족했다. 같은 로맨스 장르라도 유저가 끌리는 이유는 다르다. 소꿉친구의 철벽을 무너뜨리는 스토리와 계약 관계에서 시작하는 스토리를 모두 '설레는 로맨스'라고 표현하면, 각각의 스토리를 광고하는 의미가 줄어든다. 그래서 먼저 스토리마다 어떤 설정과 관계가 매력인지 정리하고, 그걸 광고 카피와 이미지 선택에 공통으로 쓸 수 있도록 전처리했다. ## 이미 있던 데이터부터 활용했다 스토리 데이터는 운영 DB를 미러링한 BigQuery에서 가져왔다. 광고 후보의 자격 조건과 장르별 랭킹을 적용한 다음 제목, 소개, 시작 상황, 프로필과 상황 이미지, 댓글 등을 읽었다. ```plaintext - 제목: 우주 - 장르: BL - 공개 태그: 연애, 여성향, 로맨스, 철벽, 내가, 짝사랑, 하는, 소꿉친구, 꼬시기 - 타겟: female - 챗타입: rolePlaying ``` | 테이블 | 여기서 뽑는 것 | 소재에서 쓰이는 곳 | | --- | --- | --- | | stories | 제목 · 소개 · 장르 · 타겟성별 · 좋아요수 · 성인여부 · 오리지널 여부 · 프로필 이미지 | 모든 형식의 기본 메타 | | story_starting_sets | 시작 상황 프롬프트 · 상황 이미지 · 첫 메시지 · 키워드북 · 엔딩 · 플레이 가이드 | 배너 이미지 · 롱폼 대본 · Anime 레퍼런스 | | character_comments | 좋아요순 상위 50개 댓글 | 소구점 도출의 보조 신호 | | profiles · genres | 작가 닉네임 · 장르 매핑 | 제작자 차단 · 장르 슬롯 | 입력 중에서 특히 활용하기 좋았던 것은 스토리 추천을 위해 미리 만들어 둔 세계관·줄거리와 11축 장르 태그였다. AI Engineer Kevin이 전처리해 둔 추천용 데이터였는데, 광고에서 스토리의 매력을 해석하는 데도 쓸 수 있었다. 관계 성향, 캐릭터 속성, 관계 동학, 분위기 등이 있으니 단순 장르보다 구체적으로 이야기를 읽을 수 있었다. ```plaintext tag_relationship_orientation BL tag_content_orientation 여성향 tag_world_setting 현대/일상, 학교/아카데미 tag_theme 로맨스, 청춘 tag_conversation_type 1:1 롤플레잉 tag_character_attribute 다정, 능글, 집착형 tag_relationship_dynamic 친분 기반, 짝사랑 tag_mood 청량, 설렘, 애잔 tag_subject_matter tag_species tag_power_dynamic ``` 세계관은 정제 후 길이를 제한해 넣었고, 비어 있으면 요약으로 대체했다. 모든 스토리에 같은 양과 품질의 정보가 있는 건 아니라서, 일부 필드가 비어 있어도 소구점을 만들 수 있는 입력 구조가 필요했다. ```plaintext ### 세계관 2025년 현대 대한민국을 배경으로 하며, 주된 무대는 한국대학교 캠퍼스와 그 주변 일대이다. 주인공들이 속한 대학에는 실용음악과 학생들로 구성된 '타임리스(Timeless)'라는 밴드부가 활발히 활동하고 있다. ... 두 주인공이 어린 시절부터 함께 뛰어놀던 동네 놀이터는 지금도 힘들거나 지칠 때 무의식적으로 찾아가는 둘만의 안식처이자, 향후 감정적 충돌과 화해가 일어나는 특별한 상징적 공간으로 기능한다. ### 숨겨진 설정 ...10%의 확률로 이성의 갑작스러운 고백이나 대학교 전체 MT 같은 새로운 서사적 분기점이 무작위로 발생할 수 있다. 우 주는 유저가 거짓말할 때 시선을 피하는 사소한 버릇까지 알아차린다. ``` | 항목 | 내용 | | --- | --- | | 스토리 정보 | title · genre_category (없으면 genre) · tags (공개 태그) · internal_tags (운영 태그) · target · chat_type | | 장르 태그 11축 | stories.tag_\* 열한 개 — tag_relationship_orientation (관계성향) · tag_content_orientation (콘텐츠성향) · tag_world_setting (세계관) · tag_theme (테마) · tag_subject_matter (소재) · tag_conversation_type (대화유형) · tag_character_attribute (캐릭터속성) · tag_relationship_dynamic (관계동학) · tag_mood (무드) · tag_species (종족) · tag_power_dynamic (권력관계) | | 세계관·줄거리 | world_settings 를 정제해 1,500자로 컷해 쓰고, 비어 있으면 content_summary 로 대체 | | 댓글 | comments\[\].content — 좋아요순 상위. 보조 신호일 뿐이라 별도 블록으로 붙이고, 없으면 "(댓글 없음 — 세계관·태그 기반으로 소구점 도출)"이라고 명시해 넣는다 | ## 댓글은 유용했지만, 그대로 믿을 수는 없었다 댓글은 유저가 어디에 반응했는지 직접 볼 수 있는 정보였다. 반복되는 키워드나 특정 캐릭터의 집착, 질투, 몰입을 표현한 반응은 스토리의 매력을 잡는 데 도움이 됐다. 다만 댓글이 많다고 모두 광고 기획에 쓸 만한 건 아니었다. 제작자의 공지나 유저노트 안내도 댓글에 섞여 있었다. ```plaintext - "💙등장 캐릭터 프로필" - "💙유저노트 TIP은 대댓확인 🆙!단축어 /커뮤니티 업데이트 …" - "헉 고백 받아내기 굿!! 전 매번 제가 고백합니다.. 😭😭" → 앞 두 개는 제작자 공지·안내라 소구점과 무관한 '뻘글'이다. 프롬프트가 댓글을 보조 신호로만 쓰라고 못박아 둔 이유가 이것이다. ``` 약 3만 개의 스토리를 전처리해야 했기 때문에 입력 비용도 고려했다. 이모티콘과 반복되는 자모, 여러 공백, 의미 없는 문자열을 정리했고 긴 댓글은 500자 이후를 잘랐다. 이모티콘에도 감정 정보가 있지만, 당시에는 토큰을 줄이는 쪽을 선택했다. 댓글의 역할은 보조 신호로 제한했다. 댓글이 없거나 적은 스토리에서도 세계관과 캐릭터 설정만으로 소구점을 만들 수 있어야 했다. 공지성 댓글 하나에 기획이 끌려가면 오히려 입력을 더 넣은 것이 문제가 된다. 프롬프트에도 댓글을 참고하되 과의존하지 말라고 명시했다. ## 스토리의 매력을 광고 카피로 옮기기 프롬프트에는 세 단계로 분석하도록 순서를 정했다. 먼저 세계관·태그·댓글에서 매료 포인트를 찾고, 그 매력이 왜 지금 이 스토리를 플레이하고 싶은 이유가 되는지 해석한 뒤, 앞의 분석에 연결된 결과를 만들게 했다. '흥미진진하다', '매력적이다', '몰입감이 있다' 같은 말은 거의 모든 스토리에 붙일 수 있었다. 그런 표현을 막고, 캐릭터가 실제로 하는 행동이나 관계의 긴장이 드러나게 하려고 했다. 소구점 세 개도 같은 내용을 바꿔 말하기보다는 캐릭터성, 관계성, 상황·전개처럼 다른 측면을 담도록 했다. ```plaintext 너는 모바일 앱 퍼포먼스 마케팅 전략가야. 크랙 앱의 캐릭터챗 콘텐츠를 타겟(여성향/남성향, 장르별 서브컬처)에 맞춰 광고 소재화하는 전문가야. 소구점은 스토리의 세계관·줄거리·장르 태그(11축)·유저 댓글을 종합해서 도출해 — 어느 한 신호에도 과의존하지 마. 특히 댓글은 '있으면 참고'하는 보조 신호일 뿐이야: 댓글이 없거나, 수가 적거나, 뻘글(무의미한 반응)만 있는 스토리가 많기 때문에, 댓글이 빈약하면 세계관·장르 컨벤션·캐릭터 설정·태그만으로 충분히 소구점을 도출하고 뻘글에 휘둘리지 마. 추상어·일반론 금지. 구체적인 캐릭터성·관계성·장면이 드러나야 해. CTR과 전환율을 높이는 것이 최우선 목표야. [분석 지시 — 반드시 이 순서로 사고할 것] Step 1. 매료 포인트 분석 (세계관·태그·댓글 종합): ... 유저 댓글이 있으면 보조 근거로 참고하되(반복 키워드·집착/몰입 표현 등), 댓글이 없거나 빈약해도 세계관·장르 컨벤션·캐릭터 설정만으로 매료 포인트를 잡아. 댓글에 과의존하거나 뻘글에 휘둘리지 마. Step 2. 소구 코어 정의: Step 1에서 뽑은 매료 포인트를 "이 스토리를 지금 당장 플레이하고 싶게 만드는 이유"로 번역해. 장르 컨벤션(멘헤라남·집착공·악역영애·계약결혼 등)이 명확하면 그 컨벤션의 어떤 변주/강도가 유저를 끌어당기는지 구체적으로. Step 3. 위 분석을 근거로 Output을 산출해. 일반론/추상어("흥미진진", "매력적", "몰입감") 금지. appeal_points: 소구점 3가지 (각 1문장). "사용자가 이 스토리를 실제로 플레이하고 싶어지는 이유"여야 함. 각 소구점은 서로 다른 축(캐릭터성/관계성/상황·전개/장르적 쾌감 등)을 다뤄야 하고, 가능한 경우 세계관·캐릭터·전개에서(및 있으면 댓글에서) 드러난 구체적 요소(캐릭터의 특정 행동·말투·집착 포인트 등)를 직접 반영할 것. 예: 멘헤라 남성향이면 "집착형 여주가 유저를 향해 무너지는 장면", "도망칠수록 더 깊어지는 소유욕" 같이 구체적으로. ``` 결과는 훅 포인트, 타깃 감정, 소구점, 시각 검색어, CTA 방향, 광고 본문 등을 가진 `strategy_json`으로 저장했다. 이 중 시각 검색어는 이미지 검색에서, 이상적인 폰트 샘플 문장은 폰트 선택에서 쓴다. 광고 기획을 사람이 읽는 문장으로만 끝내지 않고 다음 제작 단계가 사용할 수 있는 필드로 나눈 셈이다. | 항목 | 내용 | | --- | --- | | hook_point | 3초 안에 클릭하게 만들 후킹 한 문장 | | target_emotion | 자극하는 핵심 감정 — 설렘·질투·독점욕·구원욕구·서열역전쾌감처럼 구체적으로 | | appeal_points | 소구점 3개. 각 1문장이고 서로 다른 축이어야 한다 — 캐릭터성 / 관계성 / 상황·전개 / 장르적 쾌감. `strategy_json.appeal_points` 로 저장 | | hyde_visual_query | 그림 찾을 영어 시각 토큰 12~16개. 이게 이미지 선택의 검색어가 된다 | | cta_direction | 소구점 중 가장 강한 것을 행동으로 전환 | | ad_description | 매체별 광고 본문. | ```plaintext hook_point: 절대 선을 넘지 않는 완벽한 소꿉친구가 다른 남자 옆에 선 나를 보고 무너져 내렸다. target_emotion: 애가 타는 짝사랑의 아슬아슬함과 견고한 철벽을 무너뜨릴 때의 짜릿한 정복감 appeal_points: ① 절대 연애 감정을 주지 않으려 발버둥 치는 소꿉친구의 필사적인 철벽 ② 거짓말할 때 시선을 피하는 내 사소한 버릇까지 모두 꿰뚫어 보는 은밀한 집착 ③ 다른 밴드부원을 꼬셔서 그의 숨겨진 질투와 독점욕을 폭발시키는 아슬아슬한 밀당 hyde_visual_query: 1boy, handsome, blonde hair, yellow eyes, looking at viewer, intense expression, subtle jealousy, upper body, dramatic lighting, blurred background, masterpiece, best quality, anime illustration cta_direction: 다른 남자를 향한 질투심을 자극해 그의 철벽을 부수고 고백을 받아내세요 tiktok_body: 평생 친구라며 선 긋던 소꿉친구가 다른 남자와 웃는 내 모습에 이성을 잃고 질투하기 시작했다. ideal_font_sample_text: 팽팽한 긴장감 속에서 터져 나오는 질투를 담아낸 날렵하고 세련된 서체 ``` ```plaintext 검색용 소구점 텍스트 (AGENTS/APPEAL_EMBEDDER.PY · FORMAT_APPEAL_TEXT) [제목] {스토리 제목} [장르] {장르} [핵심감정] {target_emotion} [후킹] {hook_point} [소구점1] {appeal_points[0]} [소구점2] {appeal_points[1]} [소구점3] {appeal_points[2]} ``` 한 번 저장한 소구점을 배너 카피, 모션 연출, 위닝 검색에서 함께 사용했다. 이후 형식이 늘어날 때도 각 생성 경로가 스토리의 매력을 새로 정의하는 대신, 공통 기획을 받아 자기 형식에 맞게 표현하도록 했다. 나중에 위닝 소재와 비슷한 후보를 찾을 때는 스토리 정보 자체를 텍스트로 임베딩하기도 했고, 전처리해 둔 후킹 포인트와 소구점을 임베딩해서 사용하기도 했다. 위의 검색용 텍스트처럼 제목·장르·핵심 감정·후킹 문장·소구점을 묶어 두면, 스토리의 설정뿐 아니라 광고에서 강조할 매력을 기준으로도 후보를 찾을 수 있었다. 이 텍스트 임베딩은 성과가 났던 소재와 유사한 스토리·소재를 찾는 hybrid search에 활용했다. ## 이미지 URL도 그냥 한 필드에 있지 않았다 스토리마다 이미지를 저장해 둔 위치가 달랐다. 상황 이미지가 situation_images 같은 필드에 모여 있는 스토리도 있었지만, initial_images나 keyword_book 등 여러 필드에 이미지 주소가 흩어져 있는 경우도 있었다. 광고 제작에서 쓸 이미지를 놓치지 않으려면 한 필드만 읽는 것으로는 부족했다. 정규 이미지 목록은 URL·키워드·상황 정보로 형태를 맞췄다. 시작 세트가 여러 개면 각 세트의 이미지를 모두 펼쳐 합치고, 프로필 이미지도 함께 모았다. 본문에서는 system_prompt_variables, keyword_book, initial_messages, ending에 들어 있는 이미지 URL을 추출했다. 이렇게 서로 다른 필드에서 찾은 주소를 이미지 자산으로 정리하고, 이미지 한 장을 한 행으로 저장했다. 본문에 완성된 URL이 있으면 정규식으로 수집했다. 마크다운 이미지 선언은 링크 뒤의 문장까지 삼키지 않게 괄호의 깊이를 확인했고, GitHub blob 링크는 이미지 원본을 받을 수 있는 raw 주소로 바꿨다. URL 양식과 변수 값이 따로 적혀 있는 경우에는 LLM이 명시된 양식과 값만 조합해 완성된 주소를 만들도록 했다. 변수가 덜 채워진 URL은 제외했다. ```yaml AGENTS/LLM_IMAGE_EXTRACTOR.PY · 배치 프롬프트(발췌) 당신은 캐릭터 챗봇의 system_prompt_variables 필드에서 외부이미지 URL 을 추출 각 raw 는 종종 다음 패턴을 포함합니다: - 자연어/JSON 으로 외부이미지 URL 양식이 서술됨 (예: "이미지는 https://example.com/{캐릭터}_{상황}.png 형식") - {캐릭터}, {상황}, {이미지코드} 같은 placeholder 변수의 실제 값들이 같은 raw 안에 함께 정의됨 작업: 1. 양식(템플릿 URL) 식별 2. placeholder 의 실제 값 식별 3. 양식 × 모든 가능한 값 조합으로 완성된 URL 들을 만들어 반환 4. raw 안에 이미 완성된 https URL 이 있으면 그것도 그대로 포함 규칙: - placeholder 가 채워지지 않은 ({...} 가 남아있는) URL 은 절대 포함하지 말 것 - URL 이 완전히 없으면 빈 리스트 반환 - 추측하지 말 것 — raw 에 명시된 양식과 명시된 값들로만 조합 - 모든 입력 스토리에 대해 results 배열에 1개씩 응답 (story_id 정확히 매칭) - 코드펜스 / 설명 / 주석 없이 순수 JSON 만 반환 ``` 이미지 자산에는 출처와 URL뿐 아니라 내려받기 성공 여부, CLIP 점수, 임베딩, 후속 아웃페인팅 결과와 얼굴 좌표가 이어서 붙는다. URL 접근에 실패한 경우도 기록을 남겼다. 생성에서는 성공한 자산만 쓰더라도, 나중에 왜 특정 이미지가 빠졌는지 확인할 수 있어야 했다.| stories | 제목·세계관·줄거리·11축 태그·장르·타겟. |
| image_assets | 이미지 1장 = 1행. URL · 출처(situation/profile/external) · CLIP 점수 · fetch 성공여부 · 아웃페인트 결과 · 얼굴 좌표. |
| story_embeddings | 이미지 임베딩(512-dim). HyDE 쿼리와 내적해 "이 소구점에 어울리는 그림"을 고른다. |
| strategy_json | 소구점 전략 — 훅 포인트 · 소구점 N개 · HyDE 비주얼 쿼리 · 광고 설명문 · 틱톡 본문 · 이상적 폰트 샘플 문장. |
| comments | 좋아요순 상위 댓글. 소구점 도출 |
원본 데이터의 장르 분포
11축 태그로 재분류한 장르 분포
장르 분류에 활용한 태그 축
1. 관계성향(`relationship_orientation`)이 bl/gl이면 즉시 → bl / gl (최우선, 다른 축 무시). 2. 세계관(`world_setting`)에 "무협" → wuxia, "로판" 또는 (판타지 세계관 + 로맨스 테마 + 콘텐츠성향=여성향) → rofan. 3. 테마(`theme`)에 "스포츠" → sports. 4. 로맨스 신호(테마=로맨스 or 관계성향=hl)면 → 콘텐츠성향(`content_orientation`)으로 남성향→romance-m, 여성향→romance-f 가름. 5. 소재/대화유형(`subject_matter`, `conversation_type`)에 게임태그(시뮬·육성·키우기·타이쿤 등) → simul. 6. 세계관(`world_setting`)이 SF/판타지군(아포칼립스·이세계·가상현실 등) → sf-fantasy. 7. 테마(`theme`)가 추리/범죄/호러/스릴러 → mystery 8. 테마(`theme`)가 일상/힐링/드라마·일상대화 → daily 9. 그 외 → etc. 장르를 12종으로 확장한 뒤 기타 비중은 2.4%로 줄었다. 이 수치는 광고 성과가 오른 결과가 아니라, 원래 한 덩어리였던 후보를 타겟에 맞춰 구분할 수 있게 된 결과다. 이후 생성과 광고세트 구성에서 쓸 수 있는 데이터가 됐다는 점이 이 작업의 목적이었다. 전처리에서 만든 산출물은 눈에 보이는 광고보다 앞에 있지만, 뒤쪽 제작의 선택을 상당 부분 결정한다. 어느 댓글을 넣을지, 어떤 태그를 우선할지, 소구점을 어떤 필드로 남길지부터 정해 둬야 형식이 늘어나도 같은 스토리를 일관되게 광고할 수 있었다. ### 소구점에 맞는 이미지를 찾고 배너로 렌더링하기 - Canonical URL: https://hyejunl33.github.io/projects/2026-10-12-wrtn-03-image-retrieval-rendering/ - Collection: Project - Published: 2026-10-12 - Tags: Project 광고에 쓸 소구점을 만들고 나면 그 문장에 맞는 그림을 골라야 했다. 캐릭터챗에는 같은 캐릭터의 이미지가 여러 장 들어 있는데, 표정이나 구도가 조금씩 다르다. 어느 이미지든 캐릭터는 같지만, 질투를 강조하는 카피와 다정함을 강조하는 카피에 어울리는 장면은 같지 않을 수 있다. 그림을 고른 뒤에도 매체별 규격으로 바꾸고, 얼굴이 잘리지 않게 배치하고, 폰트와 카피를 얹는 과정이 남았다. 이 글에서는 이미지 후보를 정리하는 단계부터 실제 배너 파일로 렌더링하는 단계까지 이어서 정리한다. ## 배너에 못 쓰는 이미지부터 걸러냈다 수집한 이미지를 모두 검색 후보에 넣지는 않았다. 글자가 들어간 캡처, 실사, 풍경이나 도표, 캐릭터가 없는 이미지 등은 배너의 입력으로 적합하지 않았다. NSFW처럼 정해진 항목만 막는 필터로는 광고에서 쓸 만한 이미지를 충분히 구분하기 어려웠다. CLIP 계열 모델로 긍정·부정 프롬프트와의 유사도를 계산했다. 긍정 쪽에는 애니메이션 인물, 얼굴과 상반신, 감정적인 표정 등을 두고, 부정 쪽에는 자막·워터마크·말풍선, 노출, 풍경·UI, 실사·비인간 객체 등을 넣었다. CLIP 기반 이미지 필터링 흐름
이미지 점수 분포와 속성별 비교
필터링 점수별 이미지 사례
광고 후보에서 제외한 이미지 사례
```python POSITIVE_PROMPTS = { 'p_character': "anime human character, illustrated person, human figure", 'p_face': "anime character face, human upper body portrait, clear face", 'p_emotion': "dramatic emotional expression, intense human gaze, expressive face", } POS_WEIGHT = 5.0 # Positive 전체 가중치 (final score) # Negative 프롬프트 — 전체 x5 가중치 NEGATIVE_PROMPTS = { 'n_text': ( "subtitled anime screenshot, image with Korean text, " "dialogue text bar, caption overlay, watermark, speech bubble, " "white text on black bar, colored subtitle" ), 'n_nsfw': "nude, explicit, nsfw, undressed, sexually suggestive content", 'n_no_char': "landscape, scenery, map, diagram, screenshot, UI, no human character", 'n_panels': "manga panels, comic strip layout, multiple frames, panel borders", 'n_real': ( "real photograph, real person, real animal, photo portrait, " "live action, 3D render, photorealistic" ), 'n_object': ( "cute mascot, chibi animal, cartoon penguin, cartoon creature, " "food illustration, small icon, item sprite, object illustration, " "illustrated animal, non-human cartoon creature" ), } NEG_WEIGHT = 5.0 # Negative 전체 가중치 (final score) ``` 초기 실험의 점수는 `5 × positiveScoreMean - 5 × NegativeScoreMean` 형태였다. 두 항에 같은 가중치를 곱하면 순위 자체가 달라지는 것은 아니다. 점수의 크기와 임계값의 관계를 함께 봐야 한다. 뒤의 제작 흐름에는 단색 이미지와 흡연에 대한 별도 페널티도 들어갔다. 이미지 필터링 실험에서는 0.5를 기준으로 보수적으로 후보를 남겼다. 한편 전체 전처리 기록에는 양수 점수만 통과시키는 0 기준도 있다. 이 두 설정을 같은 실험 결과로 섞지는 않으려고 한다. 아래는 이미지 필터링과 선정 단계에서 남긴 자료다. 이미지 필터링 점수 분포
이미지 필터링에서 확인한 후보와 제외 사례
이미지 필터링에서 확인한 후보와 제외 사례
이미지 필터링에서 확인한 후보와 제외 사례
이미지 필터링에서 확인한 후보와 제외 사례
이미지 필터링에서 확인한 후보와 제외 사례
이미지 필터링에서 확인한 후보와 제외 사례
자동화에서는 잘못 남긴 이미지가 그대로 제작까지 갈 수 있어서, 쓸 수 있는 그림이 일부 빠지는 비용도 감수했다. 다만 모델 점수를 낮게 받았다는 사실만으로 그 이미지가 실제 광고에 부적합하다고 확정할 수는 없다. 필터가 무엇을 놓치고 무엇을 과하게 막는지 사례를 같이 확인해야 했다. 임베딩에는 `xlm-roberta-base-ViT-B-32`를 사용했다. 처음에는 한국 서비스인 크랙에서 개발했지만, 북미 OOC와 일본 캬라푸로 확장할 계획이 있었다. 처음부터 다국어 텍스트 인코더를 고려한 이유다. 이미지를 내려받지 못한 경우는 `fetch_status='failed'`로 남기고 생성 조회에서는 성공한 자산만 사용했다. ## 소구점을 그대로 검색하면 잘 맞지 않았다 소구점은 사람의 감정이나 관계를 설명하는 문장이다. '은밀한 집착' 같은 표현을 이미지 검색에 바로 넣으면 눈에 보이는 장면으로 대응하기 어렵다. 이런 추상적인 쿼리를 썼을 때 이미지들과의 코사인 유사도가 낮고, 상위 후보들 사이의 점수 차이도 작았다. 그래서 HyDE 시각 쿼리를 영어 단어 형태로 바꿨다. 머리색, 눈 색, 구도, 표정, 조명처럼 그림에서 확인할 수 있는 특징을 토큰으로 만들었다. 전처리의 소구점 JSON에 이 쿼리를 저장하고, 제작 단계에서는 이미지 벡터와 비교해 후보를 고른다. 시각 쿼리와 이미지 후보를 CLIP 공간에서 비교해 선택하는 흐름
소구점 시각 쿼리로 검색한 이미지 후보
쿼리별 이미지 검색 결과 비교
단어형 쿼리의 점수와 후보 간 gap 비교
CLIP 논문의 프롬프트별 ImageNet 성능 비교 — Radford et al., CLIP
CLIP 논문의 프롬프트 템플릿에 대한 설명 — Radford et al., CLIP
단어형 쿼리에서 코사인 점수와 Top1-Top2 gap이 커지는 경향은 있었다. 그렇지만 기대했던 만큼 크게 개선되지는 않았다. 이미지 에셋이 서로 다른 사물 사진처럼 다양하지 않고, 대부분 같은 캐릭터의 구도 차이였기 때문이라고 추정했다. 점수가 올랐다고 실제로 더 적절한 그림을 골랐다고 단정할 수는 없다. 검색 결과를 눈으로 같이 봐야 했다. 프롬프트를 바꾸는 것만으로 해결할 수 있는 범위가 어느 정도인지 확인한 실험이었다. 소구점마다 CLIP top-1 이미지를 선택하되, 앞의 소구점에서 이미 쓴 그림은 누적해서 제외했다. 서로 다른 카피를 만들었는데 같은 그림만 반복해서 나오는 것도 줄여야 했다. ## 선택한 그림을 실제 파일로 만들기 이미지 배너 렌더링에는 여러 단계가 들어갔다. 원본에 박힌 글자를 제거하고, 필요한 효과를 넣고, 세로 이미지를 가로 캔버스로 확장한다. 그런 다음 얼굴을 찾고, 카피·폰트·색상·그림을 렌더 상태로 조립한다. 이미지 배너 제작 파이프라인
| # | 단계 | 무엇을 하나 | 산출·캐시 | | --- | --- | --- | --- | | ① | 오버레이 텍스트 제거 | 원본 그림에 박힌 글자를 FLUX Kontext로 지운다 | overlay_clean_{hash}.png · 실패는 원본으로 조용히 진행 | | ② | 임팩트 이펙트 (캬라푸) | 일본향 배너용 효과 선처리 | kyarapu_fx_pre_{hash}.png | | ③ | 가로 아웃페인팅 | 세로 그림을 4000×2000 캔버스로 확장 — 가로 배너 규격을 위해 | outpaint_v2_…_{hash}.png · DB에 캐시 | | ④ | 얼굴 검출 | 확장된 이미지에서 얼굴 좌표 검출 | image_assets.face | | ⑤ | state 조립 | 카피·폰트·색·이미지를 렌더러가 먹는 하나의 상태 객체로 | render state | | ⑥ | 캡처 | Chromium 하나 + 영속 컨텍스트 N개로 HTML을 2× 슈퍼샘플 캡처 | 1080×1920 원본 + 프리셋별 PNG | | ⑦ | 후처리 | 정확한 해상도로 다운샘플 + 500KB 이하로 압축 | {prefix}_{preset}.jpg | HTML을 Chromium으로 캡처한 뒤 매체별 해상도로 줄이고 파일 용량도 맞췄다. 같은 원본에 같은 처리를 반복하지 않도록 오버레이 제거와 아웃페인팅 결과는 캐시했다. 텍스트 제거에 실패하면 원본으로 진행하는 단계가 있는 반면, 아예 결과를 버려야 하는 생성 경로도 있다. 모든 실패에 똑같은 재시도 규칙을 쓰지는 않았다. ## 얼굴 검출 모델도 도메인을 맞춰야 했다 사이즈 베리에이션 로직은 얼굴 좌표를 기준으로 배치했다. 그래서 얼굴을 못 찾거나 엉뚱한 위치를 찾으면 가로·정사각 배너에서 캐릭터가 잘렸다. 실사 얼굴에 맞춰진 BlazeFace를 쓰다가, 애니메이션 도메인으로 학습한 YOLOv8 nano 기반 모델로 바꿨다. | 모델명 | BlazeFace | face_detect_v0_n(YOLOv8 nano) | | --- | --- | --- | | 학습 도메인 | 실사 인물 사진 (Google open dataset) | Anime 일러스트 | | 파라미터수 | 110k | 3.01M | | 모델 사이즈 | ~250KB | 12.1MB | 얼굴 좌표를 활용한 세로 배너
얼굴 기준의 규격별 배너 베리에이션
다른 이미지에 적용한 얼굴 기준 배치
규격 변경 후 캐릭터 배치 사례
교체 후 얼굴 인식과 배너 오류 사례가 개선됐다. 모델의 크기는 더 커졌지만, 우리가 입력으로 넣는 그림은 실사 얼굴이 아니라 애니메이션 캐릭터였다. 이 작업에서는 그 도메인에 맞는 검출 결과가 후속 배치의 기준이 된다. 모델이 가볍다는 장점만 보고 선택할 수는 없었다. ## 폰트도 검색 대상으로 만들었다 디자이너분이 전달해 주신 폰트들을 임베딩하고, 작품의 장르와 소구점에 맞는 폰트를 벡터 검색으로 고르는 흐름을 만들었다. 같은 카피라도 어떤 폰트를 쓰느냐에 따라 분위기가 다르기 때문이다. 생성 단계에서 저장한 이상적인 폰트 샘플 문장도 이 선택에 연결했다. 폰트 선택 파이프라인
폰트 임베딩의 장르별 분포
임베딩을 보면 장르별로 폰트가 어느 정도 군집을 이뤘다. 같은 장르 안에서는 비슷한 폰트를 고를 수도 있겠다는 생각이 들었지만, 군집이 나뉘는 것과 실제 배너에서 잘 읽히는 것은 따로 봐야 했다. 플레이그라운드에서 기존 광고와 비교하고 정성적인 피드백을 반영하는 방향으로 고도화했다. 이미지 검색, 얼굴 검출, 폰트 선택은 각각 다른 모델의 결과지만 마지막에는 배너 한 장에서 만난다. 중간 점수가 좋아도 얼굴이 잘리거나 카피가 읽히지 않으면 쓸 수 없다. 그래서 개별 단계의 점수와 완성된 배너의 오류 사례를 함께 보면서 바꿔 나갔다. 본문의 데이터 흐름 애니메이션은 3Blue1Brown의 오픈소스 [Manim](https://github.com/3b1b/manim)에서 출발한 [Manim Community](https://www.manim.community/)로 만들었다. ### 하나의 스토리에서 이미지·영상·플레이어블 광고 만들기 - Canonical URL: https://hyejunl33.github.io/projects/2026-10-12-wrtn-04-creative-generation/ - Collection: Project - Published: 2026-10-12 - Tags: Project 스토리의 소구점과 이미지 자산을 정리한 뒤에는 표현할 수 있는 형식을 늘렸다. 정적 배너에 카피를 얹는 것부터 시작했지만, 같은 스토리를 짧은 모션 영상으로 보여줄 수도 있고, 읽히는 롱폼이나 직접 선택하는 플레이어블로 만들 수도 있었다. 형식이 늘어날수록 모든 것을 생성 모델에 한 번에 맡기기는 어려웠다. 어떤 단계는 모델이 기획하고, 어떤 단계는 코드가 결정적으로 조립하며, 비용이 큰 생성 앞에는 사람이 확인하는 지점을 두는 식으로 경로를 나눴다. ## 공통 기획과 형식별 제작 공통 입력은 스토리 정보, `strategy_json`, 이미지 자산이었다. 이 중 훅 포인트와 타깃 감정, 소구점, CTA 방향은 형식이 달라져도 유지한다. 정적 배너의 입력은 아래처럼 구성했다.| strategy_json | 소구점 N개 · 훅 포인트 · HyDE 비주얼 쿼리 · 이상적 폰트 샘플 문장. |
| image_assets | CLIP 통과 이미지 + 임베딩. 이미지 선택에 LLM은 쓰지 않는다 — Stage 2가 만든 HyDE 쿼리를 CLIP으로 임베딩해 이미지 벡터와 비교하고 가장 유사한 이미지를 고른다 (= CLIP top-1). 소구점마다 다른 그림이 뽑히도록 이미 쓴 이미지를 누적 제외한다. |
| 폰트 카탈로그 | 장르·소구점 임베딩으로 고른다. |
| 카피 폼 | 대사형 · 액션형 · 상황형 3폼. 언어별로 프롬프트 원본 파일이 따로 있고, 그 파일 하나가 유일한 기준이다. |
7초 모션 영상 제작 흐름
구간에는 인물 동작뿐 아니라 신체 역학, 지속되는 움직임, 표정, 카메라 워크, 효과음이 들어갔다. 이 구조화된 결과를 i2v 프롬프트로 펼치는 단계는 LLM을 다시 호출하지 않고 코드로 처리했다. 기획에서 이미 정해진 구간을 재해석할 필요가 없어서였다. ```yaml 정규화 장르 (13슬러그): {슬러그} 캐릭터 속성: {tag_character_attribute} 대표 대사: {simple_description} 줄거리: {content_summary} [소구점] 훅포인트 / 타깃 감정 / 어필 포인트 / CTA 방향 세계관(발췌, 1500字) ``` ```yaml scene_read: "Akari stands angled in a low-angle perspective against a blood moon in a red sky, wearing black lacquered armor plates over a dark outfit." scene_concept: "Under the blood moon, Akari shifts her grip on her katana with a cautious, resolute gaze down toward the viewer." audio_plan: "Howling high-altitude wind, distant rhythmic taiko drums, and the slide of a katana habaki locking inside its wooden scabbard." physics_notes: "The long black hair strands and thin crimson ribbon whip in the crosswinds while the rigid black armor plates stay firmly anchored." segments: - time_range: "0-1.5s" character_action: "Akari pivots her shoulders slightly toward the camera, thumb clicking the katana guard forward out of its scabbard by an inch." body_mechanics: "Starting in a three-quarters back stance, her core rotates 45 degrees toward the viewer while her right thumb levers the gold tsuba forward and her other hand steadies the scabbard." ``` ```plaintext [0-1.5s] {동작}; body mechanics: {신체 역학}; moving continuously through the entire segment; expression: {표정}; camera: {카메라}; sfx: {효과음}. [1.5-3.5s] ... [3.5-5s] ... [5-7s] ... Global camera direction: {전역 카메라 지시} One continuous take. Keep the character moving throughout the shot. No on-screen text, captions, subtitles, or watermarks. ``` 영상 입력에는 오버레이 제거본을 썼다. 예전에는 21:9로 확장한 이미지를 넣었는데, 세로 영상으로 cover-crop되면서 캐릭터가 잘려서 그 경로를 폐기했다. 9:16 영상은 한 번만 만들고 가로·정사각은 좌우를 채워 파생했다. 정책 차단이 발생하면 같은 프롬프트를 계속 고치기보다 다른 후보 이미지로 최대 네 장까지 시도했다. 오디오를 켰을 때 의도하지 않은 사람 음성이 나오면 발화 가드로 처리했다. 생성 모델의 결과가 요청한 조건과 완전히 같다고 가정할 수 없어서 후처리가 필요했다. ## 롱폼: 대본을 HTML 화면으로 구성하고 녹화하기 롱폼은 스토리를 읽히는 형식으로 재구성해 HTML 페이지를 만들고, 스크롤되는 화면을 녹화했다. 대본 모델에 세계관과 인물 정보를 주고 참고 이미지 여러 장도 함께 넣었다. 이미지는 중립적인 파일명으로 표시하고, 어떤 장면에 어떤 그림을 쓸지는 대본 안의 마커로 선택하게 했다. 롱폼 대본 생성과 HTML 화면 구성·녹화 흐름
```yaml [S] 장면 블록 - 상황 서술 [U] 유저(시청자) 발화 블록 N 나레이션 D 대사 H 하이라이트 P 사진 배치 예: P img_3.jpg ← 참고 이미지를 그 장면에 배치 · 첫 [S] 블록 = 후킹 정점 장면이고, 여기엔 P 이미지를 반드시 1장 넣는다 · 참고 이미지가 0장이면 P 마커를 절대 쓰지 않는다 · 라이브 채팅용 출력 포맷(**이름**|내용, 상태창)은 쓰지 않는다 ``` 첫 블록에는 후킹할 정점 장면과 이미지 한 장, 짧은 문장을 두었다. 릴스에서 시작하자마자 스크롤이 올라가는데 글이 길면 읽히지 않았다. 첫 블록 위치도 0.8에서 시작했을 때는 초반이 비었고, 0.0에서는 이미지와 글이 바로 잘려서 0.5로 정착했다. 대본에 '유저'라는 호칭이 남는 것도 어색했다. 첫 줄에 이름 메타 정보를 선언하게 하고, 남은 호칭은 후처리로 치환했다. 금칙어는 해당 줄만 다시 수선하고, 출력 언어가 다른 언어로 흐르면 실패로 처리했다. HTML 화면 구성과 녹화는 1080×1920에서 한 번 하고 다른 규격은 scale과 pad로 만들었다. 규격 하나가 실패했다고 모두 버리지 않고, 저장 가능한 결과는 남겼다. 긴 영상은 상한을 넘으면 트림하도록 했다. ## 플레이어블: 시나리오를 실행 가능한 조합으로 플레이어블은 클릭할 수 있는 미니게임 형태의 광고다. 스토리를 자체완결 HTML 하나로 만들기 위해, 스토리보드와 실제 시나리오 조합을 분리했다. 아래는 플레이어블 형식을 보여주는 Google의 공개 참고 예시다. 광고 안에서 직접 게임을 조작해 볼 수 있고, 화면에는 설치 버튼도 함께 뜬다. 우리가 만든 스토리 광고에서는 이 상호작용을 캐릭터의 대화와 선택지로 구성했다. 플레이어블 형식 참고 예시 — Google AdMob 공개 자료: Rewarded ads with playables
플레이어블의 기획·검증·HTML 조립 흐름
대표 이미지는 CLIP 상위 후보 다섯 장을 비전 LLM에 보여주고 하나를 고르게 했다. 캐릭터가 선명한지, 장르와 무드가 맞는지 보게 했고, 파싱 실패나 범위를 벗어난 선택에는 CLIP 1위로 돌아가는 대체 경로를 뒀다. Stage A에서 장면 흐름과 연출 방향을 만든 뒤 Stage B에서 조합 DSL로 바꾼다. 검증에 걸리면 같은 세션에서 멀티턴으로 수정했다. 채팅·선택·게이지·공개·CTA 등 준비된 요소를 조합하는 방식이라, 결과를 검증하고 렌더러에 넘길 수 있었다. ```yaml { theme, gauges[], steps[], branches{} } steps 프리미티브: chat · choice · burst · cta (v1) card_pick · gauge · stat_panel · reveal (확장) scratch · qte_tap · swipepick 게이지 스타일: danger · heart · qi · bar · suspicion 화면 형태(layout): chat · battle · raise · harem · investigate immersion · scratch · swipe ``` 최종 HTML에는 레이아웃과 게이지, 이펙트, 서비스 스킨을 함께 넣었다. 외부 자산 요청이 없어도 실행되게 만드는 것은 매체에 전달할 때의 조건이었다. ## UGC 리메이크: 훅을 만드는 방법이 네 번 바뀌었다 UGC(User Generated Content)는 유저나 크리에이터가 직접 만든 콘텐츠를 뜻한다. 사람이 카메라를 보며 서비스를 소개하거나 사용 화면에 반응하는 영상이 익숙한 예다. 아래는 틱톡에서 확인한 OOC 크리에이터 광고들이다. 틱톡에서 확인한 OOC 크리에이터 광고 예시 — OOC app 검색 화면
OOC에서는 이미 잘된 UGC의 대본과 화면 구성을 유지하면서, 화면 속 인물을 AI로 바꾸는 경로도 만들었다. 원본 영상의 단어별 타임스탬프를 뽑고 컷을 나눈 다음, 훅과 발화 컷을 별도로 생성했다. UGC 리메이크의 생성과 합성 흐름
컷 경계는 문장 경계로 맞췄다. 훅이 첫 문장의 앞토막만 말하면 이후 편집이 잘돼도 어색하기 때문이다. 훅은 원본 클립을 움직임과 구도의 레퍼런스로, 승인된 얼굴 이미지를 인물 레퍼런스로 넣는 r2v 방식으로 만들었다. 이 구간의 소리는 원본을 다시 합성했다. 발화 컷은 앵커와 대사를 넣어 음성이 포함된 영상으로 만들고, 전사 결과를 맞춰 앞뒤를 잘랐다. 인물 매팅 이후에는 얼굴 기준 크롭, 우하단 PIP, 자막, 엔딩 로고를 합성했다. 얼굴 갤러리는 인종·성별별 앵커를 미리 만들어 사람이 승인한 것만 사용했다. 공식 틱톡 계정의 리포스트는 리메이크 대기 큐로 활용했다. 훅 생성 방식은 완전 재현, 프레임 스왑+i2v, 스토리보드 기반 생성, r2v 단일 호출까지 바뀌었다. 실배치에서는 발화가 사라지거나, DB 락이 생기거나, 매팅 결과가 전부 실패하는 문제가 드러났다. 단위테스트가 통과해도 이 형식을 쓸 수 있다고 말하기 어려웠던 이유다. 실제 실패 사례를 확인한 뒤 그 조건이 다음 가드가 됐다. ## Anime teaser: 비싼 생성 전에 플랜을 확인했다 오리지널 스토리에서는 30초 애니메이션 티저를 만드는 흐름도 구현했다. 감독 단계에서 세계관과 소구점, 레퍼런스 이미지를 받아 컷과 샷, 캐스트, 대사를 계획한다. 후보 이미지 풀에서 선택한 이미지를 캐릭터·배경·소품으로 나눠 컷에 연결했다. 애니메이션 티저의 플랜·생성·합성 흐름
애니메이션 티저 생성 화면과 컷 계획
사람이 플랜을 확인한 다음 본편 영상 모델을 호출한다. 컷별 영상을 이어 붙이는 대신 컷 플랜과 캐스트를 넣어 본편을 한 번에 생성하는 경로였다. 실제 발화를 다시 전사해 자막 타이밍을 맞추고 서비스별 엔딩과 BGM을 합성했다. ```yaml shot_size: "medium" beat: "Chloe scrambles on the floor after spilling game pieces." motion: "Chloe hurriedly gathers scattered colorful plastic tokens off the floor, rushing back up toward the desk." action: "Chloe crouches low to scoop up dice from the linoleum floor, then moves back behind the wooden desk." scene: "Chloe crouches beside the cluster of desks in the sunset-lit classroom." line: speaker: "Chloe" from_source: true voice: "flustered and breathless, catching her voice in a panicked stammer" line: "Aah! S-sorry! My hand slipped! B-but... I will have everything picked up right away!" advances: "The spilled pieces are collected and placed back onto the playing surface on the desk." ``` | | 크랙 | OOC | | --- | --- | --- | | 대상 | IP 등록 오리지널만 | 공식계정 제작 레인 | | 프롬프트 | 한국어 별도 벌(번역 아님) | 영어 벌 | | 인트로 | 빨강 워드마크 + ORIGINAL 배지 | 로고 2.0초 | | 엔드카드 | 없음 | 섬네일 고정 2.5초 | | 아웃트로 | 세로 로고 애니 4.0초 | 로고 3.5초 | | 매체 | 메타 · 틱톡 · X | 틱톡 · X | 한국어와 영어는 발화량 기준도 달랐다. 영어 플랜을 한국어 기준으로 검사하면 발화 과다로 잘못 판단하는 경우가 생겼다. 원작에서 인용할 수 있는 대사가 있는 경우와 없는 경우도 나눴다. 소구점이 없으면 티저 생성은 실패로 처리했다. 무엇을 광고하는지 정해지지 않은 상태에서 영상부터 만드는 건 피하고 싶었다. 자막이나 BGM, 꼬리 부분만 잘못되면 저장된 중간 영상부터 합성 단계를 다시 실행했다. 본편 생성까지 다시 호출할 필요가 없게 만드는 것이 비용 면에서도 중요했다. 형식마다 모델과 검수 방식은 달랐지만, 입력과 산출물의 계약을 정하고 수정 가능한 중간본을 남기는 방향은 같았다. 생성 결과가 한 번에 잘 나오기를 기다리는 것보다, 어느 단계가 잘못됐는지 확인하고 그 부분만 다시 처리할 수 있어야 운영할 수 있었다. ### 광고 안전성 필터에서 과차단을 줄인 과정 - Canonical URL: https://hyejunl33.github.io/projects/2026-10-12-wrtn-05-safety-filtering/ - Collection: Project - Published: 2026-10-12 - Tags: Project 캐릭터챗은 유저가 자유롭게 스토리를 만드는 서비스다. 광고 제작을 자동화하려면 이미지를 잘 만드는 것만큼, 만들면 안 되는 광고를 먼저 거르는 것도 필요했다. 서비스에 있는 스토리라고 모두 광고로 내보낼 수 있는 건 아니었다. 문제가 있는 소재를 놓치는 것은 피해야 했지만, 민감한 단어가 한 번 등장했다는 이유로 모두 차단하면 정상적인 판타지까지 빠졌다. 처음에는 보수적으로 잡고, 실제 판정 사례를 보면서 범위를 좁혀 갔다. ## 살아 있는 스토리인지 먼저 확인했다 BigQuery에 적재된 데이터에는 삭제됐거나 비공개로 바뀐 스토리도 있었다. 광고를 클릭하면 딥링크로 해당 스토리에 들어가야 하는데, 서비스에 없는 작품을 광고하면 유입이 끊긴다. 그래서 공개·활성 상태, 삭제·차단 여부, 국가코드 등은 쿼리 단계에서 먼저 확인했다. 제작할 때는 살아 있었지만 집행 중에 제작자가 내리거나 차단되는 경우도 있었다. 전처리 한 번으로 끝낼 수 없는 문제여서 주간 크론으로 라이브 상태를 다시 조회하는 흐름을 뒀다. 성인물과 2차창작 여부도 데이터에 필드가 있으면 먼저 제외했다. 매체 가이드라인을 참고한 생성 가드레일과 별개로, 구조화된 데이터로 바로 판별할 수 있는 조건은 앞단에서 처리했다. ## 어느 단계에서 무엇을 거를 것인가 필터는 한 곳에만 두지 않았다. 데이터 적재에서는 스토리 자체의 광고 적합성을 보고, 이미지 후보에서는 광고에 쓸 수 없는 그림을 걸렀다. 카피 생성 프롬프트에도 안전 가이드를 넣었다. 원문 스토리가 통과해도 생성 과정에서 표현이 달라질 수 있기 때문이다. LLM 분류의 결과는 safe와 blocked로 받았다. 초기에는 애매하면 blocked로 분류하고, 한 축이라도 문제에 해당하면 차단하는 방향이었다. 오리지널 스토리는 서비스에서 별도 검수한 공식 작품이라 이 검사에서 면제했다. 자동 판정이 오리지널이면 안전하다고 알아낸 것이 아니라, 이미 검수한 콘텐츠를 별도 경로로 처리한 정책이었다. | 판정축 | 무엇 | 크랙 | OOC | 카라푸 | | --- | --- | --- | --- | --- | | minor_sexual | 미성년 성적 묘사 | ● | ● | ● | | discrimination | 차별 + 노예·인신매매의 노골적 성적 묘사 | ● | ● | ● | | self_harm | 자해 | ● | ● | ● | | gambling | 도박이 스토리의 중심 주제일 때만 | ● | ● | ● | | politically_sensitive | 선거·진영 갈등 | ● | — | — | | religion_political | 2026-08-05 전 스코프 은퇴 | — | — | — | 분류축과 적용 서비스는 운영 중에 바뀌었다. 정치 관련 기준은 한국 서비스와 해외 서비스에서 같지 않았고, 종교축은 이후 제거했다. 아래 실험도 당시 사용했던 기준 안에서 읽어야 한다. ## 문제 사례를 잡으면서 정상 스토리의 오차단 줄이기 초기 테스트셋은 문제가 있었던 스토리 세 개와 랜덤으로 뽑은 정상 스토리 97개였다. 당시에는 소재 수가 줄어드는 것보다 문제가 있는 광고가 나가는 것이 더 치명적이라고 봤다. 그래서 blocked recall을 우선했다. Claude Opus 4.6으로 분류했을 때 문제 사례는 3/3건을 잡았다. 반면 정상으로 라벨링한 97건 중 일곱 건도 blocked로 분류됐다. 이 일곱 건이 평가셋 기준의 False Positive, 즉 오차단이었다. 문제 사례를 놓치지 않는 수준을 유지하면서, 정상 소재가 어떤 이유로 걸렸는지 확인해 과차단을 줄이는 것이 다음 과제였다. blocked 예측 열 건 중 실제 문제 사례가 세 건이라 precision은 0.30이었다. | 지표 | 값 | 의미 | | --- | --- | --- | | blocked recall = 1.00 | 3/3 | 🎯 핵심 성과 – GT 누수 0건 | | safe recall = 0.928 | 90/97 | 7건 false positive (오차단) | | blocked precision = 0.30 | 3/10 | 모델 blocked라 한 10건 중 3건만 진짜 | | F1 = 0.46 | – | precision이 낮아 F1 저하 | | MCC = 0.528 | – | 불균형 데이터 고려 시 양호 | | Accuracy = 0.93 | – | 전체적으로 잘 분류 | 평가에서 차단 대상으로 지정한 세 사례는 장애를 대상화하는 맥락, 실존 정치인과 정치적 갈등을 중심으로 한 스토리, 영토 분쟁을 소재로 한 스토리였다. 정상 라벨과 판정이 달랐던 일곱 건의 이유도 따로 읽었다. 판타지 종교 설정, 역사적 배경, 본문 안의 자해나 미성년 관련 표현 등이 있었다. 처음 붙인 정상 라벨과 모델의 판단이 다르면, 모두 모델의 잘못이라고 바로 결론 내릴 수는 없다. 판정 기준과 라벨이 일치하는지도 다시 봐야 했다. 중요한 것은 모델이 어떤 근거로 차단했는지 남겨 다음 기준 조정에 쓸 수 있다는 점이었다. ```plaintext [오체불만족] (gt_category=discrimination) pred_status : blocked pred_category : discrimination reason : 장애(사지결손)를 핵심 소재로 다루며, 태그·시스템 프롬프트에서 장애를 대상화하는 맥락이 드러나 discrimination으로 판단함. latency : 59.4s → status ✓ | category ✓ [리버스 1979] (gt_category=politically_sensitive) pred_status : blocked pred_category : politically_sensitive reason : 박정희·김대중·전두환·김재규 등 실존 한국 정치인 실명이 다수 등장하고 정치적 사건·갈등을 스토리의 핵심 소재로 삼아 politically_sensitive로 판단함. latency : 59.4s → status ✓ | category ✓ [독도는 일본땅] (gt_category=politically_sensitive) pred_status : blocked pred_category : politically_sensitive reason : 제목·시스템 프롬프트·대사에서 독도/다케시마 영토 분쟁을 핵심 소재로 삼고 있어 politically_sensitive로 판단함. latency : 59.4s → status ✓ | category ✓ ``` ```plaintext False Positive: 7 건 - [사랑하는 나의 증오에게] → self_harm reason: content_summary에서 '시체를 끌어안은 채 제 심장을 찌를 겁니다'라며 직접적인 자해 표현을 사용해 self_harm으로 분류함. - [1933년 독일에서 살아남기s] → politically_sensitive reason: title·system_prompt·initial_messages에서 '1933년 독일'이라는 시대·정치적 배경이 명시되어 정치적으로 민감한 설정으로 판단함. - [지옥과 천국에서의 삶] → religion_political reason: userPrompt 및 세계관 설정에서 기독교의 실존 천사(미카엘, 가브리엘 등)와 종교 세계관이 등장해 religion_political로 분류함. - [조정혀] → minor_sexual reason: userPrompt 필드에서 중학교(꿈결중학교) 재학생 캐릭터가 '야한 드립을 한다'는 성적 대화 설정을 갖고 있어 미성년자와 성적 맥락의 결합으로 판단함. - [미래를 아는 자 과거를 바꾸다] → politically_sensitive reason: content_summary 및 initial_messages에서 '박정희 대통령 시해' 등 실존 정치인과 정치적 사건을 핵심 소재로 제시하여 politically_sensitive로 판단함. - [원효] → religion_political reason: title, tags, content_summary 등에서 실존 불교 승려 '원효대사'를 중심인물로 제시해 religion_political로 분류함. - [천국 시뮬레이션] → religion_political reason: customPrompt의 테마 필드에 '종교'가 명시되어 있고, 스토리 전체가 천국이라는 종교적 세계관을 중심으로 구성되어 religion_political로 분류함. ``` 이 실험의 총 비용은 5.07달러, 스토리당 평균은 0.0507달러였다. 이후 Gemini 3.1 Flash Lite로 바꿔 비교했고, 당시 기록에서는 비용이 약 52배 저렴하면서 문제 세 건의 recall을 유지했다. 안전성 분류 모델의 비용·판정 결과 비교
비교 실험의 blocked precision·recall·F1
비교 이미지에는 blocked precision 0.375, recall 1.000, F1 0.545가 남아 있다. 다만 문제 사례가 세 개뿐인 실험의 recall 1을 일반적인 운영 성능으로 볼 수는 없다. 더 다양한 문제가 들어오면 놓치는 사례가 생길 수 있고, 모델을 바꾸는 것과 기준을 바꾸는 효과도 따로 봐야 한다. ## 엄격한 검사에서 SF·판타지까지 과차단됐다 검사를 엄격하게 적용하자 광고로 쓸 수 있는 SF·판타지 스토리까지 과차단됐다. 민감한 요소가 세계관에 등장하는 것과, 그 요소를 광고에 부적절한 맥락으로 다루는 것을 구분해야 했다. 크랙 200건의 dry-run에서도 노예·도박을 등장만으로 판정하자 차단률이 11%에서 31.5%로 올랐다. 많은 사례가 신분제 세계관에 '노예'라는 단어가 한 번 들어 있는 정도였다. 이 비율은 전체 차단률이고, 그 자체가 오탐률은 아니다. 다만 차단 근거를 읽어 보니 기준이 넓다는 문제가 드러났다. 그래서 차별이나 노예·인신매매의 노골적인 성적 맥락을 보도록 좁히고, 도박도 스토리의 중심 주제일 때 판정하는 식으로 조정했다. 민감한 단어가 등장한 사실보다 광고에 쓰기 어려운 맥락이 실제로 있는지를 보게 했다. OOC에서도 종교·정치축이 판타지 설정을 많이 잡았다. 3,762건 중 blocked는 196건이었고, 그중 33건의 근거가 Lucifer, 십자가 소품, 소림사, 윤회 같은 요소였다. 종교적 갈등을 광고하는 것과 종교에서 가져온 판타지 설정을 구분하지 못한 것이다. 이 사례를 확인하고 종교축을 제거했다. ## 기준은 운영 사례와 함께 바뀌어야 했다 처음 실험은 알려진 문제를 놓치지 않는지 확인하는 용도였다. 정상 사례 97건도 서비스 전체의 장르와 국가별 분포를 대표하도록 구성한 것은 아니었다. 따라서 낮은 비용의 모델이 비슷한 결과를 냈다는 관찰은 유용했지만, 그 테스트셋만으로 안전성 필터를 완성했다고 할 수는 없었다. 안전하게 자동화하려고 넓게 막았는데, 그 기준이 너무 넓으면 제작할 수 있는 정상 콘텐츠가 줄어든다. 판정축을 추가한 뒤에는 실제 차단 이유를 읽고, 맥락이 다른 사례를 모으고, 기준을 다시 조정해야 했다. 이후에도 신규 문제 사례를 평가셋에 추가하면서 확인하는 일이 남았다. ### IP침해차단 파이프라인 만들기 - Canonical URL: https://hyejunl33.github.io/projects/2026-10-12-wrtn-06-ip-detection/ - Collection: Project - Published: 2026-10-12 - Tags: Project 광고에 쓸 스토리 이미지에서 확인해야 하는 IP는 애니메이션에 한정되지 않았다. 애니메이션처럼 정해진 도메인의 IP는 WD-Tagger로 태깅한 뒤 걸러낼 수 있었고, ops팀도 이미 이 방식으로 자동 태깅과 필터링을 하고 있었다. 우리가 더 확인해야 했던 것은 영화, 버튜버, 삼국지나 콜오브듀티 같은 게임의 에셋 IP까지 포함한 범위였다. 태거가 아는 캐릭터만 확인해서는 이 범위를 다루기 어려워 이미지 역검색을 사용했다. 스토리의 2차창작 여부는 서비스 데이터에 필드로 있었다. 처음에는 그 값이 false인 스토리만 광고로 만들었다. 그런데 운영하면서 해당 필드가 false인 작품에 알려진 버튜버 IP가 들어 있는 사례가 생겼다. 신고가 들어온 콘텐츠를 사람이 처리하는 흐름만으로는 광고 생성 앞에서 모든 후보를 확인하기 어려웠다. 이미지의 IP를 찾는 모듈을 따로 만들었고, 그 과정에서 '웹에 같은 그림이 있다'는 것과 '알려진 IP를 사용했다'는 것이 다르다는 문제를 만나게 됐다. ## 역검색과 이미지 거리로 시작했다 처음에는 이미지 역검색 결과와 원본 이미지의 유사도를 사용했다. 실제 문제가 있었던 다섯 스토리의 이미지 쌍을 잘 찾는 임베딩 모델을 비교했고, CCIP가 해당 사례에서 높은 유사도를 보여 채택했다. 거리 지표는 `(1 - cosine similarity) / 2`였다. 값이 작을수록 비슷한 이미지다. 랜덤으로 뽑은 1,000개 스토리의 프로필 이미지에서 점수 분포를 보고, 이미지 쌍을 직접 확인해 0.055를 초기 후보 기준으로 정했다. IP 이미지 쌍의 임베딩 모델 비교
거리 기준을 정하기 위해 확인한 이미지 쌍
이미지 쌍의 유사도와 오류 사례
이미지 거리 분포와 후보 임계값
이 방식은 같은 이미지를 찾는 데는 쓸 수 있었지만, 다른 사이트에 그 이미지가 있다는 이유만으로 차단하면 문제가 있었다. 같은 제작자가 여러 캐릭터챗 서비스에 올릴 수도 있고, 누군가 핀터레스트에 재게시했을 수도 있다. 검색 결과만으로 어느 쪽이 원본인지 알 수 없는 경우도 있었다. 광고 제작에서는 애매한 경우까지 보수적으로 막는 선택을 할 수 있었지만, Ops 검수에도 이 기준을 그대로 적용하면 너무 많이 차단됐다. 랜덤 1,000건에서 약 20%가 검열되는 문제가 있어서 기준을 바꿀 필요가 있었다. ## 검색 결과가 가리키는 엔티티를 보게 했다 사례를 알려진 버튜버·게임·애니 캐릭터·실존인물이 있는 경우, 다른 서비스나 이미지 모음 사이트에 등장하지만 권리 관계가 불명확한 경우, 검수된 오리지널이나 제작자 자체 이미지인 경우로 나눠 봤다. 다른 사이트에 등장한 이미지 사례
재게시와 IP 식별을 구분해야 하는 사례
동일 이미지가 검색되는 또 다른 사례
검색 결과를 그대로 차단 판정으로 쓰는 대신, 검색이 제공한 맥락을 LLM이 읽는 단계를 추가했다. 원본과 매치 이미지 쌍, 도메인, 페이지 제목과 URL, 역검색 태그를 함께 넣었다. 스토리 제목과 요약, 프롬프트, 태그도 판정 맥락으로 활용했다. 이미지와 검색 결과 맥락을 함께 넣은 판정 입력
LLM에는 알려진 실체인지, 엔티티 이름과 소속 작품은 무엇인지, 어떤 유형인지, 어느 도메인의 증거가 결정적이었는지를 구조화해서 받았다. 이름을 이미지에서만 맞히게 했을 때 놓쳤던 한국 버튜버나 게임 캐릭터도, 관련 페이지 제목과 태그가 함께 있으면 식별할 수 있었다. ```python class Verdict(BaseModel): is_known: bool = False # 핵심 판정 — 증거가 실존 실체를 지목하는지 여부 entity_name: Optional[str] = None # 지목한 실체명 (예: "흥선대원군 (이하응)") franchise: Optional[str] = None # 소속 작품/그룹/회사 (예: "블루 아카이브") entity_type: str = "unknown" # 실체 유형 (실존인물/게임캐릭터/버튜버 등) confidence: float = 0.0 # 모델 자체 확신도 0~1 key_evidence_domain: Optional[str] = None # 결정적 근거가 된 매치 도메인 ``` WD tagger와 역검색 증거 기반 LLM 판정의 데이터 흐름
태거와 역검색을 결합한 IP 탐지 흐름
역검색 증거를 LLM 판정으로 연결하는 흐름
핵심은 웹상 존재 여부보다 검색 증거가 특정 IP나 인물을 가리키는지를 보는 것이었다. 다만 이 출력만으로 실제 권리 관계를 확정할 수 있는 것은 아니다. 우리가 만든 것은 광고·검수 흐름에서 확인할 후보를 가르는 판정 시스템이었다. ## 수동 라벨링으로 바뀐 결과를 확인했다 100건을 수동으로 라벨링해 진짜 문제 사례와 오탐을 구분했다. LLM 레이어를 추가한 평가에서는 문제 사례를 놓치지 않으면서 오탐이 줄었다. IP 판정 평가의 최종 지표
판정 전후의 검수 후보 비교
실험 대시보드에는 recall 100%, FP 감소율 87.8%, precision 20% → 74%가 기록돼 있다. 표의 최종 수치는 불일치 사례를 재검토한 뒤 반영한 결과다. 알려진 문제 26건을 모두 남겼고, 비IP 74건 중 65건을 후순위로 돌려 검수 큐 잔존율은 35%가 됐다. precision은 전체 정확도가 아니라, 검수 큐에 남긴 후보 중 실제 문제 사례가 차지하는 비율이다. 여기서 recall 100%는 해당 평가 표본에서 FN이 없었다는 뜻이다. 이미지에도 26/26의 신뢰구간이 함께 표시돼 있다. 서비스의 모든 IP를 놓치지 않는다는 의미로 확대할 수는 없다. 초기 1,000건 EDA와 이후 라벨링 평가도 서로 다른 목적의 표본이었다. 단일 호출과 세 번 호출하는 앙상블도 비교했다. 120건에서 개선된 것은 한 건이어서, 그 실험에서는 호출을 세 배로 늘릴 만큼 큰 차이가 아니었다. JSON 파싱 오류가 나면 재시도하는 대체 경로는 남기고, 앙상블까지 사용할 필요는 없다고 판단했다. 증거 기반 IP 판정 모델 비교
단일 호출과 세 번 호출한 앙상블 비교
## 웹에 없는 변형 이미지는 또 다른 문제였다 반대로 역검색 결과가 없는데도 유명 IP인 그림이 있었다. 생성 모델로 변형한 이미지는 웹에 똑같은 원본이 없어서 검색에 걸리지 않을 수 있다. 블루아카이브와 귀멸의 칼날 캐릭터 사례에서 이 문제가 드러났다. 변형 이미지에서 확인한 블루아카이브 사례
변형 이미지에서 확인한 귀멸의 칼날 사례
웹 역검색에서 확인한 후보 이미지
변형 이미지의 유사 후보 검색 결과
기존의 0.055 거리 기준은 완전히 같지 않은 이미지를 후보에서 빼는 데도 영향을 줬다. 그래서 후보 기준을 0.1로 넓혔다. 더 많은 후보가 들어와도 뒤의 LLM이 검색 태그와 맥락을 확인하도록 했다. 역검색을 보완하기 위해 파이프라인 앞단에도 WD-Tagger를 연결했다. Danbooru 어휘를 기반으로 유명 애니·게임 캐릭터를 식별하는 경로다. 역검색이 0건이었던 원피스 합성 포스터에서 태거는 roronoa_zoro를 높은 점수로 잡았다. 문제가 있었던 두 스토리도 유명 IP여서 태거로 걸러낼 수 있었다. WD tagger를 추가한 IP 탐지 흐름
태거만으로 끝낼 수도 없었다. 일본 애니·게임에 강한 반면 한국 버튜버는 어휘 커버리지에 없어서 못 잡는 사례가 있었다. 태거와 역검색+LLM은 서로 다른 실패를 보완했다. 이미 서비스에서 검수한 오리지널 스토리는 이 검사에서 별도로 제외했다. 처음에는 이미지가 같은지를 잘 찾으면 문제가 해결될 거라고 봤다. 실제로는 같은 이미지가 있어도 판정을 보류해야 하는 경우와, 같은 이미지가 없어도 알려진 캐릭터인 경우가 함께 있었다. 운영 사례가 생길 때마다 그 차이를 분리하고, 어느 단계가 그 증거를 다룰 수 있는지 다시 설계했다. 본문의 데이터 흐름 애니메이션은 3Blue1Brown의 오픈소스 [Manim](https://github.com/3b1b/manim)에서 출발한 [Manim Community](https://www.manim.community/)로 만들었다. ### 한국에서 만든 광고 파이프라인을 북미·일본으로 확장하기 - Canonical URL: https://hyejunl33.github.io/projects/2026-10-12-wrtn-07-global-expansion/ - Collection: Project - Published: 2026-10-12 - Tags: Project 광고 소재 제작 파이프라인은 크랙에서 먼저 만들었다. 이후 북미 OOC와 일본 캬라푸로 확장했다. 이미 돌아가는 생성 흐름이 있으니 언어만 바꾸면 될 것 같지만, 실제로는 입력 데이터와 UI, 폰트, 디자인 레퍼런스가 달랐다. 공통으로 쓸 수 있는 제작 단계는 유지하고, 서비스마다 다른 조건을 어디에서 분기할지 정하는 작업이었다. ## 입력 스키마부터 달랐다 크랙에서 쓰던 `ending`, `play_guide`, `taste_score`, 추천용 11축 태그가 OOC·캬라푸 테이블에는 없었다. 같은 필드를 당연히 읽는 코드로는 확장할 수 없었다. 없는 값은 입력에서 빼고, 각 서비스가 제공하는 세계관과 시작 상황을 중심으로 기획하도록 구성했다. 소구점과 카피 프롬프트도 언어별로 분기했다. 한국어의 장르 표현을 그대로 번역하기보다는, 해당 언어에서 실제 광고로 쓸 수 있는 문장이 필요했다. 생성 결과의 폴더와 파일명에도 서비스가 드러나게 해서, 마케터분들이 결과를 구분할 수 있도록 했다. 크랙·OOC·캬라푸 서비스별 제작 분기
같은 스토리→소구점→소재 흐름을 유지하되, 플레이어블 UI는 각 서비스에 맞춰 바꿨다. 이미지 배너와 플레이어블, 모션 등 기본 제작 경로를 먼저 확장하고, 현지 레퍼런스에 맞추는 작업을 이어서 했다. ## 폰트와 디자인도 서비스의 일부였다 기존 폰트가 일본어를 지원하지 않아 폰트 라이브러리를 새로 구성했다. 카피를 일본어로 잘 만들더라도 글자가 표시되지 않으면 배너로 쓸 수 없었다. 언어 지원은 스타일 이전에 확인해야 하는 조건이었다. 일본어를 지원하는 폰트 라이브러리
OOC에서는 기존 배너에 폰트 색상과 이펙트를 추가하는 식으로 시작할 수 있었다. 캬라푸의 레퍼런스는 더 다양했다. 일본 마케터분들과 싱크를 맞추고, 어떤 표현을 생성 규칙으로 옮길지 정리했다. 캬라푸에서 생성한 이미지 배너
OOC에서 생성한 소재 예시
현지인이 아닌 내가 어울리는 효과를 혼자 정하기 어려워서, 레퍼런스를 기반으로 역설계하는 방식을 택했다. Figma에 정리된 일본향 배너 약 300장을 장르별로 보고, 자주 쓰이는 효과와 분위기를 텍스트 템플릿으로 만들었다. ## 장르 템플릿만으로는 모든 그림이 비슷해졌다 장르별 `mood_template`에는 색상, 조명, 꽃잎·입자·후광 같은 효과 방향을 넣었다. 로맨스와 판타지, 코미디, 미스터리는 레퍼런스에서 사용하는 표현이 달랐다. 효과 설계에 활용한 일본향 배너 레퍼런스
레퍼런스에서 정리한 효과 구성 요소
| romance-f | sweet otome romance — warm pink/crimson/gold, soft dreamy soft-focus, layered 玉ボケbokeh, rose & sakura 花吹雪 petals, キラキラ sparkle, a tender glowing aura, floating hearts |
| romance-m | warm school romance (male lead) — pink & warm tones, bright rim light, soft bokeh, sakura petals, hearts and キラキラ, cheerful bright grade |
| bl | dramatic romance — cool blue/violet or moody warm gold, strong rim light & dramatic glow, rose petals, halftone, refined bokeh, tasteful sparkle |
| fantasy | epic & magical — luminous god-rays/light-pillars, arcane 魔法陣 magic circle & glyphs, glowing aura, prism dispersion, aurora, floating orbs & light particles |
| humor | bright poppy comedy (少女漫画 pop) — vivid CMYK pop colours, comic halftone burst, exclamation sparkles, hearts & confetti, high-key cheerful |
| mystery | cool suspense / neon-noir — moody cyan/magenta, dramatic spotlight & deep shadow, faint glitch & chromatic aberration, cold sparkle, tense contrast |
| underworld | dark & dangerous — grunge ink splatter, red/black high contrast, diagonal caution stripes, drifting embers & smoke, gold glints, broken-heart accents, deep shadow |
| daily | soft wholesome slice-of-life — warm sunlight 玉ボケ, gentle pastel bokeh, sakura petals, small hearts and sparkles, dreamy soft-focus |
| sf | neon cyber — electric cyan/magenta, digital particles & data motes, non-text HUD glints, 稲妻 lightning, lens flare, glowing grid lines |
| period | elegant traditional — gold accents, 桜 sakura & 花吹雪, ink-wash (水墨) haze, seigaiha wave motifs, refined warm glow, stained-glass light |
| sports | dynamic & energetic — bold speed lines & 集中線, impact bursts, motion streaks, vivid punchy complementary contrast, sweat-drop energy |
| etc · (기본) | vivid & eye-catching — bold mood grade, layered bokeh, sparkle-dust, confetti, dramatic rim light |
코미디 장르의 이미지 효과 적용 예시
판타지 장르의 이미지 효과 적용 예시
예시는 장르별 분위기를 반영한 산출물이다. 배너가 레퍼런스와 비슷한 형태가 됐다는 것과 실제 광고 성과가 좋다는 것은 별개라, 디자인 변화만으로 성과 개선을 주장하지는 않으려고 한다. ## 원본 썸네일을 규격에 맞추는 별도 경로 캬라푸에서는 앱 썸네일 원본 자체를 네 가지 광고 사이즈로 변형하는 경로도 만들었다. 여기는 카피를 새로 얹는 배너와 조건이 달랐다. 원본에 들어 있는 타이포를 유지하면서 크레딧과 로고만 붙여야 했다. 앱 썸네일을 광고 규격으로 바꾸는 흐름
모델을 부르기 전에 생성 크기부터 계산했다. 두 변은 16의 배수, 최종 결과와 같은 비율, 면적 하한과 최종 크기 이상이라는 조건을 맞췄다. 원본과 목표 비율의 상대오차가 2% 이내면 생성 모델을 호출하지 않고 리사이즈만 했다. 불필요하게 다시 그리게 하면 모델이 원본 문구를 바꾸는 문제가 있었기 때문이다. 원본의 글자는 하나의 고정된 이미지 자산으로 취급했다. 글자 블록을 통째로 옮기거나 줄일 수는 있어도, 새로운 문구를 쓰거나 글자 자체를 바꾸지 않게 했다. 원본에 글자가 없으면 결과에도 없어야 한다는 조건도 넣었다. 안전 영역을 알려주는 것만으로는 잘림 문제가 충분히 줄지 않았다. 글자 블록이 차지할 수 있는 높이를 숫자로 명시한 뒤에야 축소하는 결과가 나왔다. 상단에는 규격별로 로고·크레딧 공간을 예약했다. ```yaml AGENTS/KYARAPU_FX/MINIMAL_META.PY · REFRAME_PROMPT_TMPL (구조) ① 글자 불가침 선언 — 맨 앞에. 원본에 박힌 타이포는 "고정 자산"이며 새로 만들거나 바꾸지 않는다. ② ANATOMY 절. 가려진 신체를 예측해서 그리지 말 것. (손가락 4개/6개의 근원) ③ 상단 예약대 (reserved_top_frac). 9:16 = 11% · 1:1 = 18% · 4:5 = 14% — 크레딧·로고가 들어갈 자리. ④ 가로 SAFE AREA 가로 규격은 잘림 위험이 커서 안전 영역을 따로 선언한다. ⑤ 무자막 역방향 조항. 원본에 글자가 없으면 없는 채로 둔다 — 창작 금지. ``` 전송 장애 재시도와 해부학 오류 재생성은 따로 처리했다. 손가락이나 팔다리 형태가 계속 잘못 나오면 해당 베리에이션을 버렸다. 이 경로에서는 앱 썸네일을 광고하는 것이므로, 실패했다고 전혀 다른 그림으로 교체할 수는 없었다. ## 현지화는 계속 피드백을 받는 작업이었다 데이터 분기와 기본 제작 기능을 구현한 뒤에도 현지 고도화는 남았다. 언어가 맞고 파일이 생성된다는 사실만으로 현지 광고의 톤이 맞는 것은 아니었다. 마케터분들이 보는 카피 방향과 디자이너분들의 레퍼런스를 받아서, 반복해서 적용할 수 있는 조건으로 바꿔야 했다. 공통 파이프라인을 유지하면 새 형식과 수정사항을 여러 서비스에 전달하기 쉽다. 반면 서비스의 차이를 공통화하려고 억지로 없애면 입력도 디자인도 어색해질 수 있다. 같은 흐름을 쓰되, 없는 필드와 언어별 문장, 폰트와 규격 제약은 분명하게 나누는 쪽으로 확장했다. ### 성과가 난 광고에서 다음 스토리를 찾는 위닝앵글 검색 - Canonical URL: https://hyejunl33.github.io/projects/2026-10-12-wrtn-08-winning-angle-search/ - Collection: Project - Published: 2026-10-12 - Tags: Project 초기 AX 제작은 좋아요 랭킹 순으로 스토리를 넓게 탐색하는 방식이었다. 이후에는 이미 성과가 난 광고에서 다음 후보를 찾는 경로를 만들었다. 다른 팀원이 만든 에이전트의 광고 성과 분석과 인사이트를 받아, 비슷한 소구점이나 이미지를 가진 새로운 스토리를 발굴하는 작업이다. 발굴 이후의 제작은 기존 서브카피·롱폼·모션 파이프라인을 그대로 사용했다. 새로 만든 것은 그 앞에서 어떤 스토리를 가져올지 정하는 검색 경로였다. ## 앵글과 실제 소재를 따로 저장했다 입력은 다른 팀원이 만든 에이전트에서 JSON 형태로 받은 광고 성과 분석과 인사이트였다. 여기에는 앵글 제목과 요약, 추천 크리에이티브 브리프, AI 분석 근거와 확신도, 뒷받침 소재 수, 위닝 형식과 매체가 들어 있었다. 이 분석 결과를 다음 스토리 검색의 입력으로 활용했고, 앵글을 뒷받침하는 배너와 원본 스토리는 별도 목록으로 남겼다. ```plaintext selection_id 앵글 고유 id title 위닝 앵글 제목 summary 요약 recommended_brief 추천 크리에이티브 브리프 (가설 시드) ai_rationale 왜 이겼는지에 대한 분석 근거 category genre_theme | copy_angle confidence 확신도 support_count 이 앵글을 뒷받침한 소재 수 media_type image | video ← 위닝 형식 platform meta | tiktok ← 위닝 매체 ``` ```plaintext folder_name Drive 폴더명 creative_name 소재 이름 material_type img | vid genre 파싱된 장르 form sub | tag | longform | motion story_id 딥링크에서 뽑은 원본 스토리 (없으면 데이터 오류) ``` '어떤 관계나 장면이 잘됐다'는 분석 문장과 실제 광고 파일이 연결돼 있어야 했다. 원본 스토리는 소재의 딥링크에서 식별했다. 이후 새 후보를 만들 때도 어떤 앵글과 검색축에서 왔는지 남겨서, 결과를 다시 확인할 수 있게 했다. 텍스트축·이미지축의 후보를 순환 선택하는 흐름
위닝 앵글에서 스토리를 발굴하고 제작하는 흐름
## 텍스트축은 실제 위닝 스토리의 소구점으로 처음처럼 LLM에게 가상의 소구점을 새로 만들게 하기보다, 위닝 앵글을 뒷받침한 실제 스토리의 감정·훅·소구점 원문을 검색어로 썼다. 그 문장은 검색 코퍼스가 임베딩한 원문이기도 했다. 검색을 위해 번역하거나 다시 해석하면서 뜻이 흔들리는 것을 줄일 수 있었다. 어휘 검색인 BM25와 의미 기반 벡터 검색을 순위 융합으로 합쳤다. 같은 키워드를 공유하는 후보와 표현은 달라도 의미가 비슷한 후보를 함께 찾으려는 방식이었다. 한쪽 검색이 실패해도 다른 쪽 결과를 반환하도록 했다. 위닝 스토리가 연결돼 있지 않을 때만 LLM이 가상 소구점을 만드는 기존 경로로 돌아갔다. 실제 원문이 있는데도 다시 만들어 쓰는 것과, 입력이 없어서 대체하는 경우를 나눴다. ## 이미지축에서는 배너마다 따로 검색했다 이미지축은 위닝 배너 그림 자체를 CLIP으로 인코딩하고, 스토리의 프로필 이미지에서 이웃을 찾았다. 여기서 여러 배너의 결과를 어떻게 합칠지가 문제였다. 실측 사례에서 배너 일곱 장이 있는 앵글의 상위 열 후보 중 일곱 개가 한 배너에서 나왔다. 인물 크롭이 큰 배너가 순위를 독식하는 현상이 있었다. 광고 배너와 캐릭터 일러스트는 종류가 달라 절대 코사인 점수도 낮게 나왔기 때문에, 다른 배너의 점수를 같은 기준으로 비교하기 어려웠다. 그래서 배너마다 후보를 따로 찾고 돌아가며 채웠다. 각 배너 내부의 순위를 사용하고, 하나의 배너가 전체 후보를 가져가지 않도록 했다. 여러 이미지의 평균 벡터도 쓰지 않았다. 서로 다른 그림체와 구도를 평균내면 어느 쪽도 제대로 나타내지 않는 중간점이 될 수 있어서였다. 이 선택은 다양성을 확보하기 위한 운영 규칙이었다. 서로 다른 배너의 점수를 섞어서 하나의 높은 숫자를 고르는 것이 이 작업의 목적과 맞는지부터 다시 봐야 했다. ## 검색 결과를 그날의 생성 목록으로 앵글들을 돌아가며 목표 개수만큼 새로운 스토리를 발굴했다. 개별 앵글 검색이 실패하면 그 앵글만 건너뛰고 전체 작업은 계속했다. 후보가 모자라면 목표 미만인 채로 끝냈다. 개수를 맞추려고 관련성이 낮은 후보를 억지로 넣지는 않았다. 발굴은 크론으로 미리 돌리고, 아침에 통합 생성 화면을 열면 사용할 세트가 준비돼 있게 했다. 운영자는 일괄 생성을 실행하고 결과를 확인할 수 있다. 선택된 스토리는 기존 제작 흐름에 들어간다. 다만 디자이너 프롬프트에는 위닝 카피의 헤드라인·서브·CTA와 그 톤을 예시로 넣었다. 결과물은 위닝 경로의 폴더로 올리고 소재 메타데이터에 어느 검색축에서 발굴했는지 기록했다. ## 실제 집행에서 확인한 성과 위닝 앵글에는 '왜 성과가 났는가'에 대한 해석이 들어 있다. 실제 소재를 근거로 한 분석이지만, 그것을 새로운 스토리에 적용했을 때 같은 성과가 난다고 확정할 수는 없다. 검색은 그 가설과 비슷한 후보를 찾아주는 단계다. 실제 집행에서는 차이가 나타났다. 서비스별로 차이는 있었지만, 위닝앵글을 기반으로 만든 광고 배너는 그리드서치 방식으로 만든 배너보다 약 두 배의 성과를 냈다. OOC에서는 핵심 지표로 봤던 D0 ROAS가 10% 이상으로 유지되는 결과도 나왔다. 이 작업에서는 모델이 새 기획을 계속 만드는 것보다, 운영팀이 이미 확인한 광고와 원본 스토리를 다음 제작에 연결하는 데 집중했다. 텍스트축과 이미지축을 분리하고, 후보가 어디서 왔는지 남긴 이유도 이후 집행 결과를 다시 읽기 위해서였다. 이후에도 어떤 앵글과 검색축이 유효한지는 새 광고의 집행 결과와 함께 계속 확인해야 한다. 본문의 데이터 흐름 애니메이션은 3Blue1Brown의 오픈소스 [Manim](https://github.com/3b1b/manim)에서 출발한 [Manim Community](https://www.manim.community/)로 만들었다. ### 카피 A/B 테스트와 밈으로 광고 성과를 끌어올리기 - Canonical URL: https://hyejunl33.github.io/projects/2026-10-12-wrtn-09-ad-performance-experiments/ - Collection: Project - Published: 2026-10-12 - Tags: Project 광고 배너를 자동으로 만들 수 있게 된 뒤에는 어떤 카피를 얹을지가 다음 과제였다. 그런데 어떤 형태의 카피가 효과적이라고 할 수 있을까? 성과가 높은 카피, 재밌는 카피에는 정해진 Ground Truth가 없었다. 광고 성과를 끌어올리는 AX를 하는 입장에서 이 부분이 가장 어려웠다. 답이 없는 문제를 풀고 있다는 느낌이었다. CTR이나 D0 ROAS처럼 집행 후에 볼 수 있는 지표는 있었다. 어려운 것은 집행 전에 카피만 보고 그 성과를 대신 평가할 명확한 metric을 정하는 일이었다. LLM as Judge를 쓴다고 해도 어떤 프롬프트로, 어떤 기준으로 점수를 매겨야 할까? 좋은 광고 카피란 무엇인지 정하지 못한 상태에서는 평가 점수를 높여도 실제 광고 성과가 좋아진다고 보기 어려웠다. 그래서 여러 톤앤매너로 카피를 만들고 실제로 라이브한 뒤, 성과가 좋은 톤앤매너를 다음 카피에 사용해 보기로 했다. 같은 스토리의 소구점도 행동을 권하는 문장으로 쓸 수 있고, 캐릭터의 대사나 상황을 보여주는 문장으로 쓸 수 있었다. 서비스별로 마케터분들이 선호하는 톤도 달랐으니, 그 의견을 테스트할 수 있는 후보로 만드는 것부터 시작했다. ## 현지 마케터의 의견을 테스트할 수 있는 형태로 OOC에서는 구어체 카피, 캬라푸에서는 행동유도형 카피가 좋을 것이라는 마케터분들의 의견이 있었다. 특정 방향으로 고정하기보다 여러 톤을 만들어 테스트해 보자는 방향으로 정리됐다. 같은 스토리 소구점에서 세 가지 형식을 만들었다. - 행동유도형: 헤드라인이 유저에게 행동을 요구하거나 권한다. - 캐릭터 대사형: 그림 속 캐릭터가 그 장면에서 할 법한 구어체 한마디다. - 상황형: 소구점의 상황을 경악·깨달음·곤경으로 표현한다. 슬라임 스토리의 캐릭터 대사형 카피
슬라임 스토리의 행동유도형 카피
슬라임 스토리의 상황형 카피
좀비 스토리의 캐릭터 대사형 카피
좀비 스토리의 행동유도형 카피
좀비 스토리의 상황형 카피
같은 소재에서도 헤드라인과 CTA가 어떻게 달라지는지 볼 수 있었다. 생성 경로는 공통 입력에서 유형별 카피를 만들고 렌더링하는 형태로 구성했다. 카피 유형별 생성과 렌더링 흐름
## 밈을 카피에 넣고 실제로 테스트했다 톤앤매너를 바꾸는 것과 함께, LLM이 뽑은 소구점만으로 카피를 생성하는 방식에도 다른 입력을 더해보고 싶었다. 스토리에 맞는 밈을 retrieval하고 RAG로 카피를 만들면 사람들의 눈길을 끌 수 있지 않을까? 일단 광고를 클릭해야 서비스 퍼널로 들어오고, 그 안에서 결제까지 이어질 기회도 생긴다. 밈으로 어그로를 끌어 CTR을 높이고, 그 유입이 D0 ROAS 개선으로 이어질 수 있을지를 보고 싶었다. 이 가설을 테스트하려고 스토리의 상황에 맞는 밈을 검색해 카피 생성에 함께 넣는 파이프라인을 구상했다. 클릭을 유도할 만한 표현이어도 스토리와 맞지 않으면 억지스럽고, 위험한 맥락이 있으면 광고에 쓸 수 없었다. 밈 카탈로그의 출발점은 나무위키의 밈 정리 문서였다. 여기서 크롤링한 밈 216개를 그대로 카피 생성에 넣지는 않았다. 위험한 밈이나 광고에 어울리지 않는 항목을 걸러내는 전처리 과정이 필요했다. 먼저 키워드 기반 휴리스틱으로 정치·사망·특정인 관련 위험 키워드가 있는 항목을 걸렀다. 곡·댄스·인물 등 광고 카피에 부적합한 항목도 이 단계에서 제외했다. 통과한 후보는 LLM이 본문과 유래를 읽고 안전성 등급을 판정하도록 했다. `red`는 배제하고, `yellow`는 사람 검수를 통과한 경우에만 사용했으며, `green`은 카탈로그에 넣었다. 짧은 표현만 보면 평범해 보여도 유래에 위험한 맥락이 있을 수 있어서 본문까지 확인하는 흐름으로 구성했다. 카탈로그에는 의미, 사용 맥락, 톤, 어울리는 캐릭터 유형, 사용 패턴과 템플릿 슬롯, 안전성, 신선도 등을 정리했다. 같은 유행어를 모든 캐릭터에 붙이기보다 어떤 관계와 상황에서 자연스러운지 구분하려는 정보다. 카피에 적용한 뒤에도 억지스럽거나 재미없는 밈, 스토리 맥락에 맞지 않는 결과는 걸러야 했다. ```yaml - id: ssyagal phrase: 쌰갈 meaning: 한중 국제커플 유튜버 '여단오'의 멤버 여루가 기분 나쁠 때 '씨발'을 돌려 말하는 표현으로, 짜증이나 황당함이 날 때 널리 쓰입니다. usage_context: - 짜증 - 황당함 - 분노 - 코믹한 분노 - 스트레스 - 일상 tone: - 코믹한 - 짜증난 - 유쾌한 - 캐주얼한 archetype: - 다혈질 소꿉친구 - 스트레스 받는 직장인 - 개그 캐릭터 - 허당 악당 - 츤데레 usage_pattern: append template_slots: '{짜증나는 상황}... 아 쌰갈!' source_type: person applicability: 3 safety: yellow safety_note: 욕설(씨발)을 돌려 말하는 유행어 freshness: 5 era: 2023년경부터 입소문을 타기 시작해 숏폼 및 AI 음성 밈으로 널리 쓰이는 현역 밈 origin_country: 한국 - id: byeongi_e_naeryeo phrase: ○○를 변기에 넣고서 내려 meaning: 상대를 변기에 넣고 물 내리듯 압도적으로 짓밟겠다는 강한 디스·도발 펀치라인 usage_context: - 디스 - 도발 - 라이벌 - 압도 - 기싸움 - 선전포고 tone: - 도발 - 공격적 - 힙합 - 자신감 - 살벌 archetype: - 라이벌 캐릭터 - 디스전/래퍼 - 도발적 빌런 - 기싸움 연애물 - 먼치킨 template_slots: '{상대}를 변기에 넣고서 내려' source_type: song applicability: 3 safety: yellow safety_note: 실명 비방 원문(빅나티/BIG Naughty) 제거하고 ○○ 슬롯으로 일반화 freshness: 5 era: 2025~ 현역(스윙스 디스전 밈) origin_country: 한국 - id: bamti-ugly-fashion phrase: 밤티 meaning: 라인플레이의 '밤티'라는 유저의 기괴한 코스튬에 다른 유저가 심한 돌직구를 날린 장면에서 유래한 표현으로, 기괴하거나 촌스러운 외모·코디를 뜻하는 대명사로 쓰입니다. usage_context: - 패션테러리스트 - 팩트폭력 - 촌스러움 - 기상천외한코디 - 무덤덤한반응 tone: - 돌직구 - 황당함 - 시니컬 - 유쾌함 archetype: - 패션테러리스트 - 마이웨이캐릭터 - 팩폭러 - 눈치없는캐릭터 usage_pattern: append template_slots: 밤티님 죄송한데 진짜 개 좆같이 생기 셨네요... 소리가 절로 나오는 상황 source_type: meme-native applicability: 3 safety: yellow safety_note: 실존 유저의 닉네임에서 유래한 외모 비하/촌스러움의 대명사로 쓰여 실제 인물에 대한 외모 비하로 사용하지 않도록 주의해야 함 freshness: 4 era: 2020~2021년 라인플레이 커뮤니티에서 시작되어 2024~2025년 X(트위터) 등 SNS에서 다시 확산된 밈 origin_country: 한국 ``` 밈 카탈로그를 활용하는 생성 흐름
밈을 활용한 광고 소재 예시
스토리에 밈을 적용한 카피 예시
같은 스토리의 다른 밈 카피
밈 테스트도 실제 광고 성과를 끌어올리는 방법이 됐다. 다만 카탈로그에서 유행어 하나를 골라 붙이는 것으로 제작이 끝나는 것은 아니었다. 스토리의 관계와 장면에 맞는지, 광고 문구로 써도 되는지 확인하는 과정이 함께 있어야 했다. ## 성과를 보고 다음 카피를 고르는 작업 카피 A/B 테스트는 같은 소구점을 여러 톤으로 표현하는 경로였고, 밈 테스트는 그 표현에 익숙한 유행어와 사용 맥락을 더하는 경로였다. 둘 다 배너를 생성하는 기존 흐름에 붙여 실제 소재를 내보낼 수 있게 만들었다. 실제 집행에서는 일반적인 zero-shot 방식으로 만든 카피에 비해 광고 성과가 최대 2배까지 높아진 결과가 있었다. 북미 서비스인 OOC에서는 D0 ROAS가 10% 이상으로 나온 결과도 있었다. 처음에 고민했던 카피의 평가 기준을 실제 집행 성과로 확인하면서 개선할 수 있었다. 자동 생성의 역할도 카피 한 개를 정답처럼 내놓는 것에서, 비교할 수 있는 후보를 만드는 쪽으로 넓어졌다. 마케터의 의견을 카피 유형으로 만들고, 밈의 의미와 사용 패턴을 카탈로그로 남긴 이유도 같은 가설을 다음 소재에서 다시 테스트할 수 있게 하기 위해서였다. ### CTR을 예측할 수 있을리가 없잖아 무리무리!(무리가아니었다!?): nemotron persona - Canonical URL: https://hyejunl33.github.io/projects/2026-10-12-wrtn-10-nemotron-persona-ctr/ - Collection: Project - Published: 2026-10-12 - Tags: Project Nemotron Persona를 처음 알게 된 건 1차 랄프톤에서였다. 국가권력급 AI 엔지니어 Kevin이 사내 QA 에이전트의 시스템 프롬프트에 Nemotron Persona를 넣고, 변경한 UI·UX 구성요소를 A/B 테스트하는 데 활용하는 에이전트를 만든 것을 봤다. 오픈소스로 신뢰도 있는 설문조사를 LLM으로 할 수 있다니..! 당시에는 그렇게 받아들였다. 광고 배너를 AX로 자동 생성하는 파이프라인에도 무조건 적용해 봐야겠다고 생각했다. 어떤 광고 배너가 잘될지는 결국 집행 비용을 써봐야 알 수 있었다. 배너를 많이 만들 수 있어도, 그중 무엇을 내보낼지 고르는 데는 여전히 돈이 들었다. Kevin의 에이전트를 보고 떠올린 아이디어를 바탕으로, 집행 전에 후보를 걸러낼 수 있을지 확인하려고 NVIDIA Nemotron Persona-Korea 데이터셋으로 선호도 시뮬레이션을 해봤다. 페르소나에 배너와 카피를 보여주고 클릭하고 싶은 정도를 물은 뒤, 그 점수가 실제 CTR과 같은 방향으로 움직이는지 비교했다. 점수에 예측력이 있다면 일정 기준 이상의 배너만 집행하는 방식으로 연결할 수 있었다. 실험에서 확인하려던 것은 바로 이 연결이었다. ## 페르소나의 클릭 의향을 실제 CTR과 비교하기 검증 기준은 실제 CTR과 시뮬레이션 점수의 상관계수였다. 당시에는 correlation이 0.5 이상이면 집행 후보를 고르는 데 활용할 수 있겠다는 기준을 뒀다. 배너를 보고 긍정적인 답을 많이 받는 것보다, 실제로 CTR이 높은 배너에 더 높은 점수를 주는지가 중요했다. 산점도의 가로축은 페르소나가 준 click_intent 점수의 평균이고, 세로축은 실제 CTR(%)이다. click_intent는 0~10점 척도로 평가한 클릭 의향이다. 8점을 받았다고 CTR이 8%라는 뜻은 아니어서, 점수와 실제 집행 지표를 따로 놓고 관계를 봤다. ## 실험 1·2·3에서 평가 집단을 바꾼 이유 세 실험에서는 누구에게 배너를 평가하게 할지를 바꿨다. 일반적인 인구 집단의 반응으로 시작해 광고 타깃에 맞추고, 이후에는 서비스에 관심을 가질 만한 집단까지 좁히려는 순서였다. 각 조건에서 페르소나의 클릭 의향 점수와 실제 CTR을 비교했다. ### 실험 1: 전연령에서 기준 결과를 확인하기 먼저 연령·성별·교육·직업·지역을 층화해 페르소나를 구성했다. 특정 인구 집단에 쏠리지 않은 평가에서도 배너별 클릭 의향이 실제 CTR과 같은 방향으로 움직일지 확인하려 했다. 이 결과를 기준으로 두고, 평가 집단을 타깃에 맞춰 좁히면 예측력이 달라지는지 비교했다. 표본을 구성하기 전에 연령과 성별, 학력, 결혼 상태의 분포도 확인했다. Nemotron Persona-Korea 데이터의 연령·성별·학력·결혼 상태 분포
### 실험 2: 광고 타깃의 연령과 성별에 맞추기 다음에는 평가 집단을 20~39세로 좁혔다. 남성향 스토리는 남성 페르소나에게, 여성향 스토리는 여성 페르소나에게 평가하게 했다. 전연령의 반응을 섞기보다 실제 광고 타깃에 가까운 집단의 반응을 보면 예측력이 나아질지 확인하려는 조건이었다. 이 단계에서는 연령과 성별을 맞췄고, 크랙에 대한 취향으로 집단을 더 고르지는 않았다. | 조건 | 실험 1 | 실험 2 | 실험 3 | | --- | --- | --- | --- | | 연령 | 전연령 층화 표본 | 20~39세 | 20~39세 | | 성별 | 성별 층화 표본 | 남성향은 남성, 여성향은 여성 | 남성향은 남성, 여성향은 여성 | | 그 밖의 구성 | 교육·직업·지역 등을 층화 | 20~30대 남성·여성 | 크랙 서비스를 좋아할 만한 클러스터 선택 | | 실험 정리표의 corr | -0.219 | -0.048 | | ### 실험 3: 같은 연령·성별 안에서도 서비스 취향으로 좁히기 세 번째 조건에서는 20~39세와 스토리 성향에 맞춘 성별 조건을 유지하면서, 그 안에서 크랙 서비스를 좋아할 만한 클러스터를 고르려 했다. 연령과 성별만 같다고 서비스 취향까지 같지는 않으니, 프로필의 관심사와 생활 맥락으로 평가 집단을 더 좁히면 예측력이 나아질지 보려는 방향이었다. 이를 위해 페르소나 서술을 임베딩하고 K-means로 군집화했다. 군집 수는 8개로 설정했다. 프로필을 그룹으로 묶고, 유사한 집단을 벡터 검색으로 찾는 방식을 살펴봤다. 다만 실제로 선택한 클러스터와 사용한 feature 조합, 검색 질의는 작업 기록에 남기지 못했다. 세 번째 조건의 상관계수도 기록하지 않아, 이 방식의 효과를 결과로 확인할 수는 없었다. 페르소나 임베딩의 K-means 군집 분포 — K=8
## 질문과 점수, 판단 이유를 함께 남겼다 선택한 페르소나에게 배너와 카피를 보여주고, 광고를 클릭해 더 알아보고 싶은 정도를 0~10점으로 평가하게 했다. 각 페르소나의 점수를 평균 내 배너별 click_intent를 구한 뒤 실제 CTR과 비교했다. 점수와 함께 판단 이유도 받아, 어떤 프로필이 어떤 이유로 광고에 반응하는지 확인하려 했다. ## 전연령과 20~39세 조건에서 나온 결과 전연령 층화 표본에서 배너 14개를 비교한 결과, 상관계수는 -0.219였다. 페르소나가 더 높은 점수를 준 배너가 실제로 더 높은 CTR을 보이지 않았다. 비교한 소재 수가 적어서 이 실험만으로 예측력을 판단하기도 어려웠다. 전연령 층화 표본 — 실제 CTR과 평균 click_intent 비교: r=-0.219, n=14
20~39세로 평가 집단을 좁혀 배너 86개를 비교했을 때 상관계수는 0.079였다. 약한 양의 상관이지만, 활용 기준으로 생각했던 0.5와는 차이가 컸다. 이 조건에서는 평가가 전반적으로 긍정적인 쪽으로 치우치는 현상도 확인했다. 높은 점수를 받는 것만으로는 배너의 실제 성과를 잘 구분할 수 없었다. 20~39세 표본 — 실제 CTR과 평균 click_intent 비교: r=0.079, n=86
실험 2를 정리할 때의 상관계수는 -0.048이고, 배너 86개를 비교한 결과는 +0.079다. 두 비교의 실행 조건과 표본이 같은지 확인하지 못해 결과를 구분했다. 어느 쪽도 당시 목표였던 0.5에는 도달하지 못했다. ## 페르소나별 점수 기준을 보정해본 비교 배너 88개에 대해서는 원점수 평균과 페르소나별 Z-score 평균도 비교했다. 실제 CTR과의 상관계수는 원점수 평균을 쓰면 0.292, Z-score 평균을 쓰면 0.321이었다. 페르소나마다 점수를 후하게 주거나 박하게 주는 차이를 줄이려고, 각 점수를 `(점수 - 개인 평균) / 개인 표준편차`로 바꾼 뒤 배너별로 평균 냈다. 각자가 평소보다 얼마나 높게 평가했는지 비교하는 [Z-score 보정](https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.zscore.html)이다. 원본 평균 점수와 페르소나별 Z-score 보정 비교 — r=0.292 → 0.321, n=88
| 비교 자료 | 배너 표본 수 n | 상관계수 r | | --- | --- | --- | | 전연령 층화 산점도 | 14 | -0.219 | | 20~39세 산점도 | 86 | 0.079 | | 추가 비교: 원본 평균 점수 | 88 | 0.292 | | 추가 비교: Z-score 보정 | 88 | 0.321 | 상관계수는 0.029 높아졌지만, 이 차이만으로 비정상적으로 커졌다거나 예측력이 유의미하게 개선됐다고 판단하지 않았다. 집행 후보를 자동으로 거를 기준인 0.5에도 미치지 못했다. 배너 88개를 비교한 조건과 세 번째 클러스터 실험의 조건이 같은지 확인하지 못했으므로 두 결과는 구분했다. ## 예측에 필요한 서비스 취향 정보가 부족했다 결과를 보고 가장 먼저 생각한 한계는 feature였다. Nemotron Persona에는 나이, 결혼 여부, 지역, 직업, 취미 같은 일반적인 인구통계와 생활 정보가 있었다. 하지만 우리가 알고 싶은 것은 서브컬처 배너를 보고 클릭할지, 크랙 서비스를 이용하고 비용을 지불할지였다. 이 행동을 직접 설명하는 서비스 관련 feature는 없었다. 취미나 생활 맥락을 자세히 적은 프로필이라고 해도, 그 정보만으로 우리 서비스에 대한 선호를 알 수 있을지는 별개의 문제였다. 각 feature와 크랙 이용 여부의 상관관계를 따로 측정한 것은 아니다. 다만 이번 CTR 예측 실험에서 나온 낮은 상관을 보고, 일반적인 프로필 정보만으로는 우리 서비스의 광고 반응을 설명할 신호가 부족했을 것이라고 추정했다. 결제 의향을 검증한 실험도 아니었으므로 클릭 결과를 결제 예측으로 확장할 수는 없었다. ## 여러 feature를 결합한 집단의 신뢰도도 보장되지 않았다 [NVIDIA의 공식 데이터셋 카드](https://huggingface.co/datasets/nvidia/Nemotron-Personas-Korea)는 공개 데이터와 생성 모델의 제약 때문에 일부 변수 간 독립성을 가정했다고 설명한다. 예를 들어 세부 직업을 배정할 때 성별, 소득, 학력, 전공이 독립적으로 영향을 준다고 가정하며, 성별과 전공의 결합 효과 같은 교호작용은 반영하지 않는다. 이 설명을 모든 feature를 반드시 따로 써야 한다는 사용 규칙으로 읽을 수는 없다. 다만 개별 분포가 현실과 비슷하다는 것만으로, 여러 조건을 동시에 만족하는 페르소나 집단까지 실제 사용자 집단을 잘 대표한다고 볼 수는 없었다. 나는 연령·성별·교육·직업·지역을 함께 사용하고, 프로필을 임베딩해 서비스에 관심을 가질 만한 집단을 고르려 했다. 이 과정에서는 데이터셋이 충분히 검증하지 않은 변수 간 관계까지 신뢰하는 셈이었다. 여러 feature를 합쳐 평가 집단을 정교하게 만들려고 했지만, 실제로는 그 집단의 대표성에 대한 불확실성을 더할 수 있는 방향이었다. 이 결합이 상관계수를 얼마나 낮췄는지 따로 검증하지는 않았다. 그래서 실패 원인으로 확정하기보다는, 실험 설계에서 충분히 고려하지 못한 데이터셋의 한계로 남겼다. ## 결국 광고 집행 필터로 사용하지 않았다 원래 구상은 장르별 배너를 먼저 생성하고, 페르소나로 시뮬레이션한 뒤, 기준 미만인 후보를 제외하는 흐름이었다. 하지만 이번 실험은 상관계수 0.5라는 활용 기준을 충족하지 못했다. 서비스 선호를 직접 설명할 feature가 부족했고, 여러 feature를 결합해 만든 평가 집단의 대표성도 신뢰하기 어려웠다. 이 두 한계와 실제로 확인한 낮은 예측력을 바탕으로, Nemotron Persona를 이용한 CTR 예측은 광고 운영에 사용하지 않기로 했다. 시간상 충분한 표본을 확보하지 못한 점도 있었지만, 표본 수만 늘리면 해결될 문제라고 보지는 않았다. 우리 서비스와 관련된 취향·이용 행동 정보가 없는 상태에서 페르소나를 더 많이 뽑는다고 필요한 신호가 생기는 것은 아니기 때문이다. 질문 형식과 점수 보정, 집단 선택을 바꿔본 기록은 남겼지만, 실제 집행 후보를 고르는 파이프라인에는 붙이지 않았다. ### [이미지기반 카페추천 프로젝트] ADK 기반 에이전트 챗봇 구현 - Canonical URL: https://hyejunl33.github.io/projects/2026-01-30-ADK-Multi-agent/ - Collection: Project - Published: 2026-01-30 - Tags: 이미지기반 카페추천 프로젝트, ADK 기반 에이전트 챗봇 구현 ## 목차 1. [필요한 기능](#필요한-기능) 2. [동네 처리 (Location Agent)](#동네-처리--location-agent) 3. [Stateful 채팅 구현](#stateful-채팅-구현) 4. [ADK 마이그레이션](#adk-마이그레이션) 5. [Context 기반 추천 질문 생성 (Suggestion)](#context-기반-추천-질문-생성-suggestion) 6. [실험 및 검증](#실험-및-검증) --- ## 필요한 기능 - 인풋 쿼리에서 동을 따로 받아서 해당하는 동네 내에서만 검색결과 보여주는 기능 - 인풋 쿼리의 랜드마크나 위치를 받아서 행정동으로 변환하는 에이전트 - Stateful 채팅을 구현해서 이전까지의 Context를 기억해서 다른 카페 찾을 수 있는 기능 - Context에 알맞는 다음 예상 질문을 생성하는 기능 --- ## 동네 처리 → Location Agent **문제정의:** 쿼리에서 자연어로 들어오는 동네의 형태는 매우 다양하다. 홍대, 롯데월드근처(랜드마크)일 수도 있고, 잠실역(역 이름)등일수도 있고, ‘연남동’과 같이 동네 이름 자체일 수도 있다. 유저가 제시한 위치의 근처에 위치한 카페를 검색결과로 보여주기 위해, Location Agent를 사용해서 연관 행정동 리스트를 추출하고, 카페마다 DB에 저장된 `dong_group` 에 해당하는 카페만 검색을 해서 결과로 제시하는 기능이 필요했다. **핵심 목표**: `"홍대"` → `["서교", "연남", "동교", "상수", "합정"]`과 같이 연관 행정동 리스트를 추출하여 검색 재현율(Recall) 향상 ### LocationAgent.run(user_query: str) → dict **입력**: user_query: "홍대 조용한 카페 추천해줘" **처리 흐름**: ```python def run(self, user_query: str) -> dict: # 1. LLM 호출 prompt_result = self._call_llm(user_query) # 2. JSON 파싱 (실패 시 {}~{} 패턴 추출) try: result_json = json.loads(prompt_result) except JSONDecodeError: start = prompt_result.find('{') end = prompt_result.rfind('}') + 1 result_json = json.loads(prompt_result[start:end]) # 3. 결과 반환 return { "is_location_query": result_json.get("is_location_query", False), "region_names": result_json.get("region_names", []), "original_query": user_query } ``` 사용자 쿼리를 Clova LLM에 전달하여 위치 키워드를 추출한다. LLM 응답이 순수 JSON이 아닐 경우를 대비해 `{`와 `}` 사이의 문자열만 추출하는 fallback을 포함했다. 최종적으로 쿼리에 위치 정보가 있는지 여부(`is_location_query`)와 인근 행정동 리스트(`region_names`)를 반환한다. - **_call_llm() 핵심 프롬프트** ``` "너는 서울시 행정동 전문가야. 사용자 입력에서 위치 정보를 추출하고, 해당 위치와 인접한 서울시 행정동 이름을 정확히 반환해." [핵심 규칙] 1. 반드시 행정동 이름만 반환 (예: 성수1가, 자양, 화양) 2. '동', '역', '입구' 같은 접미사는 절대 포함하지 마 3. 랜드마크/역 이름 → 실제 행정동으로 변환 4. 총 5개의 인접 행정동 반환 [변환 예시] - '서울숲' → 성수1가, 성수2가, 금호, 옥수, 행당 (서울숲 ❌) - '건대입구역' → 화양, 자양, 군자, 구의 (건대입구역 ❌) - '홍대' → 서교, 연남, 동교, 상수, 합정 ``` 이 프롬프트를 통해서 LLM이 랜드마크나 역 이름을 그대로 반환하지 않고 실제 행정동 이름으로 변환하도록 유도한다. ‘동’ 접미사를 제거하는 규칙은 DB의 `dong_group` 컬럼과 일치시키기 위함이다. dong_group에는 잠실 1동, 잠실 2동 형식으로 숫자를 포함한 동의 형태로 저장되어있는데, 검색할때는 ‘잠실’이라는 키워드만 포함시켜서, 키워드기반 넓은 동네를 포함하여 검색결과를 보여준다. **API 설정**: - Clova Studio HCX-DASH-002 - temperature: 0.1 (일관된 답변) - maxTokens: 100 **출력**: ```json { "is_location_query": true, "region_names": ["서교", "연남", "동교", "상수", "합정"], "original_query": "홍대 조용한 카페 추천해줘" } ``` ### 검색 엔진 연동 (`src/engine/retriever.py`) - `vibe_search()`에 `location_filter` 파라미터 추가 - `dong_group` 컬럼을 이용한 SQL OR 조건 필터링 ```sql WHERE dong_group IN ('서교', '연남', '동교', '상수', '합정') ``` LocationAgent가 추출한 행정동 리스트를 SQL의 IN 조건으로 변환하여, 해당 지역에 속한 카페만 검색 대상에 포함시킴. 이를 통해 검색 범위를 좁히고 해당 동네에 대해서만 검색결과를다. --- ## Stateful 채팅 구현 **문제정의:** 기존에는 한번만 검색하고 결과를 보여주는 서비스였다. 하지만 유저가 추천결과에 대해서 검색을 심화할수도 있고(”더 조용한 카페 추천”), 혹은 도중에 검색하는동네를 바꾸어서 검색을 할수도있고, 추천된 가게의 메타데이터에 대해서 질문을 할수도 있을거라고 예상했다. 따라서 이전의 context를 Pydantic을 이용해서 state로 정의하고, 그 context를 Multi Agent가 참고하면서 추론할 수 있는 로직이 필요했다. ### 주요 기능 - 이전의 추천 정보를 Context로 기억하고 새로운 카페를 추천 - 추천된 카페에 대한 메타정보 질문 시 DB를 retrieval해서 답변 - 이미 추천한 장소는 재추천하지 않음 ### AgentState 데이터 모델 (`backend/agents/state.py`) ```python class AgentState(BaseModel): session_id: str # 세션 고유 ID user_query: str # 현재 사용자 쿼리 # === Shared Memory (턴 간 유지) === history_place_ids: List[int] # 이미 추천된 장소 ID (중복 방지) last_recommendations: List[Dict] # 최근 추천 결과 (QnA 참조용) current_location_filter: List[str] # 현재 동네 필터 ["서교", "연남"] previous_hyde_query: str # 직전 HyDE 쿼리 (분위기 맥락 유지) file_path: str # 업로드된 이미지 경로 # === 현재 턴 상태 === intent: AgentIntent # SEARCH | FEEDBACK | QNA final_response: Dict # 최종 응답 ``` `AgentState`는 Pydantic 모델로, 대화 세션의 모든 상태를 담고 있다. `history_place_ids`는 이미 추천한 장소를 기억해 중복 추천을 방지하고, `previous_hyde_query`는 이전의 HyDE Query를 저장한것으로 “더 조용한 곳” 같은 피드백 시 이전 분위기 맥락을 유지하는 데 사용한다. 모든 에이전트가 이 상태 객체를 공유한다. ### ContextManager (`backend/agents/context_manager.py`) DuckDB 기반의 영속적 상태 관리 싱글톤 | 메서드 | 입력 | 동작 | 출력 | | --- | --- | --- | --- | | `get_or_create_state(session_id, query)` | session_id, user_query | DB에서 기존 세션 로드 또는 신규 생성 | AgentState | | `get_state(session_id)` | session_id | 현재 세션 상태 조회 | AgentState | | `save_state(state)` | AgentState | 변경된 상태를 DuckDB에 UPSERT | None | | `update_history(state, recs)` | state, 추천 결과 | history_place_ids에 추가 (중복 방지) | None | **저장 구조 (DuckDB)**: ```sql CREATE TABLE sessions ( session_id VARCHAR PRIMARY KEY, state_json VARCHAR, -- AgentState를 JSON으로 직렬화 updated_at TIMESTAMP ); ``` 세션 상태를 DuckDB 테이블에 JSON 문자열로 직렬화하여 저장한다. 서버가 재시작되어도 `session_id`를 기반으로 이전 대화 상태를 복원할 수 있어 영속적인 대화 컨텍스트를 유지할 수 있다. **상태 저장 로직**: ```python def save_state(state: AgentState): state_json = state.model_dump_json() con.execute(""" INSERT INTO sessions (session_id, state_json, updated_at) VALUES (?, ?, CURRENT_TIMESTAMP) ON CONFLICT (session_id) DO UPDATE SET state_json = excluded.state_json, updated_at = excluded.updated_at """, (state.session_id, state_json)) ``` Pydantic의 `model_dump_json()`으로 상태를 JSON 문자열로 변환한 후, DuckDB의 UPSERT 구문(`INSERT ... ON CONFLICT DO UPDATE`)으로 저장한다. 같은 `session_id`가 있으면 업데이트, 없으면 새로 생성된다. --- ## ADK 마이그레이션 ### 현재 구현된 Agent | Agent | 역할 | 입력 | 출력 | | --- | --- | --- | --- | | **Router** | 유저 의도 파악 | user_query | AgentIntent (SEARCH/FEEDBACK/QNA) | | **Location** | 랜드마크 → 행정동 변환 | user_query | region_names 리스트 | | **Search** | 카페 검색 실행 | state (필터, 히스토리 포함) | recommendations 리스트 | | **QnA** | 장소 메타정보 답변 | state (last_recommendations 참조) | 답변 메시지 | ### 왜 ADK? - **Intent-Based Routing**: 사용자 발화 의도를 `SEARCH`, `FEEDBACK`, `QNA`로 분류 - **LoopAgent**: 에이전트들을 순차 실행하며, `escalate=True` 발생 시까지 반복 - **ADK Viewer**: 웹 기반 디버깅 UI 제공  --- ## 파일별 역할 및 상세 동작  ``` backend/ ├── main.py # FastAPI 앱 설정 & 서버 시작 ├── api/ │ └── chat.py # API 엔드포인트 (Entry Point) ├── workflow.py # LoopAgent 정의 (에이전트 순서) ├── lib/ │ └── google_adk_agents.py # ADK Wrapper (BaseAgent 구현) ├── agents/ │ ├── router.py # 의도 분류 로직 │ ├── location_agent.py # 위치 파싱 로직 │ ├── qna_agent.py # Q&A 로직 │ ├── context_manager.py # 상태 관리 │ └── state.py # AgentState 모델 └── services/ ├── search_service.py # HyDE + Retrieval ├── reasoning.py # 추천 이유 생성 └── suggestion.py # 추천 질문 생성 ``` 백엔드 로직은 **API 계층(`backend/api`)**, **워크플로우 계층(`backend/lib`)**, **핵심 로직 계층(`backend/agents`)**, **서비스 계층(`backend/services`)**으로 나뉜다. ### Entry Point (`backend/api/chat.py`) ```python @router.post("/", response_model=RecommendedPlacesResponse) async def create_chat(session_id, user_query, file): # 1. 상태 로드/생성 init_state = context_mgr.get_or_create_state(session_id, user_query) init_state.file_path = file_path_disk context_mgr.save_state(init_state) # 2. ADK Runner 설정 & 실행 runner = InMemoryRunner(agent=adk_app, app_name="vibe_pick") user_msg = types.Content(role="user", parts=[types.Part(text=user_query)]) async for event in runner.run_async(user_id, session_id, new_message=user_msg): pass # 에이전트 순차 실행 # 3. 결과 추출 final_state = context_mgr.get_state(session_id) recommendations = final_state.final_response.get("recommendations", []) # 4. 추천 질문 생성 (Suggestion) suggestions = generate_suggestions(user_query, place_names[:3], hyde_query) # 5. 응답 반환 return RecommendedPlacesResponse( recommendations=recommendations, suggestions=suggestions, ... ) ``` API의 엔트리포인트다. 먼저 `ContextManager`로 세션 상태를 로드/생성한 후, ADK의 `InMemoryRunner`를 통해 LoopAgent를 실행한다. 에이전트들이 순차적으로 실행되고, 완료되면 `final_state`에서 결과를 추출한다. 마지막으로 `generate_suggestions()`를 호출해 다음 추천 질문을 생성하여 응답에 포함한다. ### Workflow (`backend/workflow.py`) ```python from google.adk.agents.loop_agent import LoopAgent router = ADKRouterAgent(name="router") location = ADKLocationAgent(name="location") search = ADKSearchAgent(name="search") qna = ADKQnAAgent(name="qna") app = LoopAgent( name="vibe_pick_agent", sub_agents=[router, location, search, qna], max_iterations=5 # 무한루프 방지를 위한 안전장치 ) ``` ADK의 `LoopAgent`를 사용해 에이전트 실행 순서를 정의한다. 배열 순서대로 Router → Location → Search → QnA가 실행되며, 중간에 `escalate=True` 이벤트가 발생하면 루프가 종료된다. ### ADKRouterAgent (`backend/lib/google_adk_agents.py`) ```python async def _run_async_impl(self, ctx: InvocationContext): session_id = ctx.session.id # 1. 텍스트/이미지 추출 user_query = "" image_path = None for part in ctx.user_content.parts: if getattr(part, "text", None): user_query += part.text if getattr(part, "inline_data", None): # 이미지 저장: temp_images/{uuid}.jpg image_path = save_image(part.inline_data) # 2. 상태 로드 state = context_mgr.get_or_create_state(session_id, user_query) state.file_path = image_path # 3. 라우팅 실행 intent = self.router_logic.route(state) # Router.route() 호출 state.intent = intent # SEARCH | FEEDBACK | QNA # 4. 상태 저장 context_mgr.save_state(state) yield Event(author=self.name, custom_metadata={"type": "routed"}) ``` LoopAgent에서 가장 먼저 실행되는 에이전트이다. ADK의 `ctx.user_content`에서 텍스트와 이미지를 추출하고, `Router.route()` 메서드를 호출해 사용자 의도(SEARCH, FEEDBACK, QNA 중 하나)를 판단한다. 판단 결과를 `state.intent`에 저장하여 이후 에이전트들이 참조할 수 있게 한다. ### ADKLocationAgent ```python async def _run_async_impl(self, ctx: InvocationContext): state = context_mgr.get_state(ctx.session.id) # Intent가 SEARCH/FEEDBACK일 때만 실행 if state.intent not in [AgentIntent.SEARCH, AgentIntent.FEEDBACK]: return # 조기 반환 # 위치 파싱 loc_result = self.loc_agent.run(state.user_query) # {"is_location_query": true, "region_names": ["서교", "연남"]} new_filters = loc_result.get("region_names", []) if new_filters: state.current_location_filter.extend(new_filters) state.current_location_filter = list(set(state.current_location_filter)) context_mgr.save_state(state) yield Event(author=self.name, custom_metadata={"type": "location_parsed"}) ``` Router가 판단한 `intent`가 SEARCH나 FEEDBACK일 때만 동작하고, QNA면 바로 반환한다(QnA에서는 location의 변화가 없으므로). `LocationAgent.run()`을 호출해 쿼리에서 지역명을 추출하고, 새로 발견된 지역을 `current_location_filter`에 추가한다. `list(set(...))`으로 중복을 제거한다. ### ADKSearchAgent ```python async def _run_async_impl(self, ctx: InvocationContext): state = context_mgr.get_state(ctx.session.id) if state.intent not in [AgentIntent.SEARCH, AgentIntent.FEEDBACK]: return # 이전 HyDE 컨텍스트 참조 (FEEDBACK 시 분위기 누적) prev_context = state.previous_hyde_query # 검색 실행 hyde_query, recommendations = await hyde_search( state.user_query, # "더 조용한 곳" state.file_path, # 업로드된 이미지 state.current_location_filter, # ["서교", "연남"...] state.history_place_ids, # 이미 추천한 장소 제외 prev_context # "홍대 모던한 인테리어..." (이전 HyDE) ) # 상태 업데이트 state.previous_hyde_query = hyde_query context_mgr.update_history(state, recommendations) state.final_response = {"hyde_query": hyde_query, "recommendations": recommendations} context_mgr.save_state(state) # 루프 종료 (escalate=True) yield Event( author=self.name, content=types.Content(parts=[types.Part(text=output_text)]), actions=EventActions(escalate=True) ) ``` 실제 검색을 수행하는 에이전트다. `hyde_search()` 함수에 현재 쿼리, 이미지, 지역 필터, 제외할 장소 ID 목록, 이전 HyDE 쿼리를 전달한다. `history_place_ids`를 통해 이미 추천한 장소를 제외하고, `prev_context`를 통해 이전 분위기 맥락과 결합된 새 HyDE 쿼리를 생성한다. 검색이 완료되면 `escalate=True`로 LoopAgent를 종료시킨다. ### QnAAgent.run(state: AgentState) → dict ```python def run(self, state: AgentState) -> dict: query = state.user_query # "첫 번째 카페 주차 돼?" # 1. 대상 장소 식별 (LLM 사용) target_places = self._identify_target_places(query, state.last_recommendations) # [{"place_id": 101, "place_name": "블루보틀 연남점"}] if not target_places: return {"message": "참고할 추천 결과가 없어서 답변드리기 어려워요."} # 2. 장소 상세 정보 조회 (DB) all_details = [] for place in target_places: details = self._fetch_place_details(place['place_id']) # places: address, business_hours, contact # amenities: 주차, 예약, 와이파이 등 10개 항목 # reviews: summary, keywords # menus: name, price all_details.append(f"=={place['place_name']} ==\n{details}") # 3. LLM 답변 생성 answer = self._generate_answer(query, place_names, combined_details) # "네, 주차 가능합니다. 건물 지하주차장 이용 가능해요." return {"message": answer, "related_place_id": target_places[0]['place_id']} ``` QnA 에이전트는 추천된 가게의 메타데이터에 대한 질문을 답변하는 에이전트로 3단계로 동작한다. 먼저 `_identify_target_places()`에서 LLM을 사용해 “첫 번째”, “두 번째” 같은 표현이 가리키는 실제 장소를 식별한다. 그 다음 `_fetch_place_details()`로 해당 장소의 주소, 편의시설, 리뷰, 메뉴 정보를 DB에서 조회한다. 마지막으로 `_generate_answer()`에서 조회된 정보를 바탕으로 LLM이 자연스러운 답변을 생성한다. - **_identify_target_places() 프롬프트**: ``` "너는 사용자의 질문이 '추천 장소 목록' 중 어떤 장소를 지칭하는지 식별하는 분류기야. 아래 목록을 보고, 질문이 가리키는 장소들의 ID를 JSON 리스트로 반환해." [추천 장소 목록] 1. 블루보틀 연남점 (ID: 101) 2. 앤트러사이트 (ID: 102) 3. 프리베 (ID: 103) → 출력: [101] ``` LLM에게 추천 목록과 함께 사용자 질문을 전달하면, “첫 번째” → ID 101, “두 번째와 세 번째” → [102, 103] 처럼 해당하한다. “모두”, “전부” 같은 표현이면 전체 ID를 반환하도록 프롬프트에 명시되어 있다. --- ## Context 기반 추천 질문 생성 (Suggestion) **문제정의:** 유저가 어떤 검색을 해야할지 잘 모르겠는 상황이 있을거라고 생각했다. 따라서 이전의 유저의 요구를 Context로 이용해서 다음 질문을 예측하는 로직을 추가해서 챗봇에 추가했다. **기능:** 검색 완료 후, 사용자가 다음에 물어볼 법한 질문 4개를 자동 생성 ### generate_suggestions() (`backend/services/suggestion.py`) **입력(Context)**: `user_query` =“홍대 조용한 카페” `place_names` = [“블루보틀 연남점”, “앤트러사이트”, “프리베”] `hyde_query` =“홍대 연남동 조용하고 넓은 우드톤 카페…” 유저의 원본 쿼리와 hyde쿼리를 가져와서 유저의 의도를 파악하도록 했고, 이전에 추천된 가게의 이름을 `place_name`으로 제공해주었다. **처리 흐름**: ```python def generate_suggestions(user_query, place_names, hyde_query=None) -> list[str]: # 1. Context 포맷팅 place_str = ', '.join(place_names[:3]) user_content = f"검색어:{user_query}\n추천 장소:{place_str}\n분위기:{hyde_query or '없음'}" # 2. 시스템 프롬프트 system_prompt = """너는 카페 추천 서비스의 대화 어시스턴트야. 사용자가 카페 추천을 받았어. 사용자가 다음에 물어볼 법한 질문 4개를 생성해줘. [질문 유형 - 반드시 다양하게 섞어서] 1. 장소 상세 질문: 주차, 메뉴, 영업시간 등 2. 결과 조정 요청: 더 조용한 곳, 더 넓은 곳, 분위기 다른 곳 등 [규칙] - 각 질문은 30자 이내로 짧게 - 자연스러운 구어체 ("첫 번째 카페 주차 가능해?", "더 아늑한 곳 없어?") - 순수 JSON 배열만 출력: ["질문1", "질문2", "질문3", "질문4"] """ # 3. Clova API 호출 (temperature=0.7 다양성 확보) payload = { "messages": [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_content} ], "temperature": 0.7, "maxTokens": 100 } res = requests.post(clova_api_url, headers=headers, json=payload) content = res.json()['result']['message']['content'] # 4. JSON 파싱 (마크다운 코드블록 제거) suggestions = extract_json_array(content) # 5. Fallback (4개 미만 시 기본 질문으로 채움) if len(suggestions) < 4: defaults = ["주차 가능해?", "메뉴 추천해줘", "더 조용한 곳은?", "영업시간 알려줘"] return (suggestions + defaults)[:4] return suggestions[:4] ``` 검색 결과의 Context(검색어, 추천 장소 이름, 분위기 키워드)를 조합해 LLM에 전달하고, 사용자가 다음에 물어볼 법한 자연스러운 질문 4개를 생성한다. `temperature=0.7`로 설정해 다양한 질문이 생성되도록 하고, LLM 응답이 4개 미만이면 fallback으로 기본 질문으로 채운다. 질문 유형은 QNA(장소 상세)와 FEEDBACK(결과 조정)이 섞이도록 프롬프트에 명시되어 있어, 사용자가 클릭하면 자연스럽게 다음 대화로 이어진다.  **출력 예시**:["첫 번째 카페 주차 가능해?", "두 번째 카페 메뉴 추천해줘", "더 넓은 곳 없어?", "영업시간 알려줘"] ### 질문 유형 설계 의도 | 생성되는 질문 유형 | Router 분류 | 처리 Agent | | --- | --- | --- | | 장소 상세 질문 | QNA | QnAAgent | | 결과 조정 요청 | FEEDBACK | SearchAgent | → 사용자가 추천 질문 클릭 시, Router가 자동 분류하여 적절한 에이전트 실행 ### 호출 시점 (`chat.py`) ```python # 검색 완료 후 suggestions 생성 suggestions = None if recommendations: place_names = [p.place_name for p in recommendations[:3]] try: suggestions = generate_suggestions( user_query=user_query, place_names=place_names, hyde_query=hyde_query ) except Exception as e: suggestions = ["주차 가능해?", "메뉴 추천해줘", "더 조용한 곳은?", "영업시간 알려줘"] return RecommendedPlacesResponse( ... suggestions=suggestions ) ``` 추천 결과가 있을 때만 `generate_suggestions()`를 호출한다. 생성된 추천 질문은 프론트엔드에서 버튼 형태로 표시된다. --- ## 전체 데이터 흐름도  전체 흐름을 요약하면 사용자 요청이 들어오면 LoopAgent가 Router → Location → Search/QnA 순서로 에이전트를 실행한다. 각 에이전트는 `state.intent`를 확인해 자신이 처리해야 할 요청인지 판단하고, 해당되지 않으면 조기 반환한다. 최종적으로 검색 결과와 추천 질문을 함께 응답한다. --- ## 실험 및 검증 ### Case 1(Feedback): 검색된 카페의 분위기가 마음에 들지 않아서 추가적인 분위기를 제공할때 동작: Location(동네)는 변경하지 않고 이전의 HyDE 쿼리에 추가로 HyDE쿼리를 생성해서 두 HyDE쿼리를 합친 후 다시 검색함   > 상황: 성수동 검색 결과가 마음에 안 들어서 "더 개방감 있는 분위기로 찾아줘"라고 했을 때 > 1. **Router Agent**: "좀 더", "분위기로" 같은 표현과 이전 맥락(Context)을 보고 의도를 으로 분류. 2. **Location Agent**: 의도가 이므로 동작하지만, 새로운 지명이 없으므로 **기존의 `current_location_filter`("성동구 성수동")를 그대로 유지**. 3. **Search Agent**: - `FEEDBACK` 의도일 경우, 이전 검색을 위해 생성했던 시각적 묘사(HyDE)를 가져옴 - 새로운 쿼리의 HyDE를 합쳐서 **더 구체적인 새로운 HyDE 쿼리**를 생성합니다. (예: "모던한... + 밝은 자연광이 들어오는...") - **Retriever**: 기존 위치 필터("성수동") 내에서 새로운 HyDE 쿼리와 유사한 이미지를 가진 장소를 재검색 ### Case 2 (QnA): 검색된 카페에 대한 메타정보를 물어볼때  > 상황: 검색된 결과 중 "첫 번째 곳 주차 돼?"라고 물었을 때 > 1. **Router Agent**: "사람들의 평은 어때?", 같은 의도를 인식하여 의도를 로 분류 2. **Location Agent / Search Agent**: 의도가 이므로 **동작하지 않고 건너뜀.** 3. **QnA Agent**: - **Selector (LLM)**: 질문("첫 번째 곳")과 (이전 검색 결과 3개)를 보고 "1번 장소(ID: 101)"를 대상으로 식별 - **DB Fetch**: 해당 장소의 **amenities**, **places** 테이블을 조회하여 주차 정보 등을 가져옴. - **Generator (LLM)**: "이 장소는 주차가 가능합니다"라는 답변을 생성하여 사용자에게 전달. ### Case 3(new Search): 이전의 지역이 아니라 새로운 지역에 대해서 검색하고 싶을때  > 상황: "강남역 근처 카공하기 좋은 곳 추천해줘"라고 했을 때 > 1. **Router Agent**: - 먼저 **Location Agent**를 호출. - LLM이 명확한 지역을 인식하고(”강남역”) Intent를 새로운 지역에 대한 Search로 인식함 2. **Location Agent**: - "강남역"을 **["강남구 역삼동", "서초구 서초동"]** 등의 행정동 리스트로 변환하여 를 **덮어씀(Overwrite).** 3. **Search Agent**: - 변경된 필터(역삼/서초) 내에서 검색하여 결과를 반환. --- ## 완료된 기능 - [x] 인풋 쿼리에서 동을 파싱하여 해당 동네 내에서만 검색 - [x] Stateful 채팅으로 이전 Context 기억 - [x] Context에 알맞는 예상 질문 생성 (Suggestion) - [x] QnA Agent로 장소 메타정보 답변 - [x] 이미 추천한 장소 중복 방지 (history_place_ids) - [x] 분위기 피드백 시 HyDE 누적 (previous_hyde_query) ### [이미지기반 카페추천 프로젝트] Apache Airflow 파이프라인 자동화 구현 - Canonical URL: https://hyejunl33.github.io/projects/2026-01-30-Airflow_Pipeline/ - Collection: Project - Published: 2026-01-30 - Tags: 이미지기반 카페추천 프로젝트, Apache Airflow 파이프라인 자동화 구현 # Apache Airflow 파이프라인 자동화 구현 ## 목차 1. [도입 배경 및 문제 정의](#도입-배경-및-문제-정의) 2. [파이프라인 아키텍처](#파이프라인-아키텍처) 3. [DAG 설계 및 구현](#dag-설계-및-구현) 4. [병렬 처리 및 최적화](#병렬-처리-및-최적화) 5. [Task 의존성 및 실행 흐름](#task-의존성-및-실행-흐름) 6. [실행 결과 및 성능 개선](#실행-결과-및-성능-개선) --- ## 도입 배경 및 문제 정의 ### 기존 문제점 서울 전역의 카페 데이터를 수집하고 처리하는 파이프라인을 **수동으로 단계별 순차 실행**하고 있었음. 크롤링이 가장 오래걸리는 작업인데, 서울내 모든 동네(약 420개)에 대해서 크롤링이 끝나야만 다음단계로 넘어가는것은 매우 비효율적임. ``` ❌ 기존 방식: 단계별 순차 실행 (수동) [Step 0] 전체 동네 크롤링 완료 대기 ↓ (전체 완료 후) [Step 1] 전체 동네 대표 이미지 추출 ↓ (전체 완료 후) [Step 2] 전체 동네 VLM 묘사 생성 ↓ (전체 완료 후) [Step 3] 전체 동네 리뷰 요약 ↓ (전체 완료 후) [Step 4] 전체 동네 임베딩 생성 ↓ DB 적재 → 각 단계가 "전체 동네" 완료를 기다려야 다음 단계 시작 → 앞서 완료된 동네도 뒤처진 동네를 기다리며 유휴 상태 → 한 단계 실패 시 전체 재실행 필요 ``` ### 문제점 요약 | 문제 | 설명 | | --- | --- | | **단계별 병목** | 한 단계가 전체 동네에서 완료되어야 다음 단계 시작 가능 | | **유휴 시간 발생** | 빨리 끝난 동네도 느린 동네를 기다리며 대기 | | **수동 개입** | 각 단계 완료 후 다음 단계 수동 실행 필요 | | **실패 복구 어려움** | 중간 실패 시 해당 단계 전체 재실행 | | **스케줄링 없음** | 정기적인 자동 실행 불가 | ### 해결 방안: Apache Airflow 도입 **핵심 변경**: 단계별 전체 처리 → **동네 단위 독립 파이프라인** - **Task 의존성을 DAG로 정의**하여 동네별 파이프라인 자동 실행 - **동네 단위 병렬 처리**: 완료된 동네부터 다음 단계 즉시 진행 (대기 X) - **스케줄링**으로 정기적 자동 실행 - **실패 Task만 재시도**하여 복구 효율화 --- ## 파이프라인 아키텍처 ### 전체 데이터흐름  ### 파일 구조 ``` src/pipeline/ ├── _00_image_extraction.py # 이미지 다운로드 ├── _01_extract_representative_images.py # CLIP 대표 이미지 ├── _02_generate_vlm_descriptions.py # VLM 묘사 생성 ├── _03_summarize_reviews.py # 리뷰 요약 ├── _04_generate_embeddings.py # 임베딩 생성 └── airflow/ └── dags/ ├── cafe_monthly_full_pipeline.py # 월간 전체 파이프라인 └── cafe_weekly_review_pipeline.py # 주간 리뷰 업데이트 ``` ### 단계별 스크립트 설명 | Step | 스크립트 | 역할 | 사용 모델 | | --- | --- | --- | --- | | 0 | `_00_image_extraction.py` | 크롤링된 JSON에서 이미지 URL 추출 및 다운로드 | - | | 1 | `_01_extract_representative_images.py` | 카페별 대표 이미지 5장 선정 | CLIP | | 2 | `_02_generate_vlm_descriptions.py` | 이미지 분위기 묘사 텍스트 생성 | Qwen2.5-VL-7B | | 3 | `_03_summarize_reviews.py` | 리뷰 텍스트 요약 | Gemma3 | | 4 | `_04_generate_embeddings.py` | 이미지/텍스트 벡터 임베딩 | SigLIP v2 | --- ## DAG 설계 및 구현 ### 2개의 DAG 설계 서로 다른 주기와 목적을 가진 **2개의 DAG**을 설계함. | DAG | 스케줄 | 목적 | 처리 범위 | | --- | --- | --- | --- | | `cafe_monthly_full_pipeline` | 매월 1일 03:00 | 전체 데이터 갱신 | 크롤링 + 이미지 + 임베딩 | | `cafe_weekly_review_pipeline` | 매주 토요일 02:00 | 리뷰만 업데이트 | 리뷰 크롤링 + 요약 | ### 월간 전체 파이프라인 (`cafe_monthly_full_pipeline.py`) ```python from datetime import datetime, timedelta from airflow import DAG from airflow.operators.bash import BashOperator from airflow.sensors.filesystem import FileSensor from airflow.decorators import task, task_group with DAG( 'cafe_monthly_full_pipeline', default_args=default_args, description='서울 카페 월간 파이프라인 (Streaming & GPU Optimized)', schedule_interval='0 3 1 * *', # 매월 1일 03:00 (KST) start_date=datetime(2026, 1, 25), catchup=False, tags=['cafe', 'monthly', 'streaming', 'gpu_pool'], max_active_runs=1, ) as dag: ``` 월간 전체 파이프라인은 크론표현식으로 매월 1일 새벽 3시에 자동 실행됨. `max_active_runs=1`로 동시 실행을 방지하고, `catchup=False`로 과거 미실행 건은 스킵함. ### 주간 리뷰 파이프라인 (`cafe_weekly_review_pipeline.py`) ```python with DAG( 'cafe_weekly_review_pipeline', default_args=default_args, description='서울 카페 주간 리뷰 업데이트 파이프라인 (text-only)', schedule_interval='0 2 * * 6', # 매주 토요일 02:00 (KST) start_date=datetime(2026, 1, 25), catchup=False, tags=['cafe', 'weekly', 'review', 'text-only'], max_active_runs=1, ) as dag: # 리뷰만 크롤링 (이미지 스킵) crawl_reviews = BashOperator( task_id='crawl_reviews', bash_command=f''' cd{CRAWLER_PATH} &&\ python main.py --mode parallel --target text-only ''', ) # 리뷰 요약 summarize = BashOperator( task_id='summarize_reviews', bash_command=f'cd{PIPELINE_PATH} && python _03_summarize_reviews.py', ) # DB 업데이트 seed_reviews = BashOperator( task_id='seed_reviews', bash_command=f'cd{PROJECT_PATH} && python backend/core/seed_weekly_reviews.py', ) # 의존성 정의 crawl_reviews >> summarize >> seed_reviews ``` 주간 파이프라인은 **리뷰만 업데이트함**. 리뷰 업데이트를 통해 가게 정보 최신화. 이미지 처리 단계(Step 0, 1, 2, 4)를 스킵하고 리뷰 요약(Step 3)만 실행하여 실행 시간을 대폭 단축. --- ## 병렬 처리 및 최적화 ### 1. Dynamic Task Mapping - 동네별 병렬 처리 ```python # 1. 처리할 동네 목록 동적 로드 @task def get_target_dongs(): dong_file = f"{CRAWLER_PATH}/seoul_parts/seoul_dongs.json" with open(dong_file, 'r', encoding='utf-8') as f: dongs = json.load(f) return sorted(dongs) # ['강남구_개포1동', '강남구_개포2동', ...] # 2. 동네별 Task Group 정의 @task_group(group_id='process_dong') def process_neighborhood(dong_name): # 각 동네별 5단계 파이프라인 step0 >> step1 >> step2 >> step3 >> step4 # 3. Dynamic Mapping으로 병렬 확장 target_dongs = get_target_dongs() processed_groups = process_neighborhood.expand(dong_name=target_dongs) ``` `expand()`를 사용한 **Dynamic Task Mapping**으로, 동네 목록의 크기에 따라 Task가 동적으로 생성됨. 만약 10개 동네면 10개의 독립적인 Task Group이 병렬로 실행됩니다. 이를 통해 동네 수가 늘어나도 코드 수정 없이 자동으로 확장. ### 병렬 처리 시각화  ### 2. Streaming Pipeline - FileSensor 크롤링이 완료된 동네부터 **즉시 처리 시작** (전체 크롤링 완료 대기 X) ```python @task_group(group_id='process_dong') def process_neighborhood(dong_name): # A. 파일 감지 - 해당 동네 JSON이 생성되면 다음 단계 시작 wait_for_json = FileSensor( task_id='wait_for_json', filepath=f"{RAW_JSON_DIR}/{dong_name}.json", fs_conn_id='fs_default', mode='reschedule', # 대기 중에는 Worker 슬롯 반환 poke_interval=60 * 5, # 5분마다 파일 존재 확인 timeout=60 * 60 * 24, # 최대 24시간 대기 ) # B. 파일 감지 후 처리 시작 step0_download = BashOperator(...) wait_for_json >> step0_download >> step1 >> step2 >> step3 >> step4 ``` `FileSensor`는 지정된 파일이 생성될 때까지 대기함. `mode='reschedule'`로 설정하면 대기 중에 Worker 슬롯을 반환하여 다른 Task가 실행될 수 있음. 크롤링이 빠르게 완료되는 동네부터 순차적으로 처리가 시작되어 **전체 파이프라인 시간이 단축**.  ### 3. GPU Pool - 리소스 관리 GPU를 사용하는 작업들의 동시 실행 수를 제한하여 **OOM(Out of Memory) 방지** ```python # GPU 작업은 별도 풀로 제한 step1_clip = BashOperator( task_id='step1_clip', bash_command=params['cmd_step1'], pool='gpu_pool', # GPU 풀 (슬롯 제한) ) step2_vlm = BashOperator( task_id='step2_vlm', bash_command=params['cmd_step2'], pool='gpu_pool', # GPU 풀 ) step3_summary = BashOperator( task_id='step3_summary', bash_command=params['cmd_step3'], pool='gpu_pool', # GPU 풀 ) step4_embed = BashOperator( task_id='step4_embed', bash_command=params['cmd_step4'], pool='gpu_pool', # GPU 풀 ) ``` Airflow의 **Pool** 기능으로 동시 실행 가능한 Task 수를 제한. 이를 통해 각동네가 병렬로 처리되더라도 Vram을 사용하는 작업은 동시실행을 제한해서 GPU 메모리 부족을 방지. --- ## Task 의존성 및 실행 흐름 ### Task Group 상세 구조 ```python @task_group(group_id='process_dong') def process_neighborhood(dong_name): # 파라미터 준비 @task def prepare_params(name): return { 'sensor_path': f"{RAW_JSON_DIR}/{str(name)}.json", 'cmd_step0': f'cd{PIPELINE_PATH} && python _00_image_extraction.py --dong-name{str(name)}', 'cmd_step1': f'cd{PIPELINE_PATH} && python _01_extract_representative_images.py --dong-name{str(name)}', 'cmd_step2': f'cd{PIPELINE_PATH} && python _02_generate_vlm_descriptions.py --dong-name{str(name)}', 'cmd_step3': f'cd{PIPELINE_PATH} && python _03_summarize_reviews.py --dong-name{str(name)}', 'cmd_step4': f'cd{PIPELINE_PATH} && python _04_generate_embeddings.py --dong-name{str(name)}', } params = prepare_params(dong_name) # 파일 감지 wait_for_json = FileSensor(...) # 이미지 다운로드 (Default Pool) step0_download = BashOperator( task_id='step0_download', bash_command=params['cmd_step0'], pool='default_pool', ) # GPU 작업 체인 (GPU Pool) step1_clip = BashOperator(task_id='step1_clip', pool='gpu_pool', ...) step2_vlm = BashOperator(task_id='step2_vlm', pool='gpu_pool', ...) step3_summary = BashOperator(task_id='step3_summary', pool='gpu_pool', ...) step4_embed = BashOperator(task_id='step4_embed', pool='gpu_pool', ...) # 의존성 체인 wait_for_json >> step0_download >> step1_clip >> step2_vlm >> step3_summary >> step4_embed ``` 각 동네는 독립적인 Task Group으로 처리. `prepare_params()`에서 동네 이름을 받아 각 스크립트의 `--dong-name` 인자로 전달. 이미지 다운로드는 네트워크 I/O 위주라 `default_pool`을, GPU 작업들은 `gpu_pool`을 사용. ### 전체 DAG 의존성 ```python # 실행 흐름 target_dongs = get_target_dongs() processed_groups = process_neighborhood.expand(dong_name=target_dongs) # 크롤링과 병렬로 진행, 모든 처리 완료 후 DB 적재 crawl_full >> seed_db processed_groups >> seed_db ``` `crawl_full`(크롤링)과 `processed_groups`(동네별 처리)가 모두 완료되면 `seed_db`(DB 적재)가 실행됨. 크롤링은 백그라운드에서 계속 진행되고, 각 동네는 FileSensor로 JSON 파일이 생성되면 바로 처리를 시작.  --- ## 실행 결과 및 성능 개선 ### 이전 vs 이후 비교 | 항목 | 이전 (단계별 순차) | 이후 (Airflow) | | --- | --- | --- | | **실행 방식** | 수동 스크립트 실행 | 자동 스케줄링 | | **처리 단위** | 단계별 전체 동네 | 동네별 독립 파이프라인 | | **크롤링 대기** | 전체 완료 후 다음 단계 | Streaming (즉시 시작) | | **유휴 시간** | 느린 동네 대기 (블로킹) | 각 동네 독립 진행 | | **GPU 관리** | 수동 | Pool로 자동 제한 | | **실패 복구** | 해당 단계 전체 재실행 | 실패 Task만 재시도 | | **모니터링** | 로그 수동 확인 | Airflow UI | ### 성능 개선 효과 기존에는 Step1이 “모든 동네에서 완료”되어야 Step2가 시작되었지만, 이제는 “동네1의 Step1”이 끝나면 바로 “동네1의 Step2”가 시작됨. 빠르게 완료된 동네가 느린 동네를 기다리지 않음으로써 가장 큰 병목이었던 크롤링과정에서의 병목을 해결. --- ## 완료된 기능 - [x] Apache Airflow DAG로 파이프라인 자동화 - [x] Dynamic Task Mapping으로 동네별 병렬 처리 - [x] FileSensor로 Streaming 파이프라인 구현 - [x] GPU Pool로 리소스 관리 (OOM 방지) - [x] 월간/주간 스케줄링 자동 실행 - [x] 실패 Task 자동 재시도 (retries=2) - [x] Task 성공/실패 콜백 로깅 --- ### [이미지기반 카페추천 프로젝트]네이버지도에서 서울시 카페 전부 크롤링 - Canonical URL: https://hyejunl33.github.io/projects/2026-01-30-Crawler_Documentation/ - Collection: Project - Published: 2026-01-30 - Tags: 이미지기반 카페추천 프로젝트, Crawling # 네이버 지도 서울 카페 분산 크롤러 구현 ## 목차 1. [도입 배경 및 문제 정의](#1-도입-배경-및-문제-정의) 2. [아키텍처 및 핵심 로직](#2-아키텍처-및-핵심-로직) 3. [데이터 추출 전략](#3-데이터-추출-전략) 4. [안정성 및 리소스 관리](#4-안정성-및-리소스-관리) 5. [데이터 스키마 및 저장](#5-데이터-스키마-및-저장) --- ## 도입 배경 및 문제 정의 ### 크롤링 목표 서울시 전역 **424개 행정동**에 위치한 카페 데이터를 정밀하게 수집하여 이미지 기반 카페추천 서비스의 기반 데이터를 구축함. 단순한 장소명 수집을 넘어, 메뉴 이미지, 리뷰, 영업시간, 편의시설 정보 등 상세 메타데이터 확보가 필수적임. ### Playwright 도입 배경 (vs Selenium) 기존 Selenium 방식은 React 기반의 동적 페이지(네이버 지도)를 처리하는 데 구조적 한계가 있어, 최신 자동화 도구인 **Playwright**를 도입함. ### 1. Auto-waiting - **문제**: 네이버 지도는 수시로 DOM을 다시 그리기 때문에, Selenium은 요소를 찾은 직후 ‘요소가 사라짐(Stale Element)’ 에러를 빈번하게 발생시킴. - **해결**: Playwright는 클릭 직전까지 요소가 화면에 고정되고 클릭 가능한 상태인지 **자동으로 대기(Auto-waiting)**함. 이로 인해 `explicit_wait` 남발 없이도 안정적인 클릭이 가능함. ### 2. 효율적인 Iframe 제어 (Frame Locator) - **문제**: 검색 결과(`searchIframe`)와 상세 정보(`entryIframe`)가 서로 다른 iframe에 존재하여, Selenium은 `switch_to.frame`으로 컨텍스트를 계속 오가야 함. - **해결**: Playwright의 **Frame Locator** API를 사용하여 프레임 간 전환 비용 없이 DOM 요소에 즉시 접근함. - *Code*: `self.page.frame_locator("#entryIframe").locator(...)` ### 3. 데이터 추출 빠름 - **문제**: Selenium의 `execute_script`는 대용량 데이터 전송 시 직렬화 병목이 발생함. - **해결**: Playwright는 브라우저 엔진(V8)과 직접 통신하는 `evaluate()` 메서드를 제공함. 이를 통해 수 MB 크기의 `__APOLLO_STATE__` 객체를 지연 없이 즉시 Python 객체로 변환함. ### 기술적 도전 과제 및 해결 방안 | 기술적 문제 (Problem) | 상세 내용 | 해결 방안 (Solution) | | --- | --- | --- | | **대규모 데이터 처리** | 단일 프로세스로 수만 개 페이지 방문 시 실행 시간 과다 소요 | **Multiprocessing**: 동(Dong) 단위로 프로세스를 분할하여 병렬 처리함 | | **메모리 누수 (OOM)** | Chromium 로직 특성상 장시간 실행 시 메모리 사용량 지속 증가 | **3-Tier Protection**: 프로세스(재생성), 브라우저(재시작), 카페(타임아웃) 단위로 다중 리소스 관리함 | | **동적 렌더링** | React 기반 SPA로 DOM 구조가 수시로 변경되고 렌더링 시점 불규칙 | **Hybrid Extraction**: `window.__APOLLO_STATE__` 직접 파싱과 DOM 탐색을 병행함 | | **IP 차단 및 탐지** | 반복적인 자동화 접근 시 CAPTCHA 발생 또는 IP 차단으로 수집 중단 | **Stealth & Auto-Recovery**: User-Agent 위장, 랜덤 딜레이, 3회 실패 시 브라우저 교체함 | --- ## 아키텍처 및 핵심 로직 ### Manager-Worker 패턴 구조 전체 시스템은 작업을 할당하는 **Manager**와 실제 수집을 수행하는 **Worker**로 구성됨. ``` [CrawlerManager] | +--- 파트 파일 로드 (dongs_part_1.json) | +--- Multiprocessing Pool 생성 (num_workers=3) | +--- [Worker Process 1] ──(spawn)──> [Chromium] : "역삼동 카페" 수집 | (작업 완료 후 프로세스 소멸 및 메모리 반환) | +--- [Worker Process 2] ──(spawn)──> [Chromium] : "논현동 카페" 수집 | (작업 완료 후 프로세스 소멸 및 메모리 반환) ``` ### 병렬 처리 구현 (`crawler/manager.py`) ```python def run_parallel(self, part_id, num_workers=3): # ... # maxtasksperchild=1: 각 작업(동 하나)이 끝날 때마다 프로세스를 새로 띄워 # 브라우저 메모리 누적 문제를 원천 차단함. try: with Pool(processes=num_workers, maxtasksperchild=1) as pool: pool.map(_worker_wrapper, tasks) except KeyboardInterrupt: pool.terminate() ``` Python `multiprocessing.Pool`의 `maxtasksperchild=1` 옵션을 사용하여, 하나의 동 작업이 끝나면 해당 프로세스를 완전히 종료하고 새로 생성함. 이는 Chromium이 점유했던 메모리를 OS 수준에서 강제로 회수함으로써 메모리 문제 해결. --- ## 데이터 추출 전략 ### 1. Apollo State 파싱 네이버 지도는 React 앱의 초기 상태를 `window.__APOLLO_STATE__` 변수에 저장함. 이를 직접 파싱 하여 DOM 렌더링을 기다릴 필요 없이 순수한 JSON 데이터를 추출함. **코드 구현 (`crawler/scraper.py`)**: ```python def _get_apollo_state(self): """페이지 소스에 포함된 Apollo State(JSON) 추출""" states_to_check = ["__APOLLO_STATE__", "__PLACE_STATE__", "__INITIAL_STATE__"] for state_name in states_to_check: try: # 브라우저 컨텍스트에서 JS 변수 추출 state_json = frame.evaluate(f"() => window.{state_name} ? JSON.stringify(window.{state_name}) : null") if state_json: data = json.loads(state_json) merged_state.update(data) except: pass return merged_state ``` 화면에 표시되는 텍스트를 긁어오는 방식(Scraping) 대신, 데이터 소스 자체를 추출(Extraction)하므로 DOM 클래스 변경에 영향을 받지 않으며 속도가 매우 빠름. ### 2. DOM Fallback (Secondary Strategy) Apollo State에 없는 최신 정보나 동적으로 로딩되는 데이터(리뷰, 상세 영업시간)는 DOM 탐색으로 보완함. ```python # 이름 추출 실패 시 DOM 선택자로 재시도 if meta["name"] == "Unknown": name_selectors = [ "span.GHAhO", "span.Fc1rA", "span.YwYLL", ".place_name", "._name", "h2.place_name" ] for selector in name_selectors: name_el = frame.locator(selector).first if name_el.is_visible(): meta["name"] = name_el.inner_text().strip() break ``` > **설명**: 네이버 지도의 잦은 클래스명 변경에 대응하기 위해 다양한 CSS 선택자 리스트(`name_selectors`)를 순차적으로 시도하는 Fallback 로직을 구현함. > ### 3. 레이지 로딩(Lazy Loading) 극복 메뉴 사진이나 리뷰는 스크롤 시점에 로딩되므로, JS를 활용한 공격적인 스크롤링을 수행함. ```python # 메뉴 사진 로딩을 위한 강제 스크롤 for _ in range(3): frame.locator("body").evaluate("window.scrollBy(0, 500)") time.sleep(0.3) # 아이템별 스크롤 이동 for item in items: item.scroll_into_view_if_needed() ``` ### 4. 시각 정보 우선순위 (Visual Priority) 카페 추천 서비스 특성상 음식 사진보다 **매장 분위기(Vibe)**가 더 중요한 판단 기준임. 무작위로 사진을 수집하는 대신 ‘내부’ 탭을 우선적으로 탐색함. ```python # 사진 탭 이동 후 '내부' 카테고리 우선 클릭 (crawler/scraper.py) if category: try: cat_btn = frame.locator("a, span").filter(has_text=re.compile(f"^{category}$")).first if cat_btn.is_visible(): cat_btn.click() time.sleep(1) except: pass ``` 사진 탭에 진입하면 기본적으로 전체 사진이 보이지만, 코드에서 명시적으로 **‘내부’** 탭을 찾아 클릭함. 이를 통해 매장 인테리어와 분위기를 파악할 수 있는 이미지를 최우선으로 확보함. --- ## 안정성 및 리소스 관리 장시간 크롤링 시 발생할 수 있는 모든 불안정 요소를 방어함. ### 1. 프로세스 라이프사이클 관리 - 앞서 언급한 `maxtasksperchild=1` 설정을 통해 동 단위 작업 완료 시 프로세스를 초기화함. ### 2. 브라우저 정기 재시작 (`crawler/worker.py`) 동일 프로세스 내에서도 브라우저 인스턴스가 오래 유지되면 느려질 수 있으므로 일정 개수마다 재시작함. ```python BROWSER_RESTART_INTERVAL = 10 # 10개 카페마다 브라우저 재시작 if cafes_since_restart >= BROWSER_RESTART_INTERVAL: print(f"[Worker-{self.dong}] 브라우저 재시작 (메모리 관리)...") self.scraper.stop() time.sleep(2) self.scraper = NaverMapScraper(headless=True) self.scraper.start() cafes_since_restart = 0 ``` 10개의 카페를 수집할 때마다 브라우저를 닫고 새로 엶. 이는 브라우저 내부 캐시와 메모리 파편화를 정리하여 일정한 수집 속도를 유지하게 해줌. ### 3. 타임아웃 핸들링 특정 페이지에서 무한 로딩이 발생할경우, 전체 프로세스가 멈추지 않도록 제한 시간을 둠. ```python @contextmanager def timeout_handler(seconds, cafe_name=""): def _timeout_handler(signum, frame): raise CafeTimeoutError(f"'{cafe_name}' 처리 시간 초과 ({seconds}초)") signal.signal(signal.SIGALRM, _timeout_handler) signal.alarm(seconds) try: yield finally: signal.alarm(0) ``` 크롤링 로직이 3분(180초)을 초과하면 강제로 예외를 발생시키고 다음 카페로 넘어감. --- ## 데이터 스키마 및 저장 수집된 데이터는 엄격한 필드 순서를 가진 JSON으로 저장됨. | 필드명 | 타입 | 설명 | | --- | --- | --- | | `name` | String | 카페 이름 (정규화됨) | | `address` | String | 도로명 주소 | | `description` | String | 업체 소개글 | | `business_hours` | String | 영업시간 (HH:MM - HH:MM 포맷) | | `contact` | String | 전화번호 | | `instagram` | String | 인스타그램 URL | | `amenities` | List | 편의시설 태그 (주차, 와이파이 등) | | `structured_data` | Dict | 주차 여부, 세부 편의시설 구조화 데이터 | | `menus` | List | 메뉴 이름, 가격, 사진 URL, 설명 | | `photos` | List | 매장 내부/외부 사진 URL 리스트 | | `reviews` | List | 방문자 영수증 리뷰 텍스트 리스트 | | `dong_group` | String | 수집 대상 행정동 이름 | **저장 파일 예시**: `data/crawled/seoul/results_part_1_역삼동.json` --- ## 완료된 기능 - [x] **하이브리드 데이터 추출**: Apollo State 파싱과 DOM 탐색 결합으로 데이터 완전성 확보함 - [x] **멀티프로세싱 병렬 처리**: 동 단위 프로세스 분할 및 `maxtasksperchild=1` 적용함 - [x] **안정적 메모리 관리**: 10개 카페 단위 브라우저 재시작 로직 구현함 - [x] **예외 처리 및 자동 복구**: 타임아웃(180초) 및 연속 실패 시 자동 재시작함 - [x] **동적 컨텐츠 수집**: 메뉴 사진, 방문자 리뷰 더보기 자동 클릭 및 스크롤링함 - [x] **광고 필터링**: 검색 결과 상단의 광고(‘광고’ 뱃지) 자동 식별 및 스킵함 ### [이미지기반 카페추천 프로젝트] CLIP으로 이미지 전처리 - Canonical URL: https://hyejunl33.github.io/projects/2026-01-30-Preprocessing-with-CLIP/ - Collection: Project - Published: 2026-01-30 - Tags: 이미지기반 카페추천 프로젝트, CLIP으로 이미지 전처리 # CLIP으로 이미지 전처리 ## 문제정의 크롤링된 가게 이미지에 노이즈가 너무 많다. 서비스 특성상 가게의 분위기를 나타내는 사진이 DB에 있어야 하고, DB에 있는 사진과 인풋으로 들어온 사진의 임베딩을 코사인유사도를 이용해서 비교한다. 그런데 가게 이미지 50장을 크롤링해온 결과에서 대표사진 5장을 뽑을때, 노이즈를 제거하고, 해당 가게의 ‘분위기’를 나타내는 사진만 선정해야한다. 따라서 ‘분위기’를 어떤메트릭으로 정의하고, 선정할것인지가 문제였다. ### 오늘의집 케이스스터디 [오늘의집에서도 비슷한 문제가 있었다.](https://www.bucketplace.com/post/2023-05-22-%EC%9C%A0%EC%82%AC-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%B6%94%EC%B2%9C-%EA%B0%9C%EB%B0%9C-1-%EB%B9%84%EC%8A%B7%ED%95%9C-%EA%B3%B5%EA%B0%84/) 오늘의집에서도 주어진 인테리어와 유사한 다른 이미지 검색을 위해서 VGG16모델을 학습시키는 모델을 개발했는데, Finetuning시키는 데이터셋을 직접 tagging하는 방법을 사용했다. 우리의 case에서 clip을 이용해서 ‘분위기’를 나타내는 대표사진 5장만 걸리낼 수 있는 메트릭 설정만 잘한다면, finetuning없이 프롬프트만으로 걸러낼 수 있을거라고 생각했다. ## 이미지 전처리 기존방식 팀원이 CLIP을 이용해서 대표 이미지 5장만 뽑는 로직을 만들어서 파이프라인안에 잘 통합되어있었다. 그런데, 어느정도 프로젝트를 완성시키고 MVP결과를 확인해보니, 검색결과에 너무 ‘분위기’와는 관련없는 결과가 많이 등장함을 확인했다. 따라서 기존에 대표이미지 5장을 선정하는 로직을 개선해서, 최대한 ‘분위기’를 나타내는 사진만 대표이미지로 선택하는 목표를 설정하고 이를 해결해나갔다.  ### 기존방식 - 인테리어 vs 음식점수를 프롬프트에 대한 softmax 확률값을 점수로 매김 - 점수가 가장 높은 5개가 대표이미지로 선정됨. - 후보군선정 - `interior_score` > `food_score` - 예외. 모두 인테리어점수가 음식점수보다 낮다면 `interior_score`가 높은 순서 - ****대표성 점수 계산 1. 중심벡터 만들기: 선정된 후보군 이미지들의 임베딩 벡터를 모두 평균내어 하나의 '중심 벡터만들기 2. 유사도 계산: 각 후보 이미지의 중심벡터에 대한 Cosine Similarity를 계산 - **최종 점수 산출** - Final Score=(0.6×Interior Score)+(0.4×Similarity to Centroid) **Top-K를 뽑는 근거** - 0.6을 Weight로 줘서 인테리어 점수와 가까운가? 판단 - 0.4를 Weight로 줘서 Top5 이미지의 평균과 얼마나 가까운가 판단 ## **기존 방식의 맹점** 1. Food 점수와 인테리어 점수가 일관되지 않다. 즉 같은 사진이더라도 점수가 다른경우가 존재하고, Food점수는 실제 음식임을 대변하는 점수가 되지 않는다.(소금빵 확대샷이 카페이미지보다 food점수가 낮음) - 맹점 1에대한 생각 Softmax에다가 인테리어점수랑 음식점수를 넣는데, 그 과정에서 결과물의 점수가 일관되지 않은것같음 → 절대적인 비교에 Softmax가 필요한가? → softmax말고, 분위기 점수를 일관되게 뽑고,분위기 점수에 thr을 정해서 분위기가 아닌 사진은 걸러내는 알고리즘 → 분위기점수가 thr이 넘는 사진이 5개가 안되는경우 해당 카페는 아예 json에서 제외 → Thr을 주피터노트북에서 바꿔가면서 실험해봐야함 2. 평균과 유사한 이미지를 0.4만큼 반영하는데, 이 로직때문에 비슷한 사진만 5장 뽑힌다 → 분위기를 반영하더라도 클러스터링 되어있지 않은 사진이면 뽑히지 않는다. - 맹점 2에 대한 생각 평균과 유사한 이미지를 고르는 로직을 뺴는건 어떤가? → 중심벡터를 구해서 비슷한 이미지를 가중치주는 로직은 삭제해야됨 ## **해결안** ‘분위기’를 점수로 어떻게 나타낼것인가? 에대한 해답을 프롬프트에서 찾았다. 대표이미지로 선택하고자 하는 이미지들의 특징을 positive의 프롬프트로 넣어주었고, 걸러내야할 노이즈 이미지들의 특징을 Negative 프롬프트로 넣어주었다. 이미지마다 Positive와 Negative점수를 내서 그 차(delta score)를 최종 점수로 삼았다. ### Metric 개선 $Metric = Interior Score - Noise Score$ $Interior Score$와 $Noise Score$는 CLIP으로 프롬프트와 이미지의 코사인 유사도를 구해서 구함 **메트릭 설정 과정** - 크롤링된 사진의 특징을 보고 눈으로 걸러내야할 사진과 포함해야할 분위기 사진의 특징을 파악한다 → 프롬프트로 사용한다. - 걸러야 할 사진은 Negative(`Noise Score`)에, 포함해야할 사진은 Positive(`Interior Score` )에 프롬프트로 포함시킨다. - 프롬프트와의 Cosine 유사도를 구한 후 `Interior Score - Noise Score`를 메트릭으로 사용한다 - 분포를 확인하고, 잘 걸러지는지 확인한다. ```python PROMPTS = { "positive": [ "an interior photo of a cafe", "cozy cafe atmosphere", "indoor lighting and furniture", "wide angle shot of a room", # "architectural design of a building exterior", #건물 외관 "interior design details and decorations", #소픔이나 내부디자인 "outdoor terrace seating area of a coffee shop" #야외 테라스 ], "negative": [ "close-up photo of food", "dessert or cake", # 디저트 얼빡샷 "a photo of a menu board, price list or signage", "text document or receipt", "a selfie of a person", "beverage in a plastic cup"#컵사진 "a close-up photo of a beverage cup or hand holding a drink", #사람이 들고있는 컵사진 "a graphic logo, illustrative icon, or screenshot" #카페 로고 ]} ``` ### 결과1 한개 카페에 대한 분포  인테리어 스코어와 노이즈 스코어의 분포(좌), 두개의 차인 Delta Score의 분포(우)  Top 10 Selected Images (Highest delta_score):  Worst 5 Images(Lowest delta_score) 델타 스코어의 분포를 보면 느좋카페와 안 느좋카페를 구분할 수 있다. 느좋카페는 thr이 0보다 큰 사진이 많은 반면, 안 느좋 카페는 thr이 0보다 작은 사진이 더 많다. 위의 오른쪽 분포를 보면 score가 0보다 큰 사진이 많으므로 느좋사진이 많다고 볼 수 있다. ### 느좋카페 예시1   Top 10 Selected Images (Highest delta_score):  Bottom 5 Images (Likely Noise/Food) ### 느좋카페 예시 2  Delta Score를 보면 0보다 큰 사진이 많으므로 느낌좋은 사진이 많음을 확인할 수 있다.  Top 10 Selected Images (Highest delta_score):  Bottom 5 Images (Likely Noise/Food): ### 느 안좋 카페 예시  분포를 보면 Noise Score(빨간색)이 오른쪽에 치우쳐져 있고, Delta Score는 0을 넘는 사진이 거의 없음을 확인할 수 있다.  Top 10 Selected Images (Highest delta_score):  Bottom 5 Images (Likely Noise/Food): ## Threshold정하기 Thr을 정하려면 N이 충분히 큰 사진에 대해서 분포를 살펴보고, Score의 어느 경계에서 분위기를 나타내는 사진이 갈리는지 확인하면 된다. 랜덤으로 동3개를 샘플링하고 이에 대해서 (카페 45개)모든 이미지의 분포를 살펴보고 thr을 정한다. **구로2동, 가산동, 독산3동**  대략 thr이 0에서 0.01사이 지점에서 가우시안 분포가 나뉘게 된다. 오른쪽 그래프를 보면 빨간색(positive)와 파란색(negative)점수를 갖는 사진 샘플들이 클러스터링을 하며 잘 뭉쳐져있음을 확인할 수 있다.      thr을 0.01로 최종적으로 정함  이 과정 이후 thr을 넘은 사진이 5개가 안되는 카페 907개는 걸러졌음. 결론적으로 걸러내고자 했던 이미지들의 특징을 Negative 프롬프트로 넣어서, Metric에 반영을 한 결과, 노이즈이미지를 걸러낼 수 있었고, ‘분위기’를 나타내는 사진만 대표이미지로 선택할 수 있었다. ### [이미지기반 카페추천 프로젝트]서울시 카페 리뷰 데이터 정제 및 요약 - Canonical URL: https://hyejunl33.github.io/projects/2026-01-30-Review_Summarization/ - Collection: Project - Published: 2026-01-30 - Tags: 이미지기반 카페추천 프로젝트, 리뷰 데이터 정제 및 요약 # 리뷰 데이터 정제 및 요약 ## 목차 1. [도입 배경 및 문제 정의](#도입-배경-및-문제-정의) 2. [아키텍처 및 핵심 로직](#아키텍처-및-핵심-로직) 3. [데이터 전처리 전략 (Preprocessing)](#데이터-전처리-전략-preprocessing) 4. [프롬프트 엔지니어링 (Gemma3)](#프롬프트-엔지니어링-gemma3) 5. [최적화 및 성능 관리 (Batch Processing)](#최적화-및-성능-관리-batch-processing) 6. [데이터 스키마 및 저장](#데이터-스키마-및-저장) --- ## 도입 배경 및 문제 정의 ### 프로젝트 목표 크롤링된 **Raw 리뷰 데이터**는 노이즈가 많고 비정형적이라 검색이나 추천 시스템에 바로 활용하기 어려움. 이를 Google의 **Gemma-3-4B-IT** 모델을 사용하여 정제하고, 장소의 특징을 나타내는 **핵심 태그**와 **요약문**을 생성하여 서비스 품질을 높임. ### 모델 선정 근거 (Gemma3 Performance Benchmark) 다양한 모델 크기와 포맷을 비교 실험하여 최적의 모델을 선정함. | 모델 | 실행 시간 (리뷰 50개) | 요약 품질 | 비고 | | --- | --- | --- | --- | | **Gemma3-4B-IT** | 약 10초 (GPU/API) | **완벽함** | **최종 선정** (4bit 양자화 활용) | | Gemma3-1B-IT | 약 7초 (GPU/API) | 문맥이 약간 어색함 | 속도는 빠르나 표현력이 부족하여 제외함 | | Gemma3-4B-GGUF | 약 10분 (CPU) | 좋음 | 4코어 CPU/8GB RAM에서도 동작하나, 대량 처리에 부적합함 | 1B 모델은 문맥 파악 능력이 부족하고, 4B-GGUF(CPU)는 처리 속도가 너무 느림. 따라서 GPU 가속과 4bit 양자화를 적용한 **Gemma3-4B-IT** 모델이 성능과 속도의 균형 면에서 가장 적합하다고 판단함. ### 기술적 도전 과제 및 해결 방안 | 기술적 문제 (Problem) | 상세 내용 | 해결 방안 (Solution) | | --- | --- | --- | | **데이터 노이즈** | 이모지 남발, 무의미한 특수문자, 비한국어 리뷰 등으로 분석 비용 증가 및 정확도 저하 | **Token Optimization**: 정규식 정제로 불필요한 이모지 및 특수문자를 제거하여 입력 토큰을 약 30% 감소시키고 할루시네이션 방지함 | | **비정형 데이터** | 리뷰 내용이 제각각이라 일관된 검색 메타데이터 추출이 어려움 | **Structured Prompting**: 검색을 위한 태그(#)와 전시를 위한 요약문을 분리 생성함 | | **GPU 리소스 유휴** | V100 GPU (32GB VRAM) 사용 시, 단일 건 처리로는 메모리가 남아돌아 자원 낭비 발생 | **Batch Inference**: 단위 배치 처리로 VRAM을 최대한 활용함. | --- ## 아키텍처 및 핵심 로직 ### 파이프라인 구조 Step 2(VLM 묘사) 완료 데이터를 입력으로 받아, 리뷰 요약 및 태그 생성을 수행한 후 Step 3 데이터를 출력함. ``` [Input: Step2 JSON] (VLM 묘사가 포함된 카페 데이터) ↓ [Preprocessing] (이모지 제거, 길이 필터링, 한글 비율 체크) ↓ [LLM Processing (Gemma3)] (Batch Size: 8) ├── [Task 1] Tag Generation (#태그 #생성) └── [Task 2] Summary Generation (한 줄 요약 + 상세 설명) ↓ [Output: Step3 JSON] (summary_for_embedding, summary_for_display 추가) ``` ### 전처리 구현 (`clean_review`) ```python def clean_review(text, min_len=5, max_len=200): # 이모지 패턴을 [EMOJI] 플레이스홀더로 치환했다가 제거 (텍스트 깨짐 방지) emojis = EMOJI_PATTERN.findall(text) text = EMOJI_PATTERN.sub(' [EMOJI] ', text) # 한글, 영문, 숫자, 기본 부호 외 제거 text = re.sub(r'[^가-힣a-zA-Z0-9\s,.!?~()\-]', ' ', text) # 한글 비율 체크 (50% 미만인 리뷰는 스킵 - 영문/일문 리뷰 등 제외) if total_chars > 0 and korean_chars / total_chars < 0.5: return "" # ... ``` 단순한 특수문자 제거를 넘어, 리뷰의 유용성을 판단하기 위해 ‘최소 길이’와 ’한글 비율’ 조건을 적용함. 퀄리티가 낮은 리뷰는 모델 입력 단계에서 미리 차단하여 토큰 비용과 시간을 아낌. --- ## 데이터 전처리 전략 (Preprocessing) ### 1. 노이즈 제거 및 정규화 크롤링된 리뷰에는 “더보기” 같은 UI 텍스트나 반복적인 이모지가 섞여 있음. 이를 정규식(Regex)으로 제거하고, `~`나 `!` 같은 문자가 과도하게 반복되는 것을 표준화함. ### 2. 고품질 리뷰 선별 LLM의 입력 토큰 한도가 있으므로, 모든 리뷰를 넣는 대신 **유의미한 상위 30~50개 리뷰**만 선별함. - **길이 제한**: 5자 이상 200자 이하 (너무 짧거나 긴 리뷰 제외) - **중복 제거**: 내용이 완전히 동일한 리뷰는 `set`을 이용해 제거함. --- ## 프롬프트 엔지니어링 (Gemma3) 검색과 가게설명이라는 두 가지 목적을 달성하기 위해 두 종류의 독립된 프롬프트를 사용함. ### Task 1: 가게 태그 생성 가게 요약에 활용할 핵심 키워드 3개를 추출함. ```python # 프롬프트 예시 """다음 카페 리뷰들을 보고... 핵심 태그 3개를 생성해줘. 지시사항: 1. 반드시 #으로 시작하는 태그 형식 2. 태그는 3개만 작성 ...""" ``` ### Task 2: 가게 설명용 요약 생성 사용자에게 보여줄 매력적인 소개글을 작성함. 개인정보(실명 등)가 포함되지 않도록 주의 사항을 포함함. ```python # 프롬프트 예시 """다음 리뷰들을 바탕으로... 매력적인 소개문을 작성해주세요. 리뷰에 포함된 사용자의 개인정보는 요약에 포함하지 말아주세요. 형식: 한 줄 요약: ... 상세 설명: ...""" ``` --- ## 최적화 및 성능 관리 (Batch Processing) ### Batch Inference 구현 LLM 모델(Gemma-3-4B) 로드 오버헤드를 줄이고 연산 효율을 높이기 위해 배치 처리를 수행함. ```python def generate_batch(model, tokenizer, prompts, max_new_tokens=300, batch_size=8): # Padding과 Truncation을 적용하여 텐서 크기 맞춤 model_inputs = tokenizer( text_inputs, return_tensors="pt", padding=True, truncation=True, max_length=8192 ).to(device) # 배치 단위 생성 generated_ids = model.generate(**model_inputs, ...) ``` 한 번에 8개(설정 가능)의 프롬프트를 모델에 입력하여 결과를 동시에 받아옴. 이를 통해 1건씩 처리할 때보다 처리 속도가 약 3~4배 향상됨. ### 메모리 관리 배치 처리가 끝날 때마다 명시적으로 GPU 캐시를 비워 OOM을 방지함. ```python del model_inputs, generated_ids torch.cuda.empty_cache() gc.collect() ``` --- ## 데이터 스키마 및 저장 Step 3 파이프라인을 거치면 JSON 객체에 두 가지 핵심 필드가 추가되어 저장됨. | 필드명 | 타입 | 설명 | 출처/생성 | | --- | --- | --- | --- | | `summary_for_embedding` | List[str] | 검색 태그 리스트 (예: `['#조용한', '#커피맛집', '#주차가능']`) | Task 1 결과 | | `summary_for_display` | String | 전시용 요약 텍스트 (한 줄 요약 + 상세 설명) | Task 2 결과 | | `original_data` | Dict | 이전 단계(Step 2)의 원본 데이터 (유지) | Input | **저장 파일 예시**: `data/processed/json/step3_summarized/강남구_역삼동_step3.json` --- ### [이미지기반 카페추천 프로젝트] SigLip으로 텍스트 임베딩 - Canonical URL: https://hyejunl33.github.io/projects/2026-01-30-SigLip/ - Collection: Project - Published: 2026-01-30 - Tags: 이미지기반 카페추천 프로젝트, SigLip으로 텍스트 임베딩 # SigLip으로 텍스트 임베딩 ## 문제 - SigLip은 64토큰만 임베딩할 수 있음 -> Captioning과 HyDE를 뽑아낼때 최대한 간결하게 뽑아내야됨 -> 따라서 기존의 캡셔닝과 HyDE의 프롬프트를 바꿔서 50자 미만의 단어위주로 출력하도록 바꾸기 - 50자도 토큰이 130토큰 이상이므로 슬라이딩 윈도우 방식으로 `services/loadmodel.py`파일 변경 -> 기존에는 64토큰만 임베딩해서, 사실상 HyDE가 의미가 없는 수준이었음. ## 배경 아파치 라이센스에, 한국어를 잘 이해하는 모델인 siglip을 임베딩 모델로 선정했었는데, mvp를 뽑고나서 치명적인 문제가 발생했다. siglip은 64토큰으로 pretrain된 모델이라, 인풋을 64토큰으로만 사용할 수 있다는것을 모두 놓쳤다는것이다. 이 상황에서 기존의 임베딩으로 들어가던 텍스트는 64토큰으로 truncation되어 들어가고있음을 확인하고, 문제해결에 착수했다. - 해결안 1. 모델을 교체한다. - 해결안 2. 다른방법을 모색한다.. 모델을 교체하기에는 코드로 구현까지 모두 끝난상황이었기 때문에, 모델을 교체하기에는 부담이 컸다. 따라서, 64토큰이라는 한계에 맞추어서 HyDE를 생성할때, 기존에 문장형식으로 길게 출력되던것을, 명사구 형식으로 간결하게 50자 이내로 출력하도록 바꾸었다. 50자로 바꾸어도 130토큰정도이므로, 다른방법이 추가로 필요했다. 따라서 인풋을 그대로 임베딩해서 넣는것이 아니라, stride를 32씩 갖고, 64토큰씩 임베딩을하고, 평균을 내는 sliding Window방식을 사용하기로 결정했다. ## 해결방안 - HyDE에서 간결하게 분위기 정보 뽑아내도록 프롬프트 수정하기 ```python config={ "system_instruction": ( """이 이미지를 보고 아래 지시에 따라 세부적으로 묘사해줘: 너는 카페 인테리어 및 공간 디자인 전문가야. 카페의 '공간 분위기'를 묘사해야 해.\n\n [작성 가이드] 1. 문장 형식이 아닌, 콤마(,)로 구분된 '명사구' 나열식으로 작성할 것. 2. 구체적인 사물 자체가 아니라 감성적인 분위기를 묘사할 것. 3. '카페', '인테리어'처럼 당연한 단어는 생략하고 구체적인 분위기로 묘사할 것. 4. 공백 포함 한국어 50자 이내로 작성할 것. 아래 예시출력을 참고해서 출력해 예시출력: 창가자리, 자연광, 바다전망, 대형 유리창, 소박한 인테리어, 편안한 의자, 야외 테라스, 감성조명, 일몰뷰 """ ) ``` 50자 이내로 간결하게 HyDE를 생성하도록 수정했다. 이전에는 문장형식으로 길게 생성했지만, 간결하게 분위기만 나타내도록 문장구형식으로 생성하도록 프롬프트를 수정했다. - `service/loadmodel.py`를 슬라이딩 윈도우 방식으로 벡터를 64토큰씩 구하고 stride를 32로 줘서 나온 HyDE의 벡터를 평균내서 임베딩 구하도록 코드구현  결과: 프롬프트 최적화 + 슬라이딩 윈도우 조합으로, **긴 텍스트도 전체 맥락이 검색에 반영됨** ### 프로젝트아이디어 - 에듀테크 - Canonical URL: https://hyejunl33.github.io/projects/2025-11-21-ProjectIdea-edutech/ - Collection: Project - Published: 2025-11-21 - Tags: Final_Project, Edutech, idea ## LMS(Learning Management System) **With AI** 교육청, 학교, 교사를 대상으로 하는 학급 관리 프로그램. 교사는 **OCR**된 학생의 포트폴리오를 이용해서 개인맞춤형 피드백을 제공할 수 있음. ## 0. 교육현장에서 AI 도구의 메리트 - 업무자동화 - 많은량의 데이터를 한꺼번에 처리할 수 있음. - 개인 맞춤형 교육 - 다문화 학생에게도 맞춤형 교육을 제공 - 느린학습자 지원 - 과정 중심 평가의 보조도구 → 결과중심평가에서 벗어날 수 있음 - 2022 개정교육과정에도 부합함. - 비대면 수업보조도구 - 메타버스..? 실제로 코로나시기에 로블록스를 교실로 사용한 사례가 있음 ## 1. 사례분석 ### **1.1 구글 클래스룸**  **장점** - 아날로그 데이터 아카이빙 - 과제 제출여부, 제출시간등을 정량화해서 즉각적인 **정량평가 가능** **단점** - 데이터들을 엮어서 학생별 정성적 평가 불가능 - 과제는 단순한 사진 혹은 텍스트파일로 남음 → 정성적 평가 어려움 ### 1.2 **다했니? 다했어요** [https://edzip.kr/product-detail/682ed25b42cd392c8ffe1c8e](https://edzip.kr/product-detail/682ed25b42cd392c8ffe1c8e) **장점** - 구글 클래스룸과 마찬가지로, 과제평가, 과제 제출여부, 평가를 할 수 있음. - 학생별로 포트폴리오를 아카이빙 할 수 있고 학부모와 공유하여 가정연계를 쉽게 할 수 있음. - 강화를 통한 학생 동기부여 - ‘쿠키’라는 강화방안을 통해서 학생들에게 동기를 부여함 - 개선: 반별로 리더보드를 만들어서 더 동기를 부여할 수도 있을듯. **단점** - 과제 제출여부만 따지고 과제의 질적평가는 여전히 교사가 해야함. - 비정형적인 데이터를 분석해서 자동화된 피드백을 제공할 수 없음 - 일기, 독후감, 수학익힘책풀이등을 OCR한 후 채점보조를 해서 개선할 수 있음. ## 2. 문제의식 기존의 사례들에서는 학생들의 데이터를 아카이빙하는데에만 집중하고, **과제의 질적평가**는 여전히 교사의 몫이었다. 정량적 평가에서 **과정중심평가**로 교육의 패러다임이 바뀌고있음을 고려할때, 멀티모달 LLM을 이용해서 **정성적 평가**를 도울 수 있다. ## 3. 해결할 문제 AI가 대세다, 디지털 교과서를 사용한다 해도 결국에 교실에서는 **종이 책을** 이용해서 수업을 진행함 → 학생의 과제물들을 저장해서 AI모델을 이용한 정성적 평가에는 **OCR**이 필수적임. ### 3.1 휘발되는 각종 수업진행내용 → 이미지 아카이빙 혹은 OCR 교실에서는 기록할게 정말 많다..! → 학생의 교실에서의 생활 현황을 기록할 수 있음.     - **국어**: 글쓰기 활동 → OCR 후 학생 개인별 DB에 저장. - **수학**: 수학익힘책 풀이→OCR을 이용해서 자동채점보조 → 학생 개인별 DB에 저장. - **미술**: 만들기작품, 그림등을 아카이빙 → 정량적인 평가보단 교사의 정성적인 코멘트 → 해당 코멘트들을 모아서 학생의 개인화된 특징 파악 - **실과:** 만들기 작품(요리, 뜨게질) 사진으로 아카이빙 → 부모와 공유 및 교샤의 정성적인 코멘트 → 해당 코멘트를 모아서 학생의 개인화된 특징 파악 - **음악**: 리코더 및 단소와 같은 악기 및 가창 동영상으로 아카이빙 → 부모와 공유 및 교사의 정성적인 코멘트 아카이빙한 **학생별 포트폴리오**는 게시판형태로 **학부모**와 공유할 수 있음. ### 3.2 과제물 피드백할 시간부족 → OCR을 통한 채점 자동화 교사는 모든 학생들의 과제물(독후감, 수학익힘책등)을 읽고 채점해야한다. → 시간이 부족하다.. 독후감, 수학익힘책, 과학등의 교과에서 OCR을 통해 채점을 자동화 한다. ### 3.3 학생별로 개별화된 피드백 제공 학생별로 아카이빙된 멀티모달 자료들을 바탕으로 학부모상담 자료, 생활기록부등을 생성할 수 있음.  ## 4. 시장성 에듀테크 소프트웨어가 시장에 팔릴까? ### 4.1 교사를 타겟팅 - 학급운영비 - 교육청마다 다르지만 학급당 연간 20~50만원 수준 - 학급 환경 물품 구입비 - 학습준비물비 교사는 학급운영비로 소프트웨어를 구매할 수 있지만, 교육청별로, 학교별로 다르기 때문에 미지수임.. ### 4.2 에듀테크 실증 지원사업  프로젝트로 서비스개발 → 교사들에게 바이럴 → 사례를 모아서 에듀테크 실증 지원사업 공모전에 제출가능 ### 4.3 교육청을 타겟팅 교육청을 타겟팅해서 소프트웨어를 팔려면 학교장터, 조달청에 등록을 해야한다.. - 사업자등록증 필요 - CSAP인증(보안인증)을 받아야함→ 딥시크OCR은 중국모델이라 힘들듯.. ### 4.4 교과서 출판사를 타겟팅  비슷한 서비스를 운영하는 미래엔이나 AI디지털교과서 출판에 관심있는 출판사에 exit을 노려볼 수 있음 ## 5. 예상가능한 문제점 - 초등학생이 작성한 글이나수식에서 OCR한 결과가 만족할만한 성능이 나올까? → FInetuning, LoRA, 손글씨 인식을 잘하는 모델로 바꾸기 - 수학익힘책 채점을 자동화할때 풀이와 답안에는 정해진 양식이 없는데 어떻게 채점할것인가? 단순 OCR로 해결할 수 있는 문제인가? - B2C가 아닌 B2B로 팔아야하는데, 과연 교육청이나 교사가 이용을 할만한 메리트가 있을까? ### [영화리뷰 감성분류][모델최적화]하이퍼파라미터튜닝2 - Canonical URL: https://hyejunl33.github.io/projects/2025-11-01-[Domain_Common_Project]HyperParameterTuning2/ - Collection: Project - Published: 2025-11-01 - Tags: Domain_Common_Project, study, ModelOptimization, HyperParameterTuning # Introduction - 하이퍼파라미터 튜닝 - Focal Loss에서 알파 가중치를 얼마나 줘야할까? - 최적의 알파 가중치는 얼마일까? - 이외에 하이퍼파라미터 튜닝할 수 있는값 모두 넣기 - valid 데이터를 포함해서 전체 데이터를 기준으로 학습시켜보기 - 모델 앙상블 추론을 할때, 모델별로 Weight를 줘서 앙상블을 해보기 이전 실험까지를 대략 요약하자면 데이터셋이 불균형 데이터라고 생각해서FocalLoss의 $$\alpha$$가중치를 각 레이블의 비율의 역수를 정규화해서 가중치로 두었다. 하지만, 그렇게 가중치를 준게 오히려 test/acc성능에는 악영향을 미친것을 확인할 수 있었다. 즉 소수클래스에 가중치를 둔게 오히려 대다수의 클래스를 맞추는데 악영향을 미쳤고, 전체 test/acc성능이 하락함을 확인할 수 있었다. 그러면 최적의 알파 가중치를 찾으려면 어떻게해야할까? 바로 하이퍼파라미터 튜닝이다. 따라서 이번 실험에서는 최적의 FocalLoss의 $$\alpha$$가중치를 찾으면서, 그외에도 이전에 구현한 SWA에서 평균낼 체크포인트의 개수, FocalLoss의 $$\gamma$$등 다른 하이퍼파라미터도 함께 튜닝을 해서 모델의 최적 성능을 뽑아볼 예정이다. FocalLoss의 $$\alpha$$는 클래스 개수만큼의 리스트원소를 튜닝할 수 없으므로 일반적으로 아래 식을 이용해서 하나의 $$\beta$$만 튜닝한다고 한다. $$W_{final} = (1-\beta)\cdot W_{inversefreq} + \beta\cdot W_{uniform}$$ 즉 균등분포가중치`[0.25,0.25,0.25,0.25]`와 빈도 백분율역수가중치를 $$\beta$$를 하이퍼파라미터로 해서 얼마나 섞어서 최종 가중치로 계산할지 결정하는 것이다. 따라서 하이퍼파라미터 튜닝에 'alpha_beta_smooth'라는 값을 넣어주었다. # 하이퍼파라미터 튜닝 ## 최적화 해야할 하이퍼파라미터 목록 ```python sweep_config = { 'method': 'bayes', 'metric': { 'name': 'eval/accuracy', 'goal': 'maximize' }, 'parameters': { 'learning_rate': { 'distribution': 'log_uniform_values', 'min': 1e-6, 'max': 5e-5 }, 'num_train_epochs': { 'values': [5, 8, 10, 12] }, 'weight_decay': { 'distribution': 'uniform', 'min': 0.0, 'max': 0.1 }, 'per_device_train_batch_size': { 'values': [64, 128, 256] }, 'per_device_eval_batch_size': { 'values': [64, 128, 256] }, 'warmup_steps': { 'distribution': 'q_uniform', 'min': 100, 'max': 1000, 'q': 50 }, 'focal_loss_gamma': { 'distribution': 'uniform', 'min': 0.5, 'max': 5.0 }, 'label_smoothing_factor': { 'distribution': 'uniform', 'min': 0.0, 'max': 0.2 }, #'dropout_rate': { 'distribution': 'uniform', 'min': 0.05, 'max': 0.3 }, 'lr_scheduler_type': { 'values': ['cosine', 'linear', 'constant'] }, 'gradient_accumulation_steps': { 'values': [1, 2, 4] }, 'num_rare_words_to_remove': { 'values': [0, 3, 5, 10] } # 추가됨 'alpha_beta_smooth': { 'min': 0.0, 'max': 1.0, 'distribution': 'uniform' # 0.0에서 1.0 사이를 균등하게 탐색 },# Focal Loss 알파의 가중치 비중을 탐색 'SWA_K': {'values':[2,3,4] } 'early_stopping_patience' : {'values':[2,3,4]} } } ``` 하이퍼파라미터 튜닝은 실험을 통해서 단일모델중 가장 최적의 성능을 보였던 `kykim/bert-kor-base` 모델로 진행했다. 모델의 아키텍처마다 최적의 하이퍼파라미터가 다르기 떄문에, 사용할 모델 모두 하이퍼파라미터 튜닝을 진행해야하지만, 대회 시간이 촉박해서 하나의 모델로밖에 튜닝을 해보지 못했다.. 이부분은 아쉽다. 다음에 대회에 참가할 기회가 생긴다면 실험 스케줄러를 만들어서 24시간동은 GPU를 굴리면서 가능한 모든 실험을 해볼 수 있도록 할것이다.  튜닝결과 eval/accuracy_swa에서 가장 좋은 성능을 낸 9번째 하이퍼파라미터를 사용하기로 했다. 하이퍼파라미터 튜닝을 하기 전에는 0.85의 accuracy가 나왔지만, 하이퍼파라미터 튜닝 후 0.84가 나왔다. 이를 봐서는 베이지안 방식으로 하이퍼파라미터 튜닝이 아직 완벽하게 되지 않은것처럼 보였지만, 일단 시간관계상 이 하이퍼파라미터를 사용하기로 했다. ```python { 'learning_rate': 0.00000937759265615758, 'num_train_epochs': 5, 'weight_decay': 0.03423148594790665, 'per_device_train_batch_size': 32, 'per_device_eval_batch_size': 256, 'warmup_steps': 400, 'focal_loss_gamma': 4.194768435552584, 'label_smoothing_factor': 0.03442149572139974, 'lr_scheduler_type': 'linear', 'gradient_accumulation_steps': 4, 'num_rare_words_to_remove': 0, 'alpha_beta_smooth': 0.17235143553564636, 'SWA_K': 4, 'early_stopping_patience': 4 } ``` 튜닝된 하이퍼파라미터 결과를 보자면 알파는 거의 균등분포값에 가까운 가중치를 갖는다. 이전 실험까지의 인사이트와 이번 실험결과를 종합해 봤을때, `[0.25,0.25,0.25,0.25]` 즉 가장 eval/acc를 높이는 방향은 균등분포값에 가까운 가중치를 알파로 줘야한다는 인사이트를 얻었다. 실제로 test/acc를 관찰해본 결과, 하이퍼파라미터 튜닝을 통해 얻은 $$\alpha$$가중치를 쓰는것보다 균등분포 가중치를 주는것이 오히려 test/acc가 높음을 확인할 수 있었다. 아마 최적의 하이퍼파라미터를 찾기 전에(13step) 하이퍼파라미터 탐색을 중지해서 이런 결과가 나온것 같다. # 결과  맨아래는 단일모델 결과, 위의 3가지는 SWA와 모델별 앙상블 경우의수를 다르게 해서 test한 결과이다. 결과적으로 이번실험에서는 BERT기반 모델 3개를 앙상블하고, 알파가중치를 `[0.25,0.25,0.25,0.25]`로 두고, test/acc를 한 결과 가장 높은성능인 0.8278의 성능을 확인할 수 있었다. 추후 Public socre에서도 0.8301로 내가 실험해본 모델중에서는 가장 높은 성능을 보였다. ## 한계점 및 반성 하이퍼파라미터 튜닝을 하는데에는 상당한 시간이 든다. 베이지안 서치를 하더라도, 최소 15번 이상은 모델을돌려야 하고, 모델마다의 최적의 하이퍼파라미터는 다르므로, 앙상블할때 사용할 모든 모델에 대해서 하이퍼파라미터 튜닝을 해야한다. 그리고 15번 베이지안 서치를 한다고 해서 최적의 하이퍼파라미터를 얻는다는 보장은 없으므로, 어느정도 모델성능이 최적점에 수렴하는것을 확인할때까지 하이퍼파라미터튜닝을 해야한다. 실제로 이번 대회가 끝나고 오피스아워에서 멘토님이 하시는 말을 들어보니, 다른 대회에서도 최적의 모델을 우선 정한다음에, 대회가 끝날때직전까지 최적의 하이퍼파라미터를 찾는다고 한다. 이번 대회가 첫경험이라, 최적의 모델을 먼저 찾을 생각을 하지 못했고, 모델마다 최적의 하이퍼파라미터를 찾을 생각도 하지 못했다. 모델의 변경사항이 생길때마다 하이퍼파라미터는 달라질텐데, 그떄마다 하이퍼파라미터 튜닝을 다시 할 순 없으므로 가장 마지막에 튜닝을 해야하는것도 이번 대회를 통해 배우게 됐다. # 이후 실험에서 고려해야 할 것들 - tapt적용 - 전체데이터에 대해서 5개모델 다시 학습 후 앙상블 → 시간부족으로 못해봄 - 전체데이터셋으로 학습시킨 모델 효과있는지 실험→ 시간부족으로 못해봄 - 5개모델 acc를 Weight로 줘서 앙상블 - 역번역증강 사용할지 말지 결정 → 번역의 품질이 안좋아서 결국엔 사용 x ### [영화리뷰 감성분류][모델최적화]TAPT - Canonical URL: https://hyejunl33.github.io/projects/2025-11-01-[Domain_Common_Project]TAPT/ - Collection: Project - Published: 2025-11-01 - Tags: Domain_Common_Project, study, ModelOptimization, TAPT # [모델최적화]TAPT TAPT는 Task Adaptive Pre-Training의 약자로 내가 풀고자 하는 task에 적응시키기 위해 Pretraining 시키는 과정을 말한다. 기존의 BERT모델을 내가 풀고자 하는 영화리뷰 감성분류에 적응시키기 위해 TAPT를 사용할 수 있다. 일반적인 BERT,KoBERT,KLUE-BERT등은 이미 뉴스나 위키피디아, 댓글등 거대한 데이터에 대해 이미 학습된 상태이다. TAPT는 이러한 사전학습된 모델을 바탕으로 Fine-Tuning하는 과정이다. # TAPT를 왜 하는가? - 도메인 불일치: 모델이 사전 학습한 범용 데이터와, 실제 해결해야할 task의 데이터는 불일치한다. 따라서 Fine-Tuning이 필요하다. - TAPT의 목적: 도메인 사이의 격차를 줄여주는 것이 목적이다. 범용 모델을 원하는 task에 미리 적응시켜서 모델이 task의 도메인의 언어패턴을 더 잘 이해하게 만드는것이 핵심이다. 다만 Overfitting이 되지 않도록 유의해야한다. # TAPT는 어떻게 하는가? - 데이터: 학습데이터에 대해서 라벨이 없는 학습데이터를 사용한다. 이 데이터를 가지고 MLM방식을 사용해서 마스크된 단어를 예측하는 방식으로 학습한다. ## MLM: Masked Language Model 주변단어로 마스크된 중심단어를 맞추면서 학습한다. 따라서 문장 전체의 문맥을 반영하여 벡터값을 예측한다. 이 MLM을 이용해서 기존의 BERT모델을 Pretrain하면 모델이 훨씬더 데이터셋을 잘 이해할 수 있게 된다. **작동방식** 1. 입력문장을 가져온 후에, 일부 토큰을 랜덤하게 [MASK]토큰으로 바꾼다. 2. 모델이 문맥을 보고 [MASK]토큰에 들어갈 단어를 맞추도록 학습한다. 1. BERT의 기본 인코더 층 위에 MLM을 위한 HEAD를 추가로 붙인다. 2. [MASK]토큰의 최정 백터(`H_MASK`)만 MLM헤드로 전달된다. 3. 이 헤드의 최종 단계는 어휘의 사전 크기만큼의 차원으로 확장하는 하나의 Linear계층이다. 4. 계산된 Logits을 이용해서 BackPropagation을 진행한다. → 가중치를 업데이트 한다 이를 통해서 모델은 주변 문맥을 통해 빈칸을 추론하는 방법을 배운다. # Task에 맞는 데이터셋 준비 ```python # TAPT.ipynb (Cell 9) # 1. 내가 풀려는 과제의 데이터를 불러옵니다. train_df = pd.read_csv("./data/train.csv") test_df = pd.read_csv("./data/test.csv") # 2. 'review' 텍스트만 모두 합칩니다. all_text_data = pd.concat([train_df['review'], test_df['review']]) # 3. TAPT 학습용 텍스트 파일로 저장합니다. output_filename = "tapt_corpus.txt" with open(output_filename, "w", encoding="utf-8") as f: for line in all_text_data: # ... (생략) ... ``` 내가 풀고자하는 Task의 데이터를 불러와서 TAPT에 맞는 데이터셋으로 준비한다. 이때 TAPT과정에서 label은 필요없고, review데이터(텍스트)만을 이용한다. ### [영화리뷰 감성분류][모델최적화]-eval/loss vs eval/acc - Canonical URL: https://hyejunl33.github.io/projects/2025-11-01-[Domain_Common_Project]eval-loss-vs-eval-acc/ - Collection: Project - Published: 2025-11-01 - Tags: Domain_Common_Project, study, ModelOptimization # Introduction 해당 test의 평가 지표는 test/acc이다. 지금까지의 실험 가설은 eval/loss를 줄여서 과적합을 막으면 자동으로 test/acc도 올라갈것이라는 가정이 있었다. 하지만 eval/loss를 metric으로 모델을 선택해서 test를 해본 결과, 성능이 오히려 하락하는 문제가 있었다.   그리고 두번째로, 모델이 과하게 소수클래스를 중요하게 보는 문제가 있었다. test데이터셋의 분포는 알 수 없지만, 일반적으로 전체데이터셋과 같다고 생각할때, Focal Loss의 $$\alpha$$의 가중치로 인해 소수클래스만을 너무 중요하게 여겨서, 전체 데이터셋의 분포와 예측 분포를 볼때, 소수클래스의 비율이 과장되게 예측됨을 확인할 수 있었다. 따라서 이번실험에서는 평가지표를 eval/acc로 바꿔본 후, Focal Loss의 가중치를 모두 1로 두고 성능을 관찰해본다. 시간관계상 앙상블한 모델이 아닌 단일모델로 실험을 한다. 평가지표를 acc로 바꿨기 때문에 eval/acc만 상승하고 eval/loss는 폭발하는 상황을 막기 위해서 기존에 8이었던 에폭을 5로 설정한다. 만약 유의미한 성능향상이 있을 경우 이 모델을 기준으로, 하이퍼파라미터 튜닝을 한 후 앙상블을 해서 성능을 실험해 볼 예정이다. # Eval/accuracy를 메트릭으로 이용하자.. 기존에는 너무 결과가 과적합되는것 같아서 eval/loss를 메트릭으로 사용해서 모델을 선정했다. 따라서 acc성능이 잘 나오지 않은것으로 추측된다. 따라서 이번에는 eval/accuracy를 메트릭으로 사용한다. ```python # --- Training Arguments for the current model --- training_args = TrainingArguments( output_dir=output_dir, num_train_epochs=NUM_EPOCHS, per_device_train_batch_size=BATCH_SIZE_TRAIN, per_device_eval_batch_size=BATCH_SIZE_EVAL, warmup_steps=WARMUP_STEPS, weight_decay=WEIGHT_DECAY, learning_rate=LEARNING_RATE, logging_steps=100, eval_strategy="epoch", save_strategy="epoch" if SAVE_MODEL else "no", load_best_model_at_end=SAVE_MODEL, metric_for_best_model= "eval_accuracy" if SAVE_MODEL else None, greater_is_better=True, save_total_limit=SAVE_TOTAL_LIMIT_FOR_SWA if SAVE_MODEL else 0, # 수정: SWA 위해 늘림 label_smoothing_factor=0.18547040498752376, report_to="wandb" if USE_WANDB else "none", run_name=run_name if USE_WANDB else None, seed=current_seed, fp16=torch.cuda.is_available(), dataloader_num_workers=2, remove_unused_columns=False, push_to_hub=False, gradient_accumulation_steps=4, logging_first_step=True, save_safetensors=SAVE_MODEL, lr_scheduler_type= "constant", # early_stopping_patience=3, # Keep early stopping if desired # early_stopping_threshold=0.001, ) ``` `metric_for_best_model= "eval_accuracy"` 를 인자로 줘서 eval_accuracy를 메트릭으로 사용한다. 그리고 loss와는 다르게 크면 클수록 좋은것이므로 `greater_is_better=True` 인자를 True로 바꿔줬다. 이와 더불어서 Trainer를 호출할때 `focal_loss_alpha=[1, 1, 1, 1],` 를 이용해서 클래스간 가중치를 아예 없애버렸다. # 결과  기존 실험들 중 가장 높은 성능을 보인 0.8211의 acc가 나왔다. 이제 확실한건, focal_loss의 alpha가중치를 신중하게 수정해야 한다는점, 그리고 모델을 선정할때는 최종 test를 위해서 accuracy를 기준으로 선정해야 한다는점이 확실해졌다.  긍정적인 부분은 alpha가중치를 모두 1로 뒀음에도 f1이 accuracy와 비슷한 정도의 score를 갖는다는것이다. 따라서 가중치가 모두 같음에도 recall성능이 나쁘지 않다는것으로, alpha가중치를 이전에 백분율의 역수로 준게 매우 악영향을 미쳤었다는것을 추측할 수 있었다.  모델의 최종 예측분포를 보면 EDA했을때 전체 데이터셋의 분포와 비슷함을 알 수 있다. 약한 부정비율은 많이 낮아졌지만, 그래도 다수의 클래스에서 Ground Truth와 같은 정답을 예측하는 숫자가 늘어났기 때문에 acc가 향상된것 같다. 이전에는 이 테스트의 목표는 acc를 높이는건데, 그러면 차라리 소수클래스를 무시하고, recall이 낮아도 상관없다는 말이니깐 loss는 커지더라도 acc만커지면 되니깐, loss는 오히려 어느정도는 커져도 상관없을것 같다고 생각을 했다. 하지만 f1 score와 acc가 동시에 올라가는 결과를 관측할 수 있었다. 이제 남은것은 BERT기반 모델 3개의 앙상블을 통한 모델이 더 높은 성능을 보이는지 여부를 확인하고, 하이퍼파라미터 튜닝을 통해 최적의 하이퍼파라미터로 성능을 뽑아내는것이다. ## BERT기반 모델 3개 앙상블 ```python # === Ensemble Training Block === # Replace the original training cell (ID: 176174ee) with this code. # --- Model Training Settings --- SAVE_MODEL = True USE_WANDB = True # Set to True if you want to use Weights & Biases logging for each model from transformers import EarlyStoppingCallback # List of models for ensemble model_names = [ # "./tapted_klue_roberta_base", "./tapted_klue_bert_base", "./tapted_kykim_bert_kor_base", "./tapted_beomi_kcbert_base" # "./tapted_koelectra_base_v3" ] # --- Loop through each model for training --- all_training_results = {} for model_name in model_names: current_seed = random.randint(1, 100000) model_short_name = model_name.split('/')[-1].replace('-', '_') # Create a short name for directories/logging output_dir = f"./results_{model_short_name}" run_name = f"{model_short_name}-movie-review" print("\n" + "=" * 50) print(f"모델 훈련 시작: {model_name}") print(f"결과 저장 경로: {output_dir}") print(f"현재 시드값: {current_seed}") # 💡 현재 시드값 출력 print("=" * 50) # --- Load Model and Tokenizer for the current model --- try: current_tokenizer = AutoTokenizer.from_pretrained(model_name) current_model = AutoModelForSequenceClassification.from_pretrained( model_name, num_labels=NUM_CLASSES, ) current_model.to(device) # Move model to GPU # --- Add new special tokens and resize embeddings --- num_added_toks = current_tokenizer.add_tokens(NEW_SPECIAL_TOKENS) if num_added_toks > 0: print(f"Added {num_added_toks} new special tokens for {model_name}.") current_model.resize_token_embeddings(len(current_tokenizer)) print("Resized model token embeddings.") except Exception as e: print(f"Error loading model {model_name}: {e}") print("Skipping this model.") continue # Skip to the next model if loading fails # --- Recreate Datasets with the current tokenizer --- # This is necessary because different models might have different tokenization train_dataset_current = ReviewDataset( train_data["review"], train_data["label"], current_tokenizer, CHOSEN_MAX_LENGTH, ) val_dataset_current = ReviewDataset( val_data["review"], val_data["label"], current_tokenizer, CHOSEN_MAX_LENGTH, ) # SWA 설정 추가 SWA_K = 2 # 평균낼 마지막 체크포인트 개수 SAVE_TOTAL_LIMIT_FOR_SWA = SWA_K + 1 # best 모델 + 마지막 K개 저장되도록 (최소 2) # --- Training Arguments for the current model --- training_args = TrainingArguments( output_dir=output_dir, num_train_epochs=NUM_EPOCHS, per_device_train_batch_size=BATCH_SIZE_TRAIN, per_device_eval_batch_size=BATCH_SIZE_EVAL, warmup_steps=WARMUP_STEPS, weight_decay=WEIGHT_DECAY, learning_rate=LEARNING_RATE, logging_steps=100, eval_strategy="epoch", save_strategy="epoch" if SAVE_MODEL else "no", load_best_model_at_end=SAVE_MODEL, metric_for_best_model= "eval_accuracy" if SAVE_MODEL else None, greater_is_better=True, save_total_limit=SAVE_TOTAL_LIMIT_FOR_SWA if SAVE_MODEL else 0, # 수정: SWA 위해 늘림 label_smoothing_factor=0.18547040498752376, report_to="wandb" if USE_WANDB else "none", run_name=run_name if USE_WANDB else None, seed=current_seed, fp16=torch.cuda.is_available(), dataloader_num_workers=2, remove_unused_columns=False, push_to_hub=False, gradient_accumulation_steps=4, logging_first_step=True, save_safetensors=SAVE_MODEL, lr_scheduler_type= "constant", # early_stopping_patience=3, # Keep early stopping if desired # early_stopping_threshold=0.001, ) early_stopping_callback = EarlyStoppingCallback(early_stopping_patience=3) # <--- 원하는 patience 값 # --- Initialize Trainer for the current model --- trainer = CustomTrainerWithFocalLoss( model=current_model, args=training_args, train_dataset=train_dataset_current, eval_dataset=val_dataset_current, # tokenizer=current_tokenizer, num_classes=NUM_CLASSES, callbacks=[early_stopping_callback], focal_loss_alpha=[1, 1, 1, 1], # Adjust alpha if needed focal_loss_gamma=2.965201490877045, data_collator=DataCollatorWithPadding(tokenizer=current_tokenizer), compute_metrics=compute_metrics, ) ``` ```python # --- Training Execution --- print(f"훈련 정보 ({model_name}):") print(f" 훈련 샘플: {len(train_dataset_current):,}개") print(f" 검증 샘플: {len(val_dataset_current):,}개") print(f" 훈련 에포크: {training_args.num_train_epochs}회") print(f" 배치 크기: {BATCH_SIZE_TRAIN} (훈련) / {BATCH_SIZE_EVAL} (검증)") print(f" 학습률: {LEARNING_RATE}") print(f" 시드값: {current_seed}") print(f" 디바이스: {device}") print(f" wandb 사용: {USE_WANDB}") try: training_result = trainer.train() print(f"\n{model_name} 훈련 완료") print(f" 최종 훈련 손실: {training_result.training_loss:.4f}") all_training_results[model_name] = training_result # --- Save the final best model --- if SAVE_MODEL: best_model_path = f"{output_dir}/best_model_{model_short_name}" print(f"최종 베스트 모델 저장 중: {best_model_path}") trainer.save_model(best_model_path) current_tokenizer.save_pretrained(best_model_path) print(f"최종 베스트 모델 저장 완료: {best_model_path}") # === SWA (Stochastic Weight Averaging) 적용 시작 === print(f"\n--- SWA 가중치 평균 시작 (모델: {model_name}) ---") print(f"마지막 {SWA_K}개 체크포인트를 평균냅니다.") try: # 1. SWA에 사용할 체크포인트 경로 찾기 checkpoint_dir = output_dir checkpoints = sorted( glob.glob(os.path.join(checkpoint_dir, "checkpoint-*")), key=lambda x: int(x.split('-')[-1]) # 스텝 번호 기준 정렬 ) if len(checkpoints) >= SWA_K: swa_checkpoints = checkpoints[-SWA_K:] print(f"SWA에 사용할 체크포인트 ({len(swa_checkpoints)}개):") for ckpt in swa_checkpoints: print(f" - {os.path.basename(ckpt)}") # 2. 기본 모델 로드 (구조만 사용) # best_model_path에서 config를 로드하여 동일한 구조 보장 print("SWA 기본 모델 구조 로딩 중...") config = AutoConfig.from_pretrained(best_model_path) swa_base_model = AutoModelForSequenceClassification.from_config(config) swa_base_model.to(device) # 3. 가중치 평균내기 print("체크포인트 가중치 평균 계산 중...") avg_state_dict = OrderedDict() model_keys = swa_base_model.state_dict().keys() # 모델 키 저장 for i, checkpoint_path in enumerate(swa_checkpoints): print(f" ({i+1}/{len(swa_checkpoints)}) 체크포인트 로딩: {checkpoint_path}") # safetensors 우선 로드 시도 safetensors_path = os.path.join(checkpoint_path, "model.safetensors") bin_path = os.path.join(checkpoint_path, "pytorch_model.bin") if os.path.exists(safetensors_path): state_dict = load_safetensors_file(safetensors_path, device="cpu") elif os.path.exists(bin_path): state_dict = torch.load(bin_path, map_location="cpu") else: print(f" 경고: {checkpoint_path} 에서 모델 파일을 찾을 수 없습니다. 건너<0xEB><0x9A><0x8D>니다.") continue # 평균 계산 (첫 번째 체크포인트는 복사, 이후는 더하기) for key in model_keys: if key not in state_dict: print(f" 경고: 키 '{key}'가 체크포인트에 없습니다. 건너<0xEB><0x9A><0x8D>니다.") continue if i == 0: avg_state_dict[key] = state_dict[key].clone().float() # float()로 타입 통일 else: if key in avg_state_dict: avg_state_dict[key] += state_dict[key].float() # float()로 타입 통일 else: print(f" 경고: 이전 체크포인트에 없던 키 '{key}' 발견. 건너<0xEB><0x9A><0x8D>니다.") del state_dict # 메모리 확보 # 평균 계산 (K로 나누기) num_averaged = len(swa_checkpoints) # 실제 로드된 체크포인트 수 if num_averaged > 0: for key in avg_state_dict: avg_state_dict[key] /= num_averaged # 4. 평균낸 가중치를 모델에 로드 missing_keys, unexpected_keys = swa_base_model.load_state_dict(avg_state_dict, strict=False) if missing_keys: print(f" 경고: 로드되지 않은 키: {missing_keys}") if unexpected_keys: print(f" 경고: 예상치 못한 키: {unexpected_keys}") print("평균 가중치 모델에 로드 완료.") # 5. 배치 정규화(Batch Normalization) 통계 업데이트 (매우 중요!) print("배치 정규화 통계 업데이트 중...") # update_bn 함수는 DataLoader가 필요 swa_data_collator = DataCollatorWithPadding(tokenizer=current_tokenizer) train_dataloader_for_bn = DataLoader( train_dataset_current, batch_size=BATCH_SIZE_TRAIN, # 훈련 배치 크기 사용 권장 collate_fn=swa_data_collator, shuffle=False, # BN 업데이트 시에는 셔플 불필요 num_workers=2 ) # update_bn 함수 호출 # swa_utils.update_bn()은 AveragedModel 객체를 받지만, # 여기서는 직접 평균낸 모델을 사용하므로, 수동 루프 또는 아래와 같이 직접 호출 swa_base_model.train() # BN 업데이트는 train 모드에서 with torch.no_grad(): num_batches_tracked = 0 for batch in tqdm(train_dataloader_for_bn, desc="BN 업데이트", leave=False): inputs = {k: v.to(device) for k, v in batch.items() if k in ['input_ids', 'attention_mask', 'token_type_ids']} if not inputs: continue # 입력이 없는 경우 건너뛰기 swa_base_model(**inputs) num_batches_tracked += 1 if num_batches_tracked >= 100: # 전체 데이터 대신 일부(예: 100 배치)만 사용해도 충분할 수 있음 break swa_base_model.eval() # 다시 eval 모드로 print(f"배치 정규화 통계 업데이트 완료 (약 {num_batches_tracked} 배치 사용).") # 6. SWA 모델 저장 swa_model_path = f"{output_dir}/swa_model_{model_short_name}" os.makedirs(swa_model_path, exist_ok=True) print(f"SWA 모델 저장 중: {swa_model_path}") # state_dict() 저장 방식 사용 torch.save(swa_base_model.state_dict(), os.path.join(swa_model_path, "pytorch_model.bin")) # save_pretrained는 전체 모델 객체를 저장하려 하므로 여기서는 state_dict 저장 권장 # swa_base_model.save_pretrained(swa_model_path) # 필요시 사용 가능 current_tokenizer.save_pretrained(swa_model_path) # 토크나이저도 함께 저장 # config.json도 저장 (save_pretrained가 없으므로 수동 복사 또는 저장) config.save_pretrained(swa_model_path) print(f"SWA 모델 저장 완료: {swa_model_path}") else: print("평균낼 유효한 체크포인트가 없습니다.") else: print(f"SWA를 위한 체크포인트가 충분하지 않습니다 ({len(checkpoints)}개 발견, {SWA_K}개 필요). SWA를 건너<0xEB><0x9A><0x8D>니다.") except Exception as e: print(f"SWA 처리 중 오류 발생: {e}") finally: # SWA 모델 객체 메모리 정리 (필요시) if 'swa_base_model' in locals(): del swa_base_model if torch.cuda.is_available(): torch.cuda.empty_cache() print("--- SWA 가중치 평균 종료 ---") # === SWA 적용 종료 === except KeyboardInterrupt: print(f"\n사용자에 의해 {model_name} 훈련이 중단되었습니다.") # Optionally break the loop if one model training is interrupted # break except Exception as e: print(f"\n{model_name} 훈련 중 오류 발생: {str(e)}") # Optionally log the error and continue with the next model # continue # --- Clean up GPU memory before next model --- del current_model del current_tokenizer del trainer if torch.cuda.is_available(): torch.cuda.empty_cache() print("\n" + "=" * 50) print("모든 모델 훈련 완료!") print("=" * 50) ``` 우선 앙상블할 각 모델마다 랜덤시드를 다르게주도록 구현해서 모델들이 보는 데이터셋의 분산을 키우고자 했다. 일반적으로 앙상블의 효과는 각 모델이 상이한 부분에서 하는 실수를 매꿀때 극대화 되므로 서로다른 모델이 학습할때마다 루프안에서 다른 랜덤시드를 가지도록 코드로 구현했다. ### 앙상블한 결과  모델 3개를 앙상블한 결과 acc가 0.7% 올랐다. 즉 유의미한 효과가 있었다.  이전 실험과 마찬가지로 최종 예측분포를 보면 전체 데이터셋의 분포와 비슷하게 맞춤을 알 수 있다. acc를 높이려면 test 데이터의 분포와 유사해야함을 시사한다. 그리고 소수를 차지하는 분포인 약한부정은 더 덜맞추는 경향성이 있지만, 0,1,3레이블은 더 정교하게 원래 데이터분포와 비슷해졌음을 알 수 있다. 대다수의 레이블을 잘 못추면 역시 acc가 올라감을 확인할 수 있었다. # 이후 실험에서 고려해야 할 것들 - 하이퍼파라미터 튜닝 - Focal Loss에서 알파 가중치를 얼마나 줘야할까? - 최적의 알파 가중치는 얼마일까? - 이외에 하이퍼파라미터 튜닝할 수 있는값 모두 넣기 - valid 데이터를 포함해서 전체 데이터를 기준으로 학습시켜보기 - 모델 앙상블 추론을 할때, 모델별로 Weight를 줘서 앙상블을 해보기 ### [영화리뷰 감성분류][모델최적화]마지막 시도, 그리고 반성 - Canonical URL: https://hyejunl33.github.io/projects/2025-11-02-[Domain_Common_Project]TAPT/ - Collection: Project - Published: 2025-11-01 - Tags: Domain_Common_Project, study, ModelOptimization # Introduction - tapt적용 - 전체데이터에 대해서 5개모델 다시 학습 후 앙상블 → 시간부족으로 못해봄 - 전체데이터셋으로 학습시킨 모델 효과있는지 실험→ 시간부족으로 못해봄 - 5개모델 acc를 Weight로 줘서 앙상블 - 역번역증강 사용할지 말지 결정 → 번역의 품질이 안좋아서 결국엔 사용 x 저번실험까지 해서 기껏 하이퍼파라미터 튜닝을 해뒀는데 TAPT라는 새로운 기법에 대해 알게됐다. 일반적으로 BERT모델을 내가 원하는 TASK에 FineTuning하는 기법인데, 이 기법을 사용하면 성능이 일반적으로 향상된다고 한다. 이 기법을 하이퍼파라미터 튜닝을 한 후에 알게되어서, 대회 종료까지 2일 남은 시점에서, 다시 하이퍼파라미터 튜닝을 해야하는 상황에 처해졌다. 따라서 TAPT를 일단 적용해보고, 기존에 찾았던 하이퍼파라미터를 이용해서 성능을 테스트해보기로 했다. [TAPT정리글](https://hyejunl33.github.io/projects/2025-11-01-%5BDomain_Common_Project%5DTAPT/) 그 외에도 모델마다 acc성능이 다르므로, 추론단계에서 모델을 앙상블 할때 그냥 logit을 softvoting하는게 아니라, 모델간의 acc를 가중치로 줘서 softvoting하는 방법을 구현했다. 역번역 증강은 코드까지는 구현했으나, 강한부정, 강한긍정에서는 어느정도 문맥이 유지되는듯 했는데, 약한긍정, 약한부정을 역번역하니, 문맥이 아예 다른 데이터들이 생성되는것을 확인했다. 더 정교한 모델을 사용하면, 역번역 증강을 사용해서 데이터를 효율적으로 늘릴 수 있겠으나, 데이터를 늘리더라도, 최적의 하이퍼파라미터를 다시 학습하는데에는 시간이 없으므로, 역번역 증강은 이번대회에서는 사용하지 않기로 했다. 기존의 방식은 Traindata를 valid,train으로 다시 나눠서 학습용과 검증데이터를 나눠서 학습을 진행했다. 하지만 일반적으로 최종 모델을 학습할떄는 전체 데이터에 대해서 다시 학습한 후 앙상블을 한다고 한다. 이또한 앙상블을 하려면 최소 3개의 모델을 전체 데이터에 대해서 다시 학습을 해야하는데, 코드까지는 구현했으나, 시간부족으로 모델로 반영하지는 못했다. # Weighted Model Ensemble ```python # === Ensemble Inference Block (Weighted Averaging) === # Replace the original inference cell (ID: 079c8f40) with this code. import torch import numpy as np import os from tqdm.auto import tqdm # Import tqdm for progress bar from transformers import AutoTokenizer, AutoModelForSequenceClassification, Trainer, TrainingArguments, DataCollatorWithPadding import shutil # Import shutil for directory removal print(f"현재 디바이스: {device}") # --- Load Test Data --- df_test = pd.read_csv("data/test.csv") print(f"테스트 데이터 로드 완료: {len(df_test)} 샘플") # --- Apply Preprocessing --- # Use the 'preprocessor' instance fitted during training print("테스트 데이터에 전처리 파이프라인 적용 중...") test_texts = df_test["review"].tolist() # Use transform only, assumes preprocessor is already fitted # Ensure the preprocessor was fitted during the training phase if not preprocessor.is_fitted: # If the preprocessor wasn't fitted (e.g., running inference separately), # you might need to fit it here or load a saved preprocessor state. # For now, we'll just apply basic preprocessing. print("Warning: Preprocessor가 fit되지 않았습니다. 기본 전처리만 적용합니다.") test_processed = preprocessor.basic_preprocess(test_texts) else: test_processed = preprocessor.transform(test_texts) # Apply transform including rare word removal if fitted print("테스트 데이터 전처리 완료") # --- List of Trained Model Paths --- # Ensure these paths match where models were saved in the training block # 수정: best_model 대신 swa_model 경로를 사용하도록 변경 model_names = [ "./tapted_klue_roberta_base", "./tapted_klue_bert_base", "./tapted_kykim_bert_kor_base", "./tapted_beomi_kcbert_base", "./tapted_koelectra_base_v3" ] model_paths = [ f"./results_{model_name.split('/')[-1].replace('-', '_')}/swa_model_{model_name.split('/')[-1].replace('-', '_')}" # <-- swa_model 로 변경 for model_name in model_names # Use the same model_names list from training ] print(model_paths) # model_paths = [ # f"./results_{model_name.split('/')[-1].replace('-', '_')}/best_model_{model_name.split('/')[-1].replace('-', '_')}" # <-- swa_model 로 변경 # for model_name in model_names # Use the same model_names list from training # ] # --- Define Model Weights (Based on Validation Performance) --- # 각 모델의 검증 데이터셋 F1 score (또는 Accuracy) 값으로 반드시 교체해야 합니다. # 이거 f1으로 할지 accuracy로할지 둘다 해보기 # model_paths 리스트의 모델 순서와 동일하게 값을 넣어야 합니다. model_performance_scores = { model_paths[0]: 0.8114, #roberta model_paths[1]: 0.8056, # 예시: tapted_klue_bert_base SWA 모델의 검증 F1 model_paths[2]: 0.8179, # 예시: tapted_kykim_bert_kor_base SWA 모델의 검증 F1 model_paths[3]: 0.7961, # 예시: tapted_beomi_kcbert_base SWA 모델의 검증 F1 model_paths[4]: 0.8077 #koelectra # 다른 모델 추가 시 여기에 성능 점수 추가 } # --- Ensemble Inference --- all_logits = [] successful_model_paths = [] # 추론에 성공한 모델 경로 저장 print("\n" + "=" * 50) print("앙상블 추론 시작...") print("=" * 50) for model_path in tqdm(model_paths, desc="모델별 추론 진행"): if not os.path.exists(model_path): print(f"Warning: 모델 경로를 찾을 수 없습니다: {model_path}. 이 모델을 건너뜁니다.") continue print(f"\n모델 로딩: {model_path}") try: # Load tokenizer and model for the current path current_tokenizer = AutoTokenizer.from_pretrained(model_path) current_model = AutoModelForSequenceClassification.from_pretrained(model_path) current_model.to(device) current_model.eval() # Create test dataset with the current tokenizer test_dataset_current = ReviewDataset( pd.Series(test_processed), # Pass processed text as a Series None, # No labels for test set current_tokenizer, CHOSEN_MAX_LENGTH ) # Define minimal TrainingArguments for prediction temp_output_dir = f"./temp_prediction_{os.path.basename(model_path)}" predict_args = TrainingArguments( output_dir=temp_output_dir, per_device_eval_batch_size=BATCH_SIZE_EVAL * 2, # Increase batch size for faster inference dataloader_num_workers=2, remove_unused_columns=False, # Keep columns needed by dataset fp16=torch.cuda.is_available(), logging_steps=len(test_dataset_current) // (BATCH_SIZE_EVAL * 2) + 1 # Reduce logging ) # Initialize Trainer for prediction pred_trainer = Trainer( model=current_model, args=predict_args, # tokenizer=current_tokenizer, # Trainer에서는 tokenizer 없어도 됨 data_collator=DataCollatorWithPadding(tokenizer=current_tokenizer), ) # Get predictions (logits) print(f"모델 추론 중: {model_path}") predictions = pred_trainer.predict(test_dataset_current) logits = predictions.predictions # Logits are in predictions.predictions all_logits.append(logits) successful_model_paths.append(model_path) # 성공한 모델 경로 추가 print(f"모델 추론 완료: {model_path}") # Clean up memory del current_model del current_tokenizer del pred_trainer if torch.cuda.is_available(): torch.cuda.empty_cache() # Clean up temporary directory if os.path.exists(temp_output_dir): shutil.rmtree(temp_output_dir) except Exception as e: print(f"Error during inference for model {model_path}: {e}") # Decide whether to continue or stop if one model fails # continue # 오류 발생 시 해당 모델 건너뛰기 # --- Weighted Averaging Logits --- if not all_logits: raise ValueError("추론 결과가 없습니다. 모델 경로 또는 추론 과정을 확인하세요.") print("\n로짓(logits) 가중 평균 계산 중...") # Convert list of numpy arrays to a numpy array for easier calculation all_logits_np = np.array(all_logits) # Filter performance scores for successfully loaded models relevant_scores = [model_performance_scores[path] for path in successful_model_paths if path in model_performance_scores] if len(relevant_scores) != all_logits_np.shape[0]: print(f"Warning: 추론된 모델 수({all_logits_np.shape[0]})와 유효한 성능 점수 개수({len(relevant_scores)})가 다릅니다. 단순 평균을 사용합니다.") # Fallback to simple mean if weights don't match (e.g., model failed or score missing) average_logits = np.mean(all_logits_np, axis=0) else: # Calculate weights based on performance scores (Normalization) total_score = sum(relevant_scores) if total_score == 0: # Avoid division by zero if all scores are 0 print("Warning: 모든 모델 성능 점수가 0입니다. 동일 가중치를 사용합니다.") weights = np.ones(len(relevant_scores)) / len(relevant_scores) else: weights = np.array([score / total_score for score in relevant_scores]) print(f"사용된 모델 경로: {successful_model_paths}") print(f"해당 모델 가중치: {weights}") # Calculate the weighted average logits across models (axis=0) average_logits = np.average(all_logits_np, axis=0, weights=weights) print(f"가중 평균 로짓 계산 완료. 형태: {average_logits.shape}") # --- Final Prediction --- predicted_labels = np.argmax(average_logits, axis=1) print(f"최종 예측 레이블 생성 완료: {len(predicted_labels)}개") # --- Add predictions to the test DataFrame --- df_test["pred"] = predicted_labels print(f"\ndf_test에 pred 컬럼이 추가되었습니다. 형태: {df_test.shape}") # --- Analyze Prediction Distribution --- unique_predictions, counts = np.unique(predicted_labels, return_counts=True) print("\n최종 예측 분포:") # Ensure LABEL_MAPPING is defined in your environment if 'LABEL_MAPPING' not in globals(): LABEL_MAPPING = {0: "강한 부정", 1: "약한 부정", 2: "약한 긍정", 3: "강한 긍정"} # Define if not present for pred, count in zip(unique_predictions, counts): percentage = (count / len(predicted_labels)) * 100 class_name = LABEL_MAPPING.get(pred, f"클래스 {pred}") print(f" {class_name} ({pred}): {count:,}개 ({percentage:.1f}%)") print("\n" + "=" * 50) print("앙상블 추론 완료!") print("=" * 50) # GPU 메모리 정리 if torch.cuda.is_available(): torch.cuda.empty_cache() # Note: The code for creating and saving the submission file remains the same # It should follow this block, using the df_test DataFrame which now has the 'pred' column ```   최종 목표가 test/acc를 향상시키는 것인만큼 각 모델의 가중치는 각 단일모델의 test/acc를 확인하고, 이 acc를 정규화 한 후 가중치로 사용했다.  단일모델로서 가장 성능이 잘나왔던 RoBERTa와 Kykim-BERT두개를 앙상블한것보다, 전체 모델 5개를 앙상블한 결과가 더 성능이 잘나오는 것을 확인할 수 있었다. Bagging에 의해 서로다른 모델을 사용하면 일반적으로 선형적으로 성능이 향상됨을 확인할 수 있었다. # 전체 데이터를 이용한 학습 ```python # === 최종 모델 재학습 (전체 데이터 활용) 블록 === # 이 블록은 앙상블 훈련(ID: 176174ee) 이후에 실행합니다. import pandas as pd import torch from transformers import AutoTokenizer, AutoModelForSequenceClassification, TrainingArguments, DataCollatorWithPadding, Trainer import os import shutil # 추가: 디렉토리 관리용 print("\n" + "="*60) print("🚀 전체 데이터(학습+검증)를 사용한 최종 모델 재학습 시작") print("="*60 + "\n") # --- 설정값 --- # 1. 재학습할 기반 모델 이름 및 경로 선택 # !!! 중요: 초기 훈련/검증에서 가장 좋은 성능을 보인 모델의 이름을 지정하세요. # (예: Wandb 로그에서 eval_loss가 가장 낮거나 eval_f1/eval_accuracy가 가장 높았던 모델) # SWA 모델이 더 좋았다면 해당 모델 경로를 initial_model_path로 직접 지정해도 됩니다. BEST_PERFORMING_MODEL_NAME = "./tapted_kykim_bert_kor_base" # <--- 실제 최적 모델 이름으로 변경하세요 (예시) best_model_short_name = BEST_PERFORMING_MODEL_NAME.split('/')[-1].replace('-', '_') # 초기 훈련 결과에서 'best_model' 경로를 사용합니다. # SWA 모델을 기반으로 재학습하려면 이 경로를 swa_model 경로로 변경하세요. # initial_model_path = f"./results_{best_model_short_name}/best_model_{best_model_short_name}" # 예: SWA 기반 재학습 시 initial_model_path = f"./results_{best_model_short_name}/swa_model_{best_model_short_name}" print(f"선택된 기반 모델: {BEST_PERFORMING_MODEL_NAME}") print(f"기반 모델 경로: {initial_model_path}") if not os.path.exists(initial_model_path): raise FileNotFoundError(f"기반 모델 경로를 찾을 수 없습니다: {initial_model_path}. 경로를 확인하거나 이전 훈련을 완료하세요.") # 2. 전체 데이터 재학습 시 사용할 에포크 수 # !!! 중요: 초기 훈련 중 검증 데이터에서 최적 성능(예: 가장 낮은 eval_loss)을 보였던 # 에포크 수를 확인하여 설정하세요. (Wandb 등 로그 확인 필요) FINAL_TRAIN_EPOCHS = 5 # <--- 실제 최적 에포크 수로 변경하세요 (예시) print(f"재학습 에포크 수: {FINAL_TRAIN_EPOCHS}") # 3. 최종 모델을 저장할 디렉토리 경로 final_output_dir = f"./final_model_{best_model_short_name}_fulldata" print(f"최종 모델 저장 경로: {final_output_dir}\n") # 4. 사용할 하이퍼파라미터 (초기 훈련의 최적값 유지) # 이 값들은 이전 셀(ID: b5ba58df) 및 훈련 루프(ID: 176174ee)에서 사용된 값과 동일해야 합니다. FINAL_LEARNING_RATE = LEARNING_RATE FINAL_WEIGHT_DECAY = WEIGHT_DECAY FINAL_WARMUP_STEPS = WARMUP_STEPS FINAL_BATCH_SIZE_TRAIN = BATCH_SIZE_TRAIN FINAL_GRAD_ACCUM_STEPS = 4 # 초기 훈련과 동일하게 설정 (training_args에서 확인) FINAL_LABEL_SMOOTHING = 0.03442149572139974 # 초기 훈련 값 (training_args에서 확인) FINAL_LR_SCHEDULER = "constant" # 초기 훈련 값 (training_args에서 확인) # Focal Loss 파라미터 (CustomTrainerWithFocalLoss 초기화 시 사용된 값) FINAL_FOCAL_ALPHA = [1,1,1,1] FINAL_FOCAL_GAMMA = 4.194768435552584 # --- 1. 학습 + 검증 데이터 합치기 --- print("📊 학습 데이터와 검증 데이터 합치는 중...") # train_data와 val_data는 이전 데이터 분할 셀(ID: e6e4ca17)에서 생성된 변수입니다. if 'train_data' not in globals() or 'val_data' not in globals(): raise NameError("train_data 또는 val_data 변수를 찾을 수 없습니다. 이전 데이터 분할 셀을 실행했는지 확인하세요.") full_train_data = pd.concat([train_data, val_data], ignore_index=True) print(f" 전체 학습 데이터 크기: {len(full_train_data):,}개") print(f" 합쳐진 데이터 샘플 확인 (처음 3개):\n{full_train_data.head(3)}\n") # --- 2. 기반 모델 및 토크나이저 로드 --- print(f"🔩 기반 모델 및 토크나이저 로딩: {initial_model_path}") try: final_tokenizer = AutoTokenizer.from_pretrained(initial_model_path) final_model = AutoModelForSequenceClassification.from_pretrained( initial_model_path, num_labels=NUM_CLASSES, # 클래스 수는 동일 ) final_model.to(device) # GPU로 이동 print(" 모델 로딩 완료.") # 특수 토큰 추가 및 임베딩 리사이즈 (초기 훈련과 동일하게 수행) num_added = final_tokenizer.add_tokens(NEW_SPECIAL_TOKENS) if num_added > 0: final_model.resize_token_embeddings(len(final_tokenizer)) print(f" {num_added}개의 특수 토큰 추가 및 임베딩 리사이즈 완료.") except Exception as e: print(f"❌ 모델 로딩 중 오류 발생: {e}. 재학습을 중단합니다.") # 필요한 경우 여기서 중단 raise e # --- 3. 전체 데이터셋 생성 --- print("\n📚 전체 데이터에 대한 PyTorch 데이터셋 생성 중...") # ReviewDataset 클래스는 이전 셀(ID: 1751489f)에 정의되어 있어야 합니다. full_train_dataset = ReviewDataset( full_train_data["review"], # 합쳐진 데이터의 전처리된 리뷰 사용 full_train_data["label"], # 합쳐진 데이터의 레이블 사용 final_tokenizer, CHOSEN_MAX_LENGTH, ) print(f" 전체 데이터셋 생성 완료: {len(full_train_dataset):,}개") # --- 4. 훈련 설정 (TrainingArguments) 변경 --- # - 검증(evaluation) 비활성화 # - 최적 모델 로딩 비활성화 # - Wandb 로깅 비활성화 (선택 사항) print("\n⚙️ 최종 훈련을 위한 TrainingArguments 설정 중...") final_training_args = TrainingArguments( output_dir=final_output_dir, # 새로운 출력 디렉토리 num_train_epochs=FINAL_TRAIN_EPOCHS, # 결정된 최종 에포크 수 per_device_train_batch_size=FINAL_BATCH_SIZE_TRAIN, # 기존 훈련 배치 크기 gradient_accumulation_steps=FINAL_GRAD_ACCUM_STEPS, # 기존 값 # --- 검증 관련 설정 제거/변경 --- eval_strategy="no", # 검증 안 함 # --- 저장 관련 설정 --- save_strategy="epoch", # 에포크마다 저장 (마지막 모델만 필요하면 "no" 또는 마지막 에포크만 저장) save_total_limit=1, # 마지막 체크포인트만 저장 (필요시 늘림) load_best_model_at_end=False, # 최적 모델 로딩 안 함 (검증 없으므로) metric_for_best_model= None, # --- 기존 하이퍼파라미터 유지 --- warmup_steps=FINAL_WARMUP_STEPS, weight_decay=FINAL_WEIGHT_DECAY, learning_rate=FINAL_LEARNING_RATE, label_smoothing_factor=FINAL_LABEL_SMOOTHING, lr_scheduler_type=FINAL_LR_SCHEDULER, # --- 기타 설정 --- logging_steps=100, # 로그 간격 (데이터 양 고려하여 조정 가능) seed=RANDOM_STATE, # 재현성을 위한 시드 고정 fp16=torch.cuda.is_available(), # FP16 사용 (GPU 사용 시) dataloader_num_workers=2, # 데이터 로더 워커 수 remove_unused_columns=False, # ReviewDataset에서 사용하는 컬럼 유지 save_safetensors=True, # Safetensors 형식으로 저장 권장 logging_first_step=True, report_to="none", # 최종 재학습은 Wandb 로깅 안 함 (선택 사항) # push_to_hub=False, # 허깅페이스 허브 푸시 안 함 ) print(" TrainingArguments 설정 완료.") # --- 5. 최종 Trainer 초기화 --- # - Focal Loss 사용 (CustomTrainerWithFocalLoss 클래스 필요) # - 검증 데이터셋, 메트릭 계산, 콜백 제거 print("\n🔧 최종 Trainer (CustomTrainerWithFocalLoss) 초기화 중...") # CustomTrainerWithFocalLoss 클래스는 이전 셀(ID: eca0c60f)에 정의되어 있어야 합니다. final_trainer = CustomTrainerWithFocalLoss( model=final_model, # 로드된 기반 모델 args=final_training_args, # 최종 훈련 설정 train_dataset=full_train_dataset, # 전체 학습 데이터셋 eval_dataset=None, # 검증 데이터셋 없음 tokenizer=final_tokenizer, # DataCollator에 필요 num_classes=NUM_CLASSES, # 클래스 수 focal_loss_alpha=FINAL_FOCAL_ALPHA, # 기존 Focal Loss alpha focal_loss_gamma=FINAL_FOCAL_GAMMA, # 기존 Focal Loss gamma data_collator=DataCollatorWithPadding(tokenizer=final_tokenizer), # 패딩 처리 compute_metrics=None, # 검증 안 하므로 메트릭 계산 불필요 callbacks=None, # EarlyStopping 등 콜백 제거 ) print(" Trainer 초기화 완료.") # --- 6. 전체 데이터로 재학습 실행 --- print(f"\n💪 전체 데이터로 {FINAL_TRAIN_EPOCHS} 에포크 재학습 시작...") try: train_result = final_trainer.train() print(" 재학습 성공적으로 완료.") print(f" 총 훈련 시간: {train_result.metrics['train_runtime']:.2f}초") print(f" 최종 훈련 손실: {train_result.metrics['train_loss']:.4f}") except KeyboardInterrupt: print("\n⚠️ 사용자에 의해 재학습이 중단되었습니다.") except Exception as e: print(f"\n❌ 재학습 중 오류 발생: {e}") # 필요한 경우 오류 처리 로직 추가 raise e # --- 7. 최종 모델 저장 --- print(f"\n💾 훈련 완료된 최종 모델 저장 중: {final_output_dir}") try: # 기존 디렉토리가 있으면 삭제 (덮어쓰기 위해) if os.path.exists(final_output_dir): print(f" 기존 디렉토리 삭제: {final_output_dir}") shutil.rmtree(final_output_dir) final_trainer.save_model(final_output_dir) # 모델 가중치 및 설정 저장 final_tokenizer.save_pretrained(final_output_dir) # 토크나이저 파일 저장 print(f" 최종 모델 및 토크나이저 저장 완료: {final_output_dir}") # 저장된 파일 확인 if os.path.exists(final_output_dir): saved_files = os.listdir(final_output_dir) print(f" 저장된 파일 목록: {saved_files}") except Exception as e: print(f"❌ 최종 모델 저장 중 오류 발생: {e}") # 필요한 경우 오류 처리 로직 추가 # --- 8. 메모리 정리 --- print("\n🧹 메모리 정리 중...") del final_model del final_tokenizer del final_trainer del full_train_dataset del full_train_data if 'train_result' in globals(): del train_result # 훈련 결과 객체도 삭제 if torch.cuda.is_available(): torch.cuda.empty_cache() print(" GPU 캐시 비움 완료.") print(" 메모리 정리 완료.") print("\n" + "="*60) print("✅ 전체 데이터 재학습 및 최종 모델 저장 완료!") print(f" 최종 모델은 '{final_output_dir}' 경로에 저장되었습니다.") print(" 추론(Inference) 시 이 경로의 모델을 사용하세요.") print("="*60) ``` 각 모델을 이전에 학습하는 train코드와 같은 방식을 공유하되, train, validation 데이터를 나누지 않고 전체 데이터를 사용해서 학습하는 코드를 구현했다. 일반적으로, 가장 성능이 좋았던 모델을 골라서, 다시 전체 데이터로 학습을 해서 제출한다고 한다. 하지만, 시간이 부족해서 다시 모델들을 재학습해보지는 못했다. # 결과    TAPT, FocalLoss의 $\alpha$가중치, SWA할 모델의 수등을 이전의 하이퍼파라미터 튜닝세팅과 다르게 해서인지, 이전에 BERT기반 3개모델을 앙상블했을때보다 성능이 비슷하거나 소폭하락했었다. 따라서 이전에 실험했던 모델들을 최종 제출했고, private score는 0.8301로 Final Leaderboard는 98위로 마무리했다. 첫 경진대회 참여라서 좋은 성과는 내지 못했지만 처음알고, 얻어가는것들이 많은 대회경험이었다. 하이퍼파라미터 튜닝을 하는 도중에 TAPT기법으로 모델성능을 향상시키는 방법을 알게되었고, BackTrainslation을 이용해서 효과적으로 데이터를 증강하거나, 전체 데이터셋을 이용해서 학습해서 성능을 향상해보는 시도들을 추가로 해보고싶었지만, 시간이 부족했었던것 같다. 모든 실험과 시도들을 해볼 수는 없다는것을 깨달았다. 가장 중요한것을 위주로 실험 우선순위를 결정해야하고, 중요한것부터 실험 자동화 스케줄러를 만들어서 24시간 GPU를 굴리는게 중요하다는것을 깨달았다. - 하이퍼파라미터 튜닝은 가장 마지막과정에 시작해서 대회가 끝나기 직전까지 해야한다. 하이퍼파라미터 튜닝을 미리하면, TAPT적용이나, 데이터 증강등을 적용했을때, 최적의 하이퍼파라미터가 다시 달라지게 되므로 또 해야하는 불상사가 생긴다. EDA, FeatureEngineering등 모델링을 사전에 먼저 충분히 진행한 후 대회가 끝나기 직전까지 하이퍼파라미터 튜닝을 해야한다는것을 알게되었다. - 우선 제일먼저 가능한 SOTA모델들을 실험해보고 사용할 모델을 고르자. 그리고 실험 우선순위를 먼저 정하자. 어떤모델을 사용할것인가를 가장 먼저 결정해야 한다. 이번 대회는 5개 모델을 한정적으로 사용헀기 떄문에, 간단했지만, 다른대회에서는 마지막에 앙상블할 모델들을 먼저 선택하고, 해당 모델들에 맞는 하이퍼파라미터 튜닝을 진행해야한다. 그리고 기간내에 모든 실험들을 해볼 수는 없다. 가장 중요한 실험부터 우선순위를 결정하고, 스케줄러를 이용해서 실험관리를 자동화해야한다. 하루에 10번의 제출을 할 수 있었지만, 많은 시도들을 해보지 못한것에 대한 아쉬움이 남는다. ### [영화리뷰 감성분류][모델최적화]하이퍼파라미터 튜닝 - Canonical URL: https://hyejunl33.github.io/projects/2025-10-28-[Domain_Common_Project]Hyperparameter_Tune/ - Collection: Project - Published: 2025-10-28 - Tags: Domain_Common_Project, study, HyperParameterTuning # Introduction  이전모델에서 FocalLoss를 추가하고 Learning rate scheduler를 “cosine”으로 바꾸고, `label_smoothing`을 적용하고, `weight_decay`값을 키워봤다. regularizastion방법을 썼기떄문에, 에폭을 늘려서 학습해도 될것같아서, 에폭을 기존 5에서 8로 늘렸다.  그 결과 TrainingLoss는 줄어들지면 ValidationLoss는 줄어들지 않는 과적합이 일어났다. 우선 `EarlystoppingPatience`를 3으로 설정했지만 기준을 Accuracy로 잡아서 validation Acc가 증가하는 이상 Early stopping은 적용되지 않았다. 따라서 이번에는 Early stopping기준을 Validation Loss로 잡을 예정이다. 이를 통해 Overfitting을 막을 생각이다. 그리고 하이퍼 파라미터 튜닝을 통해 최적의 `Weight_decay`값, `label_smoothing`값, 그리고 이전에는 적용하지 않았던 `drop_out` 비율까지 찾을 예정이다. 그 외에도 최적의 에폭 수, `Learningrate_scheduler_type` 등 다양한 하이퍼파라미터를 config에 넣어서 최적의 하이퍼 파라미터를 찾을 예정이다. 하이퍼파라미터 튜닝은 Evaluation/Loss를 기준으로 하기때문에, 최대한 Overfitting을 막는 방향으로 하이퍼파라미터 튜닝을 진행할 예정이다. 그리고 이후에 Back Translation을 통한 데이터 증강, 확률적 가중치 평균 (Stochastic Weight Averaging - SWA) 기법을 이용해서 조금더 일반화 성능을 늘려볼 예정이다. 그리고 `kykim/bert-kor-base` 모델이 단일모델로서는 성능이 가장 잘 나온다고 한다. 이 모델을 이용해서 학습을 돌려볼 예정이다. # 하이퍼파라미터 튜닝 ```python # === 훈련 함수 정의 === def train(): # --- 1. W&B Run 초기화 --- os.environ["WANDB_SILENT"] = "true" run = wandb.init(project="klue-bert-sweep-movie-review") config = wandb.config # --- 2. 시드 설정 --- set_seed(RANDOM_STATE) # --- 3. 데이터 전처리 (train 함수 내부에서 실행) --- print(f"Run {run.name}: Preprocessor 생성 (희귀 단어 제거: {config.num_rare_words_to_remove}개)") # 각 run마다 config 값으로 preprocessor 생성 preprocessor = TextPreprocessingPipeline(num_rare_words_to_remove=int(config.num_rare_words_to_remove)) # 원본 훈련 데이터로 fit_transform 수행 print(f"Run {run.name}: 훈련 데이터 전처리 (fit & transform)...") X_train_processed = preprocessor.fit_transform(X_train_orig.tolist(), y_train_orig.tolist()) # 원본 검증 데이터로 transform 수행 print(f"Run {run.name}: 검증 데이터 전처리 (transform)...") X_val_processed = preprocessor.transform(X_val_orig.tolist()) # DataFrame 형태로 변환 (Dataset 클래스 입력용) train_data = pd.DataFrame( {"ID": ids_train_orig.values, "review": X_train_processed, "label": y_train_orig.values} ) val_data = pd.DataFrame( {"ID": ids_val_orig.values, "review": X_val_processed, "label": y_val_orig.values} ) # print(f"Run {run.name}: 데이터 전처리 완료. 훈련: {len(train_data)}, 검증: {len(val_data)}") # Sweep 중 출력 최소화 # --- 4. 모델 및 토크나이저 로드 --- tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME) num_added_toks = tokenizer.add_tokens(NEW_SPECIAL_TOKENS) model = AutoModelForSequenceClassification.from_pretrained( MODEL_NAME, num_labels=NUM_CLASSES, hidden_dropout_prob=config.dropout_rate, attention_probs_dropout_prob=config.dropout_rate ) model.resize_token_embeddings(len(tokenizer)) device = torch.device("cuda" if torch.cuda.is_available() else "cpu") model.to(device) # --- 5. 데이터셋 생성 --- train_dataset = ReviewDataset( train_data["review"], # 전처리된 텍스트 사용 train_data["label"], tokenizer, CHOSEN_MAX_LENGTH, ) val_dataset = ReviewDataset( val_data["review"], # 전처리된 텍스트 사용 val_data["label"], tokenizer, CHOSEN_MAX_LENGTH, ) # --- 6. TrainingArguments 설정 --- output_dir = os.path.join("./results", run.name) training_args = TrainingArguments( output_dir=output_dir, num_train_epochs=int(config.num_train_epochs), per_device_train_batch_size=int(config.per_device_train_batch_size), per_device_eval_batch_size=128, # 평가 배치는 고정 또는 Sweep 파라미터로 추가 warmup_steps=int(config.warmup_steps), weight_decay=config.weight_decay, learning_rate=config.learning_rate, label_smoothing_factor=config.label_smoothing_factor, logging_steps=100, eval_strategy="epoch", save_strategy="epoch", load_best_model_at_end=True, metric_for_best_model="eval_loss", # 검증 손실 기준 greater_is_better=False, # 손실은 낮을수록 좋음 save_total_limit=1, report_to="wandb", run_name=run.name, seed=RANDOM_STATE, fp16=torch.cuda.is_available(), dataloader_num_workers=0, # DataLoader 워커 오류 방지 위해 0으로 설정 remove_unused_columns=False, lr_scheduler_type=config.lr_scheduler_type, # Sweep 값 사용 gradient_accumulation_steps=int(config.gradient_accumulation_steps), # Sweep 값 사용 logging_first_step=True, disable_tqdm=True, # 진행률 표시줄 비활성화 ) # --- 7. EarlyStopping 설정 --- # TrainingArguments에서 patience를 직접 설정할 수 없으므로 Callback 사용 # Sweep config에서 patience 값을 가져오도록 수정 early_stopping_callback = EarlyStoppingCallback( early_stopping_patience=3 # 고정값 사용 (또는 sweep_config에 추가하고 config.early_stopping_patience 사용) # early_stopping_threshold=0.001 # 필요시 설정 ) # --- 8. Trainer 초기화 --- trainer = CustomTrainerWithFocalLoss( model=model, args=training_args, train_dataset=train_dataset, eval_dataset=val_dataset, tokenizer=tokenizer, num_classes=NUM_CLASSES, focal_loss_alpha=[0.11, 0.45, 0.12, 0.32], # 알파는 고정 focal_loss_gamma=config.focal_loss_gamma, # Sweep 값 사용 callbacks=[early_stopping_callback], data_collator=DataCollatorWithPadding(tokenizer=tokenizer), compute_metrics=compute_metrics, ) # --- 9. 훈련 실행 --- try: # print(f"Run {run.name}: 훈련 시작...") # Sweep 중 출력 최소화 trainer.train() # print(f"Run {run.name}: 훈련 완료.") # Sweep 중 출력 최소화 except Exception as e: print(f"Run {run.name}: 훈련 중 오류 발생: {e}") wandb.finish(exit_code=1) raise # --- 10. W&B Run 종료 --- wandb.finish() # === Sweep 설정 === sweep_config = { 'method': 'bayes', 'metric': { 'name': 'eval/loss', 'goal': 'minimize' }, 'parameters': { 'learning_rate': { 'distribution': 'log_uniform_values', 'min': 1e-6, 'max': 5e-5 }, 'num_train_epochs': { 'values': [5, 8, 10, 12] }, 'weight_decay': { 'distribution': 'uniform', 'min': 0.0, 'max': 0.1 }, 'per_device_train_batch_size': { 'values': [64, 128, 256] }, 'warmup_steps': { 'distribution': 'q_uniform', 'min': 100, 'max': 1000, 'q': 50 }, 'focal_loss_gamma': { 'distribution': 'uniform', 'min': 1.0, 'max': 3.0 }, 'label_smoothing_factor': { 'distribution': 'uniform', 'min': 0.0, 'max': 0.2 }, 'dropout_rate': { 'distribution': 'uniform', 'min': 0.05, 'max': 0.3 }, 'lr_scheduler_type': { 'values': ['cosine', 'linear', 'constant'] }, 'gradient_accumulation_steps': { 'values': [1, 2, 4] }, 'num_rare_words_to_remove': { 'values': [0, 3, 5, 10] } # 추가됨 } } # === W&B Sweep 초기화 및 에이전트 실행 === # wandb 로그인 필요 # !wandb login your_api_key sweep_id = wandb.sweep(sweep_config, project="klue-bert-sweep-movie-review") print(f"Sweep ID: {sweep_id}") # 에이전트 실행 (20번 시도) wandb.agent(sweep_id, function=train, count=20) print("W&B Sweep 완료!") ``` ```python sweep_config = { 'method': 'bayes', 'metric': { 'name': 'eval/loss', 'goal': 'minimize' }, 'parameters': { 'learning_rate': { 'distribution': 'log_uniform_values', 'min': 1e-6, 'max': 5e-5 }, 'num_train_epochs': { 'values': [5, 8, 10, 12] }, 'weight_decay': { 'distribution': 'uniform', 'min': 0.0, 'max': 0.1 }, 'per_device_train_batch_size': { 'values': [64, 128, 256] }, 'warmup_steps': { 'distribution': 'q_uniform', 'min': 100, 'max': 1000, 'q': 50 }, 'focal_loss_gamma': { 'distribution': 'uniform', 'min': 1.0, 'max': 3.0 }, 'label_smoothing_factor': { 'distribution': 'uniform', 'min': 0.0, 'max': 0.2 }, 'dropout_rate': { 'distribution': 'uniform', 'min': 0.05, 'max': 0.3 }, 'lr_scheduler_type': { 'values': ['cosine', 'linear', 'constant'] }, 'gradient_accumulation_steps': { 'values': [1, 2, 4] }, 'num_rare_words_to_remove': { 'values': [0, 3, 5, 10] } # 추가됨 } } ``` `config` 를 보면 알 수 있듯이 베이지안 방식으로 learning rate, 에폭 수, weight_decay, 배치사이즈, warmup_step등등을 하이퍼파라미터로 넣어주었다. 이때 이번 실험에서의 목표가 과적합을 막는것이었으므로 Validation/loss를 metric으로 삼고, 이를 minimize하는것을 goal로 설정했다. 따라서 validation loss가 earlystopping patience를 넘는다면 바로 조기종료 될 것이다. 하이퍼파라미터 튜닝을 16번의 step을 거쳐서 진행했다. 원래는 20번으로 실행했는데, 28시간째에, 다른실험도 해봐야해서 일단 Interupt를 했다..  eval/accuracy를 기준으로 상위 5개를 시각화했다. 보라색이 가장 acc가 높아보이지만,validation loss가 불안정하게 커지므로, 과적합되었다고 볼 수 있다. 따라서 그 다음으로 acc가 높은 ancient-sweep-13 하이퍼파라미터를 사용하기로 했다. 최적의 하이퍼파라미터는 모델의 아키텍처마다 다르다고 한다. 따라서 원래는 5개의 모델을 모두 앙상블할 예정이었지만, `klue/bert-base` 모델로 하이퍼파라미터 튜닝을 했으므로, BERT기반 3개로만 앙상블해서 추론한 결과와 5개 모델 전부 같은 하이퍼파라미터를 이용해서 학습한 후 추론한 결과를 비교해볼 예정이다. # 모델 앙상블 모델 앙상블은 학습을 각각의 모델 따로따로 진행해준 후, 추론파트에서 각각의 모델을 불러와서 softVoting방식으로 레이블을 판단한다. ```python # === Ensemble Training Block === # Replace the original training cell (ID: 176174ee) with this code. # --- Model Training Settings --- SAVE_MODEL = True USE_WANDB = True # Set to True if you want to use Weights & Biases logging for each model from transformers import EarlyStoppingCallback # List of models for ensemble model_names = [ # "klue/roberta-base", "klue/bert-base", "kykim/bert-kor-base", "beomi/kcbert-base" # "monologg/koelectra-base-v3-discriminator" ] # --- Loop through each model for training --- all_training_results = {} for model_name in model_names: model_short_name = model_name.split('/')[-1].replace('-', '_') # Create a short name for directories/logging output_dir = f"./results_{model_short_name}" run_name = f"{model_short_name}-movie-review" print("\n" + "=" * 50) print(f"모델 훈련 시작: {model_name}") print(f"결과 저장 경로: {output_dir}") print("=" * 50) # --- Load Model and Tokenizer for the current model --- try: current_tokenizer = AutoTokenizer.from_pretrained(model_name) current_model = AutoModelForSequenceClassification.from_pretrained( model_name, num_labels=NUM_CLASSES, ) current_model.to(device) # Move model to GPU # --- Add new special tokens and resize embeddings --- num_added_toks = current_tokenizer.add_tokens(NEW_SPECIAL_TOKENS) if num_added_toks > 0: print(f"Added {num_added_toks} new special tokens for {model_name}.") current_model.resize_token_embeddings(len(current_tokenizer)) print("Resized model token embeddings.") except Exception as e: print(f"Error loading model {model_name}: {e}") print("Skipping this model.") continue # Skip to the next model if loading fails # --- Recreate Datasets with the current tokenizer --- # This is necessary because different models might have different tokenization train_dataset_current = ReviewDataset( train_data["review"], train_data["label"], current_tokenizer, CHOSEN_MAX_LENGTH, ) val_dataset_current = ReviewDataset( val_data["review"], val_data["label"], current_tokenizer, CHOSEN_MAX_LENGTH, ) # --- Training Arguments for the current model --- training_args = TrainingArguments( output_dir=output_dir, num_train_epochs=NUM_EPOCHS, per_device_train_batch_size=BATCH_SIZE_TRAIN, per_device_eval_batch_size=BATCH_SIZE_EVAL, warmup_steps=WARMUP_STEPS, weight_decay=WEIGHT_DECAY, learning_rate=LEARNING_RATE, logging_steps=100, eval_strategy="epoch", save_strategy="epoch" if SAVE_MODEL else "no", load_best_model_at_end=SAVE_MODEL, metric_for_best_model= "eval_loss" if SAVE_MODEL else None, greater_is_better=False, save_total_limit=1 if SAVE_MODEL else 0, # Save only the best model label_smoothing_factor=0.18547040498752376, report_to="wandb" if USE_WANDB else "none", run_name=run_name if USE_WANDB else None, seed=RANDOM_STATE, fp16=torch.cuda.is_available(), dataloader_num_workers=2, remove_unused_columns=False, push_to_hub=False, gradient_accumulation_steps=4, logging_first_step=True, save_safetensors=SAVE_MODEL, lr_scheduler_type= "constant", # early_stopping_patience=3, # Keep early stopping if desired # early_stopping_threshold=0.001, ) early_stopping_callback = EarlyStoppingCallback(early_stopping_patience=3) # <--- 원하는 patience 값 # --- Initialize Trainer for the current model --- trainer = CustomTrainerWithFocalLoss( model=current_model, args=training_args, train_dataset=train_dataset_current, eval_dataset=val_dataset_current, tokenizer=current_tokenizer, num_classes=NUM_CLASSES, callbacks=[early_stopping_callback], focal_loss_alpha=[0.11, 0.45, 0.12, 0.32], # Adjust alpha if needed focal_loss_gamma=2.965201490877045, data_collator=DataCollatorWithPadding(tokenizer=current_tokenizer), compute_metrics=compute_metrics, ) # --- Training Execution --- print(f"훈련 정보 ({model_name}):") print(f" 훈련 샘플: {len(train_dataset_current):,}개") print(f" 검증 샘플: {len(val_dataset_current):,}개") print(f" 훈련 에포크: {training_args.num_train_epochs}회") print(f" 배치 크기: {BATCH_SIZE_TRAIN} (훈련) / {BATCH_SIZE_EVAL} (검증)") print(f" 학습률: {LEARNING_RATE}") print(f" 시드값: {RANDOM_STATE}") print(f" 디바이스: {device}") print(f" wandb 사용: {USE_WANDB}") try: training_result = trainer.train() print(f"\n{model_name} 훈련 완료") print(f" 최종 훈련 손실: {training_result.training_loss:.4f}") all_training_results[model_name] = training_result # --- Save the final best model --- if SAVE_MODEL: best_model_path = f"{output_dir}/best_model_{model_short_name}" print(f"최종 베스트 모델 저장 중: {best_model_path}") trainer.save_model(best_model_path) current_tokenizer.save_pretrained(best_model_path) print(f"최종 베스트 모델 저장 완료: {best_model_path}") except KeyboardInterrupt: print(f"\n사용자에 의해 {model_name} 훈련이 중단되었습니다.") # Optionally break the loop if one model training is interrupted # break except Exception as e: print(f"\n{model_name} 훈련 중 오류 발생: {str(e)}") # Optionally log the error and continue with the next model # continue # --- Clean up GPU memory before next model --- del current_model del current_tokenizer del trainer if torch.cuda.is_available(): torch.cuda.empty_cache() print("\n" + "=" * 50) print("모든 모델 훈련 완료!") print("=" * 50) ``` 훈련코드는 각각의 훈련과정에서 데이터누수를 막기위해 토크나이저와 모델을 따로 불러온 후, fit과 transform을 따로 진행해준다. 그리고 이전의 baseline code에서처럼 학습을 진행해준다. ```python # === Ensemble Inference Block === # Replace the original inference cell (ID: 079c8f40) with this code. import torch import numpy as np import os from tqdm.auto import tqdm # Import tqdm for progress bar from transformers import AutoTokenizer, AutoModelForSequenceClassification, Trainer, TrainingArguments, DataCollatorWithPadding print(f"현재 디바이스: {device}") # --- Load Test Data --- df_test = pd.read_csv("data/test.csv") print(f"테스트 데이터 로드 완료: {len(df_test)} 샘플") # --- Apply Preprocessing --- # Use the 'preprocessor' instance fitted during training print("테스트 데이터에 전처리 파이프라인 적용 중...") test_texts = df_test["review"].tolist() # Use transform only, assumes preprocessor is already fitted test_processed = preprocessor.transform(test_texts) print("테스트 데이터 전처리 완료") # --- List of Trained Model Paths --- # Ensure these paths match where models were saved in the training block model_paths = [ f"./results_{model_name.split('/')[-1].replace('-', '_')}/best_model_{model_name.split('/')[-1].replace('-', '_')}" for model_name in model_names # Use the same model_names list from training ] # --- Ensemble Inference --- all_logits = [] print("\n" + "=" * 50) print("앙상블 추론 시작...") print("=" * 50) for model_path in tqdm(model_paths, desc="모델별 추론 진행"): if not os.path.exists(model_path): print(f"Warning: 모델 경로를 찾을 수 없습니다: {model_path}. 이 모델을 건너뜁니다.") continue print(f"\n모델 로딩: {model_path}") try: # Load tokenizer and model for the current path current_tokenizer = AutoTokenizer.from_pretrained(model_path) current_model = AutoModelForSequenceClassification.from_pretrained(model_path) current_model.to(device) current_model.eval() # Create test dataset with the current tokenizer test_dataset_current = ReviewDataset( pd.Series(test_processed), # Pass processed text as a Series None, # No labels for test set current_tokenizer, CHOSEN_MAX_LENGTH ) # Define minimal TrainingArguments for prediction temp_output_dir = f"./temp_prediction_{os.path.basename(model_path)}" predict_args = TrainingArguments( output_dir=temp_output_dir, per_device_eval_batch_size=BATCH_SIZE_EVAL * 2, # Increase batch size for faster inference dataloader_num_workers=2, remove_unused_columns=False, # Keep columns needed by dataset fp16=torch.cuda.is_available(), logging_steps=len(test_dataset_current) // (BATCH_SIZE_EVAL * 2) + 1 # Reduce logging ) # Initialize Trainer for prediction pred_trainer = Trainer( model=current_model, args=predict_args, tokenizer=current_tokenizer, data_collator=DataCollatorWithPadding(tokenizer=current_tokenizer), ) # Get predictions (logits) print(f"모델 추론 중: {model_path}") predictions = pred_trainer.predict(test_dataset_current) logits = predictions.predictions # Logits are in predictions.predictions all_logits.append(logits) print(f"모델 추론 완료: {model_path}") # Clean up memory del current_model del current_tokenizer del pred_trainer if torch.cuda.is_available(): torch.cuda.empty_cache() # Clean up temporary directory import shutil if os.path.exists(temp_output_dir): shutil.rmtree(temp_output_dir) except Exception as e: print(f"Error during inference for model {model_path}: {e}") # Decide whether to continue or stop if one model fails # continue # --- Averaging Logits --- if not all_logits: raise ValueError("추론 결과가 없습니다. 모델 경로 또는 추론 과정을 확인하세요.") print("\n로짓(logits) 평균 계산 중...") # Convert list of numpy arrays to a numpy array for easier calculation all_logits_np = np.array(all_logits) # Calculate the average logits across models (axis=0) average_logits = np.mean(all_logits_np, axis=0) print(f"평균 로짓 계산 완료. 형태: {average_logits.shape}") # --- Final Prediction --- predicted_labels = np.argmax(average_logits, axis=1) print(f"최종 예측 레이블 생성 완료: {len(predicted_labels)}개") # --- Add predictions to the test DataFrame --- df_test["pred"] = predicted_labels print(f"\ndf_test에 pred 컬럼이 추가되었습니다. 형태: {df_test.shape}") # --- Analyze Prediction Distribution --- unique_predictions, counts = np.unique(predicted_labels, return_counts=True) print("\n최종 예측 분포:") for pred, count in zip(unique_predictions, counts): percentage = (count / len(predicted_labels)) * 100 class_name = LABEL_MAPPING.get(pred, f"클래스 {pred}") print(f" {class_name} ({pred}): {count:,}개 ({percentage:.1f}%)") print("\n" + "=" * 50) print("앙상블 추론 완료!") print("=" * 50) # GPU 메모리 정리 if torch.cuda.is_available(): torch.cuda.empty_cache() ``` 이후 진행하는 inferece단계에서는 각 모델에서의 logit을 계산한 후 soft voting방식으로 레이블을 예측한다. # 결과 ### BERT기반 모델 3개를 앙상블한 결과 .png) BERT기반 모델 3개를 앙상블한결과를 SWA-1,2,3에 따라 나눈 결과이다. 총 에폭수가 5였으므로 3은 너무많고, 1은 너무적어서 SWA는 2가 최적이었던것 같다. 다만 지금까지 모델에 여러가지 튜닝을 해왔음에도 test/acc성능이 나오지 않는것은, 이유를 생각해봐야겠다.   추정컨데, 모델에 적용한, 앙상블, 하이퍼파라미터 튜닝을 통한 정규화, Focal Loss는 일반적으로 모델의 성능을 Rubust하게 만들어준다. 하지만 test/acc만이 평가 metric인 이상, 결국에 test/acc성능이 좋아야한다. 지금까지의 코드는 과적합을 막기위해 bestmodel선정을 valid/loss가 최소화된 모델을 선택했다. 그런데, 결국에는 acc성능이 평가 metric이기 때문에, acc를 기준으로 체크포인트를 선택해서 SWA를 해야하는게 아닌가 생각이 든다. 물론 valid/loss가 폭발하지 않는 선에서, 즉 과적합 되지 않는 선에서 정리를 해야한다. 그리고 Focal Loss의 $\alpha$가중치가 소수클래스에 대해 너무 큰 가중치를 주는게 아닌가 생각이 든다. test 데이터의 분포는 알 수 없지만, 일반적으로 80% acc를 갖는 모델의 예측분포는 전체 데이터셋의 분포와 유사한 분포를 띠고있다. 따라서 stratify된 분포를 갖지 않을까 추측해본다. 만약 전체 데이터셋의 분포와 같다면 강한 부정, 약한 긍정(다수클래스)은 훨씬 덜 선택하고 있는거고, 강한긍정, 약한부정(소수클래스) 는 오히려 정답레이블보다 많이 선택하고 있음을 확인할 수 있다. 따라서 Focal Loss의 가중치를 아예 1로 두고 실험을 해보고, test데이터셋의 분포를 더 추론해보고 acc의 성능을 파악해봐야겠다. # 이후 실험에서 다뤄야 할것들 - base모델 바꿔서 하이퍼파라미터 튜닝 - SWA 구현해서 SWA횟수를 하이퍼파라미터로 넣기 - 데이터증강 실험해보고 효과 있으면 이것도 하이퍼파라미터로 넣기 - TAPT적용 - Boosting-adaboost staking구현 → 기존 코드에 implementation - acc만이 평가지표로 활용된다. acc를 올릴 수 있는방법.. → 너무 많은 정규화를 하면 안되는걸까? ### [영화리뷰 감성분류][모델최적화]-커스텀토크나이저 - Canonical URL: https://hyejunl33.github.io/projects/2025-10-25-[Domain_Common_Project]Custom_Tokenizer/ - Collection: Project - Published: 2025-10-26 - Tags: Domain_Common_Project, study, CustomTokenizer, Experiments # Introduction 이전모델에서는 커스텀토크나이저를 사용해서 특수토큰을 사용해봤고, Weighted Cross Entropy를 구현했고, Stratified K-Fold Cross Validation를 구현했는데 Accuracy가 0.79근방이 나왔다. 대체 뭐가 성능하락을 야기했을까? 나머지 요인들은 통제변인으로 설정하고 하나씩 실험해보며, 성능향상에 기여하는것들을 찾아나가야겠다. 그 첫 여정이 커스텀토크나이저다. 직관적으로 커스텀 토크나이저를 사용하면 OOV문제를 더 많이 해결할 수 있고 [UNK]토큰이 줄어들것이므로 모델은 더 문맥을 잘 이해할 것이다. 다만 어떻게 토큰을 설정하고 추가해주고, 매핑해줄것인지는 전적으로 개발자인 나에게 달려있기 때문에 데이터셋의 특징과 분포를 잘 파악하고 커스텀 토크나이저를 실험해보며 처리해봐야겠다. 그 다음은 불용어 처리이다. 이전 모델에서 데이터셋을 확인해본 결과 ‘진짜’,’정말’같은 강조를 하는 단어들은 레이블과 상관없이 모든레이블에서 자주 등장하는 단어였다. 따라서 이러한 단어들을 베이스라인코드에서는 불용어처리가 되어있었는데, 불용어처리를 해제하는게 나은지, 혹은 불용어처리를 하는게 나은지 실험을 해볼 예정이다.  BaseLine코드대로 모델을 돌리면 ACC는 0.8이 나온다. 이는 커스텀 토크나이저도 사용하지 않았고, 불용어처리도 최대한 많은 단어들을 처리한 결과이다. 이번 실험을 통해 이를 뛰어넘을 수 있을지, 혹은 성능을 올릴 수 있는 방안은 무엇인지 찾는게 목표이다. # 불용어처리 - 통제변인: 불용어리스트를 제외한 나머지 (하이퍼파라미터, 모델 등등) - 조작변인: 불용어리스트(불용어리스트를 전부 주석처리했음.)  우선 EDA결과 문제가 있는 데이터의 비율은 1.63%로 전체 데이터에 비하면 적은양임을 알 수 있다. 따라서 모델학습의 안정성을 위해 문제가 있는 데이터들은 최대한 노이즈처리하고 제거를 하고 시작을 한다. ```python # 한국어 불용어 리스트 확장 stopwords = [ "은", "는", "이", "가", "을", "를", "의", "에", "와", "과", "도", "로", "으로", "에서", "한", "그", "것", "그것", "이것", "저것", "그리고", "그런데", "하지만", "그러나", "있다", "없다", "되다", "하다", "이다", "아니다", "같다", "많다", "좋다", "나쁘다", "수", "때", "곳", "사람", "것들", "정말", "너무", "매우", "아주", "참", "좀", ] ``` BaseLinecode에서는 상당수의 단어들을 불용어처리하고 시작한다. 하지만 BERT기반 모델들은 트렌스포머 기반모델이므로 문맥 자체를 학습한다. 따라서 조사나 어미등을 포함해 자연스러운 문장구조를 유지하는게 성능향상에 도움이 된다고 한다. 그리고 어차피 Self-Attention단계에서 조사나 어미는 낮은 Attention Score를 받게되므로 모델이 스스로 무시할 수 있다. 따라서 이번실험에서는 BERT기반 모델을 사용하므로 **불용어리스트를 아예 제거한다.** ```python # 클래스별 공통 키워드 분석 print("\n클래스별 상위 빈출 단어 (불용어 포함):") # 한국어 불용어 리스트 확장 stopwords = [ # "은", # "는", # "이", # "가", # "을", # "를", # "의", # "에", # "와", # "과", # "도", # "로", # "으로", # "에서", # "한", # "그", # "것", # "그것", # "이것", # "저것", # "그리고", # "그런데", # "하지만", # "그러나", # "있다", # "없다", # "되다", # "하다", # "이다", # "아니다", # "같다", # "많다", # "좋다", # "나쁘다", # "수", # "때", # "곳", # "사람", # "것들", # "정말", # "너무", # "매우", # "아주", # "참", # "좀", ] for class_name in sorted(df["label"].unique()): class_data = df[df["label"] == class_name] all_text = " ".join(class_data["review"].astype(str)) # 단어 추출 및 필터링 (길이 2 이상, 불용어 제외) words = [ word for word in all_text.split() if word not in stopwords and len(word) >= 2 and word.isalpha() ] # 단어 빈도 계산 word_counts = Counter(words) top_words = word_counts.most_common(10) # 상위 10개로 지정 print( f"\n{class_name} ({LABEL_MAPPING[class_name]}) - 총 {len(class_data)}개 샘플:" ) for i, (word, count) in enumerate(top_words, 1): percentage = (count / len(words)) * 100 if len(words) > 0 else 0 print(f" {i:2d}. '{word}': {count}회 ({percentage:.1f}%)") ``` ```python 0 (강한 부정) - 총 114066개 샘플: 1. '너무': 106022회 (3.2%) 2. '진짜': 82753회 (2.5%) 3. '보는': 55270회 (1.7%) 4. '정말': 52786회 (1.6%) 5. '이런': 52545회 (1.6%) 6. '영화': 49829회 (1.5%) 7. '영화는': 44978회 (1.4%) 8. '보고': 44776회 (1.4%) 9. '영화를': 40348회 (1.2%) 10. '내내': 39208회 (1.2%) 1 (약한 부정) - 총 27216개 샘플: 1. '너무': 16454회 (2.2%) 2. '보고': 10499회 (1.4%) 3. 'ㅠㅠ': 8538회 (1.1%) 4. '뭔가': 7251회 (1.0%) 5. '영화': 7061회 (0.9%) 6. '보는': 6857회 (0.9%) 7. '진짜': 6833회 (0.9%) 8. '정말': 6658회 (0.9%) 9. '그냥': 6467회 (0.9%) 10. '영화는': 6200회 (0.8%) 2 (약한 긍정) - 총 99416개 샘플: 1. '진짜': 60021회 (2.3%) 2. '정말': 56003회 (2.1%) 3. '너무': 45092회 (1.7%) 4. '영화': 34369회 (1.3%) 5. '보는': 29527회 (1.1%) 6. '특히': 28620회 (1.1%) 7. '영화는': 26255회 (1.0%) 8. '내내': 22921회 (0.9%) 9. '영화를': 20993회 (0.8%) 10. '보고': 19278회 (0.7%) 3 (강한 긍정) - 총 38952개 샘플: 1. '진짜': 46041회 (4.4%) 2. '정말': 24398회 (2.3%) 3. '너무': 22577회 (2.2%) 4. '영화': 17807회 (1.7%) 5. '영화는': 15968회 (1.5%) 6. '보는': 12402회 (1.2%) 7. '특히': 11121회 (1.1%) 8. '내내': 10439회 (1.0%) 9. '보고': 9783회 (0.9%) 10. '영화를': 9369회 (0.9%) ``` 불용어리스트를 아예 주석처리한 후 클래스별 상위 빈출단어를 보면 0,1,2,3 모든 레이블의 5등안에 ‘너무’,’진짜’,’정말’이라는 단어가 포함됨을 알 수 있다. 그렇다면 모든 레이블에 이러한 단어들이 자주 등장하니깐, 모델은 오히려 ‘너무’같은 단어가 등장하면 레이블을 헷갈려 하진 않을까? BERT기반 모델은 BIdirectional 학습을 통해 forward방향, backward방향 두방향 모두 학습한다. 그리고 Attention을 통해 다른 단어들과 병렬적으로 연관성을 학습한다. 따라서 ‘너무’라는 단어만 보고 모델은 헷갈려 하지 않고, ‘너무’ + ‘좋다’ 혹은 ‘너무’+’별로다’처럼 맥락을 학습하고, 맥락에 따라 레이블을 prediction할 수 있게 된다. 따라서 불용어처리를 오히려 하지 않는게 모델성능향상에 도움이 되겠다고 생각했다.  불용어를 처리하지 않은 모델은 BaseLine Code모델에 비해 0.0005 acc가 하락했다. 사실상 오차범위안이라서, 불용어를 처리하는지 안하는지는 모델에 큰 의미가 없는것 같다. # 커스텀토크나이저 - 통제변인: 토크나이저와 텍스트 전처리를 제외한 나머지 요인(하이퍼파라미터, 모델등) - 조작변인:토크나이저 커스텀(특수토큰 추가), 텍스트 전처리 과정 변경, 토크나이저 `max_length=256`으로 변경  기존의 전처리 과정에서는 “ㅋㅋㅋㅋㅋ”같이 자음이 하나만 반복되는것들을 정규식을 이용해서 모두 제거해버렸다. 그래서 ‘ㅋㅋㅋㅋ’가 전처리를 거친 후 사라진것을 볼 수 있고 ‘ㄷㄷㄷ’도 마찬가지이다. 이러한 한글로 감정을 나타내는 문자들은 없애면 안되고, 정규화를 해서, 특수토큰으로 치환해야한다. ### 텍스트 전처리 ```python # 기본 텍스트 정리 함수 def clean_text(text): """ 한국어 텍스트를 위한 기본 텍스트 정리 함수 전처리 단계: 1. 불완전한 한글 제거 (자음/모음만 있는 경우) 2. 반복되는 감정 표현 정규화 (ㅋㅋㅋ, ㅠㅠㅠ 등) 3. 과도한 문자 반복 축소 (4번 이상 → 3번으로) 4. 특수문자 제거 (한글, 숫자, 기본 구두점, 감정표현 제외) 5. 공백 정규화 """ if pd.isna(text): return "" text = str(text).strip() # 한국어 특화 전처리 # 1. 감정 표현 정규화 (먼저 수행) text = re.sub(r"([ㅋㅎ])\1{2,}", r"\1\1", text) # ㅋㅋㅋ+ → ㅋㅋ text = re.sub(r"([ㅠㅜㅡ])\1{2,}", r"\1\1", text) # ㅠㅠㅠ+ → ㅠㅠ # 2. 과도한 문자 반복 축소 (4번 이상 → 3번으로) text = re.sub(r"(.)\1{3,}", r"\1\1\1", text) # 3. 불완전한 한글 제거 (ㅋ,ㅎ,ㅠ,ㅜ,ㅡ는 확실히 제외하고 제거) # 제거할 자음/모음 목록 명시적 정의 (ㅋ,ㅎ,ㅠ,ㅜ,ㅡ 제외) unwanted_korean = r"[ㄱㄲㄴㄷㄸㄹㅁㅂㅃㅅㅆㅇㅈㅉㅊㅌㅍ]|[ㅏㅐㅑㅒㅓㅔㅕㅖㅗㅘㅙㅚㅛㅣㅢㅟㅣ]" # <-- 수정된 부분! text = re.sub(unwanted_korean, "", text, flags=re.IGNORECASE) # 4. 불필요한 특수문자 제거 (Blacklist 방식, 이모지 유지) # 제거 대상: _normalize_text에서 처리되지 않는 일부 기호들. 필요에 따라 추가/삭제 가능 # (예: 괄호 (), 꺽쇠 <>, 콜론 :, 작은따옴표 ', 큰따옴표 ", ` 등) # \w(알파벳,숫자,_), \s(공백), 가-힣(한글), .,!;?~-(기본구두점), ㅋㅎㅠㅜㅡ(감정표현) 및 이모지는 유지됨. noise_chars = r"[#*•■◆◇□○●※+=/\\%&{}$₩€£¥|`→←↑↓▶◀△▽“”‘’『』「」^±§ⓒ®™]" # <-- 확장된 노이즈 리스트 text = re.sub(noise_chars, " ", text) text = re.sub(r"\s+", " ", text) # 다중 공백을 단일 공백으로 return text.strip() print("텍스트 전처리 과정 시작") print("=" * 50) initial_size = len(df_processed) print(f"초기 데이터 크기: {initial_size:,}개") # 1단계: 텍스트 정리 적용 print("\n1단계: 기본 텍스트 정리 수행 중...") df_processed["review_cleaned"] = df_processed["review"].apply(clean_text) print("✓ 한글 자음/모음 정리, 반복 표현 정규화, 특수문자 제거 완료") # 2단계: 빈 텍스트 제거 print("\n2단계: 빈 텍스트 제거 중...") empty_count = df_processed["review_cleaned"].str.strip().eq("").sum() if empty_count > 0: df_processed = df_processed[df_processed["review_cleaned"].str.strip() != ""] print(f"✓ 빈 텍스트 {empty_count}개 제거") else: print("✓ 빈 텍스트 없음") # 3단계: 중복 제거 print("\n3단계: 중복 데이터 제거 중...") duplicates_count = df_processed.duplicated(subset=["review_cleaned", "label"]).sum() if duplicates_count > 0: df_processed = df_processed.drop_duplicates(subset=["review_cleaned", "label"]) print(f"✓ 중복 데이터 {duplicates_count}개 제거") else: print("✓ 중복 데이터 없음") # 최종 결과 요약 final_size = len(df_processed) removed = initial_size - final_size print("\n" + "=" * 50) print("전처리 결과 요약:") print(f"최종 데이터 크기: {initial_size:,} → {final_size:,}") print(f"제거된 데이터: {removed:,}개 ({removed / initial_size * 100:.1f}%)") print("=" * 50) ``` 텍스트 전처리 과정에서 자음반복등의 감정표현을 먼저 정규화를 한 후, 불완전한 한글을 제거할때 ㅋ,ㅎ,ㅠ,ㅜ,ㅡ는 제외하고 제거해준다. 따라서 감정을 나타내는 한글 자음 및 모음을 정규화시켜서 전처리를 거치더라도 남아있도록 만들 수 있다. 특수문자는 BlackList방식으로 이모지를 유지시켜준다. 해당 리스트에 있는 문자들이 데이터셋에 있을경우 없애주고, 나머지 감정을 나타낼만한 이모지나 특수문자는 유지시켜주었다. ### 텍스트 정규화 ```python print("텍스트 정규화 과정 시작") print("=" * 50) # 대소문자 정규화 (BERT가 처리하지만 일관성을 위해) print("\n1단계: 대소문자 정규화 수행 중...") df_processed["review_normalized"] = df_processed["review_cleaned"].str.lower() print("✓ 소문자 변환 완료") # 구두점 정규화 print("\n2단계: 구두점 정규화 수행 중...") def normalize_punctuation(text): # 여러 개의 구두점을 하나로 정규화 text = re.sub(r"[.]{2,}", ".", text) text = re.sub(r"[!]{2,}", "!", text) text = re.sub(r"[?]{2,}", "?", text) text = re.sub(r"[,]{2,}", ",", text) # 구두점 주변 공백 정리 text = re.sub(r"\s+([.,!?])", r"\1", text) text = re.sub(r"([.,!?])\s+", r"\1 ", text) return text df_processed["review_normalized"] = df_processed["review_normalized"].apply( normalize_punctuation ) print("✓ 구두점 정규화 완료") # 특수문자 추가 정리 print("\n3단계: 특수문자 정리 수행 중...") def clean_special_chars(text): # URL 패턴 제거 (있는 경우) text = re.sub( r"http[s]?://(?:[a-zA-Z]|[0-9]|[$-_@.&+]|[!*\\(\\),]|(?:%[0-9a-fA-F][0-9a-fA-F]))+", "", text, ) # 이메일 패턴 제거 (있는 경우) text = re.sub(r"\S+@\S+", "", text) # 멘션 패턴 제거 (있는 경우) text = re.sub(r"@\w+", "", text) # 과도한 공백 정리 text = re.sub(r"\s+", " ", text) return text.strip() df_processed["review_normalized"] = df_processed["review_normalized"].apply( clean_special_chars ) print("✓ URL/이메일/멘션 제거 완료") # 정규화 후 빈 텍스트 처리 print("\n4단계: 정규화 후 빈 텍스트 확인 중...") empty_after_normalization = df_processed["review_normalized"].str.strip().eq("").sum() if empty_after_normalization > 0: df_processed = df_processed[df_processed["review_normalized"].str.strip() != ""] print(f"✓ 빈 텍스트 {empty_after_normalization}개 제거") else: print("✓ 빈 텍스트 없음") # 정규화 전후 비교 print("\n" + "=" * 50) print("정규화 결과 요약:") print(f"최종 데이터 크기: {len(df_processed):,}개") print(f"평균 길이 - 정리됨: {df_processed['review_cleaned'].str.len().mean():.1f}자") print( f"평균 길이 - 정규화됨: {df_processed['review_normalized'].str.len().mean():.1f}자" ) print("=" * 50) ``` 정규화 과정에서는 이전 전처리과정에서 특수문자를 처리해주었으므로, 단순하게 원래 베이스라인 코드에 있었던것처럼 URL, 이메일, 멘션패턴을 제거하고, 공백정리를 하는식으로만 진행한다. ```python --- 수집된 라벨별 상위 감성 패턴 (예시) --- [Label 0]: [('ㅠㅠ', 27105), ('ㅋㅋ', 5958), ('ㅡㅡ', 1899), ('ㅎㅎ', 774), ('ㅜㅜ', 427), ('😡', 38), ('★', 31), ('ㅋㅋㅠㅠ', 26), ('ㅜㅠ', 21), ('ㅡㅡㅋ', 20)] [Label 1]: [('ㅠㅠ', 7606), ('ㅎㅎ', 1885), ('ㅋㅋ', 1464), ('ㅜㅜ', 72), ('ㅡㅡ', 67), ('★', 22), ('😊', 17), ('🌟', 11), ('♥', 11), ('ㅠㅜ', 9)] [Label 2]: [('ㅎㅎ', 15789), ('ㅋㅋ', 7532), ('ㅠㅠ', 4526), ('♥', 676), ('🌟', 527), ('✨', 411), ('ㅜㅜ', 398), ('😊', 337), ('👍', 291), ('♡', 288)] [Label 3]: [('ㅎㅎ', 4532), ('ㅠㅠ', 3967), ('ㅋㅋ', 3150), ('♥', 1621), ('♡', 448), ('ㅜㅜ', 327), ('🌟', 269), ('★', 170), ('✨', 123), ('👍', 111)] ------------------------------------------ ``` 사전 EDA를 해본 결과 정규화된 몇몇 모음 및 자음, 그리고 몇몇 이모지는 자주 등장함을 알 수 있다. 이들을 특수토큰으로 mapping해서 처리해줄 예정이다  전처리 및 정규화를 마친 데이터를 보면 감정을 나타내는 ‘ㅡㅡ’ 및 ‘ㅋㅋ’등은 데이터로 남아있고, ㅋ나 ㅎ가 여러개인경우 ‘ㅋㅋ’나 ‘ㅎㅎ’로 정규화 된것을 알 수 있었다. ## 커스텀 토큰 추가 ```python # --- 1단계: 수정된 특수 토큰 및 치환 규칙 정의 --- NEW_SPECIAL_TOKENS = [ "[LAUGH]", # ㅋㅋ, ㅎㅎ "[CRY]", # ㅠㅠ, ㅜㅜ, ㅜㅠ, ㅠㅜ "[SMILE]", # ^^, :), 😊 등 "[HEART]", # ♥, ♡ "[DISPLEASED]", # ㅡㅡ, ㅡㅡㅋ, 😡 "[THUMBS_UP]", # 👍 "[SPARKLE]", # 🌟, ✨ "[STAR]", # ★ ] # 치환 매핑 (정규식) - 적용 순서를 고려하여 리스트로 변경하는 것을 추천 # 예시: 리스트 형태 [(regex_pattern, token_string), ...] EMOTION_REPLACEMENTS = [ # 1. 불쾌 (ㅡㅡㅋ 처리를 위해 먼저) (re.compile(r'(ㅡ{2,})|(ㅡㅡㅋ)|(😡)'), "[DISPLEASED]"), # 2. 울음 (ㅡ 관련 제거됨) (re.compile(r'([ㅠㅜ]){2,}|(ㅜㅠ)|(ㅠㅜ)'), "[CRY]"), # 3. 웃음 (re.compile(r'([ㅋㅎ]){2,}'), "[LAUGH]"), # 4. 미소 (re.compile(r'(\^{2,})|(\:\))|(\:D)|(\^_+\^)|(\:\s?\))|(😊)'), "[SMILE]"), # 5. 하트 (re.compile(r'[♥♡]'), "[HEART]"), # 6. 따봉 (re.compile(r'[👍]'), "[THUMBS_UP]"), # 7. 반짝임 (re.compile(r'[🌟✨]'), "[SPARKLE]"), # 8. 별 (re.compile(r'[★]'), "[STAR]"), ] # --- 2단계: 텍스트에 치환 적용하는 함수 --- def replace_emotions(text, replacements): """Applies regex replacements to map patterns to special tokens.""" if pd.isna(text): return "" processed_text = str(text) # Ensure it's a string for pattern, token in replacements: # Add spaces around the token to ensure separation processed_text = pattern.sub(f" {token} ", processed_text) # Clean up multiple spaces that might result from replacements processed_text = re.sub(r'\s+', ' ', processed_text).strip() return processed_text #Special Tokens넣고 토크나이저 사이즈 늘리기 print(f"Original tokenizer vocab size: {len(tokenizer)}") num_added_toks = tokenizer.add_tokens(NEW_SPECIAL_TOKENS) print(f"Added {num_added_toks} new special tokens.") print(f"New tokenizer vocab size: {len(tokenizer)}") # BERT모델 토큰 늘리기 # !!! IMPORTANT: Resize model embeddings to match the new tokenizer size !!! model.resize_token_embeddings(len(tokenizer)) print("Resized model token embeddings.") # BERT 전용 전처리 함수들 def bert_tokenize_and_encode(texts, labels=None, max_length=256): """ BERT를 위한 텍스트 토큰화 및 인코딩 - 토큰화 및 길이 제한 처리 - 특수 토큰 추가 ([CLS], [SEP]) - 어텐션 마스크 생성 - 절단 및 패딩 전략 처리 """ input_ids = [] attention_masks = [] token_type_ids = [] # texts가 list 형태인지 확인 (DataFrame Series 등이 올 수 있으므로) if isinstance(texts, pd.Series): texts_list = texts.tolist() elif not isinstance(texts, list): texts_list = list(texts) else: texts_list = texts # labels도 list 형태로 변환 (필요한 경우) if labels is not None: if isinstance(labels, pd.Series): labels_list = labels.tolist() elif not isinstance(labels, list): labels_list = list(labels) else: labels_list = labels # 길이 검증 if len(texts_list) != len(labels_list): raise ValueError("texts와 labels의 길이가 다릅니다.") else: labels_list = None for text in texts: # 토큰화 및 인코딩 (특수 토큰 자동 추가) #위에서 정의했든 replcae_emotions 함수 사용 replaced_text = replace_emotions(text, EMOTION_REPLACEMENTS) encoded = tokenizer.encode_plus( replaced_text, add_special_tokens=True, # [CLS], [SEP] 토큰 추가 max_length=max_length, # 최대 길이 제한 padding="max_length", # 최대 길이까지 패딩 truncation=True, # 길이 초과시 절단 return_attention_mask=True, # 어텐션 마스크 생성 return_token_type_ids=True, # 토큰 타입 ID 생성 return_tensors="pt", # PyTorch 텐서로 반환 ) input_ids.append(encoded["input_ids"].flatten()) attention_masks.append(encoded["attention_mask"].flatten()) token_type_ids.append(encoded["token_type_ids"].flatten()) # 텐서로 변환 input_ids = torch.stack(input_ids) attention_masks = torch.stack(attention_masks) token_type_ids = torch.stack(token_type_ids) result = { "input_ids": input_ids, "attention_mask": attention_masks, "token_type_ids": token_type_ids, } if labels is not None: result["labels"] = torch.tensor(labels, dtype=torch.long) return result # 토큰 길이 분포 확인 def analyze_token_lengths(texts, max_length=256): """토큰 길이 분포 분석""" token_lengths = [] for text in texts: tokens = tokenizer.tokenize(text) token_lengths.append(len(tokens)) token_lengths = np.array(token_lengths) print( f"토큰 길이: 평균 {token_lengths.mean():.1f}, 중앙값 {np.median(token_lengths):.1f}, 범위 {token_lengths.min()}-{token_lengths.max()}" ) print( f"{max_length} 토큰 초과: {(token_lengths > max_length).sum()}개 ({(token_lengths > max_length).mean() * 100:.1f}%)" ) return token_lengths # 토큰화 테스트 및 분석 sample_text = df_processed["review_normalized"].iloc[0] sample_tokens = tokenizer.tokenize(sample_text) print(f"\n토큰화 테스트: '{sample_text[:50]}...' -> {len(sample_tokens)}개 토큰") # 전체 데이터셋 토큰 길이 분포 분석 print("\n전체 데이터셋 토큰 길이 분포:") token_lengths = analyze_token_lengths(df_processed["review_normalized"].tolist()) ``` 사전 EDA결과 웃음패턴, 울음패턴이 모든 레이블에서 가장 많이 나타나는것을 알 수 있었다. 따라서 `[Laugh], [CRY]`토큰을 만들어 주었다. 그 외에도, 데이터셋에서 자주 나타나는 이모지인 별, 따봉, 화난이모지등을 특수토큰으로 만들어주었다. EMOTION_REPLACEMENTS에서 특수토큰으로 매핑을 해주었고 이후 BERT전처리 함수에서 `replace_emotions()` 함수에서 정의된 내용을 바탕으로 특수토큰패턴이 있다면 텍스트에 치환적용을 한다.  256을 넘는 토큰이 0.5%밖에 없으므로 토크나이저의 max_length를 256으로 지정해주었다. 기존의 BaseLinecode에서는 128이었으므로 더 많은 정보를 파악할 수 있도록 해주었다. 이로써 성능향상을 기대해볼 수 있을것 같다. # 결과  테스트를 해본 결과 Training Loss는 줄어드는 경향성을 보이지만 Validation Loss는 처음에는 줄어들다가 올라가는 경향성을 보였다. 과적합되고있다는 신호로, 이후 실험들에서는 Regularization기법들을 추가하도록 고려해봐야겠다.  모든 통제변인을 제거하고 커스텀 토크나이저를 이용한 결과 약 1퍼센트의 성능향상이 있었다. 따라서 커스텀 토큰추가를 통해 유의미한 성능향상을 관측했다. 이제 이후 실험에서는 이 커스텀토크나이저 모델을 기반으로 이후에는 Focal Loss적용, Regularization기법들을 추가해볼 예정이다. ### [영화리뷰 감성분류][모델최적화]-FocalLoss - Canonical URL: https://hyejunl33.github.io/projects/2025-10-26-[Domain_Common_Project]FocalLoss/ - Collection: Project - Published: 2025-10-26 - Tags: Domain_Common_Project, study, Feature_Engineering, Focal_Loss # Introduction  이전에 Weighted Cross Entropy를 적용한 모델은 이상할정도로 과적합되어 Training Loss는 하락하는 추세를 보이지만, Validation Loss는 줄어들지 않는 문제가 있었다. Weighted CrossEntropy는 소수의 클래스에 더 높은 가중치를 부여하므로, 소수클래스 샘플의 특징에 모델이 지나치게 맞춰질 수 있다. 우선 과적합을 방지하기 위해서 시도해봐야 하는 방법들을 생각해 보았다. - Early Stopping: 가장 쉽고 빠르게 시도해볼 수 있는 방법으로 Validation Loss가 감소하지 않으면 훈련을 중단하는 방법이다. - Regularization 강화 - Weight Decay: WeightDecay값을 높여서 모델 가중치가 너무 커지는것을 방지한다. - Dropout: Dropout비율을 높여서 과적합을 방지한다. - Dropout은 일반적으로 라이브러리 모델의 기본값을 사용한다. - Label Smoothing: 정답 레이블을 원핫 인코딩이 아니라 [0.9,0.03,0.03,0.03]처럼 모델이 너무 확신하는것을 방지하도록 만든다. - Focal Loss사용: FocalLoss는 Weighted Cross Entropy와는 다르게 예측난이도에 집중하므로 단순 클래스 빈도만 고려하는 WCE보다 과적합에 덜 민감하다. - Learning Rate Scheduling: 러닝레이트 스케줄러를 조정하는 방법을 사용할 수 있다. 베이스모델은 이전실험들에서 가장 좋은 성능을 보였던 Custom_Tokenizer모델을 사용한다.  # Focal Loss Implementaion ```python # 필요 라이브러리 임포트 import torch import torch.nn as nn import torch.nn.functional as F import numpy as np # alpha가 list/ndarray일 경우를 위해 추가 class FocalLossSoftLabels(nn.Module): """ 다중 클래스 분류를 위한 Focal Loss 구현 (소프트 레이블 지원). Label smoothing이 적용된 경우에도 작동하도록 설계되었습니다. Args: alpha (float or list/tensor): 각 클래스에 대한 가중치 요소. 리스트/텐서 형태 권장 (길이=num_classes). float일 경우 모든 클래스에 동일 적용. 기본값 0.25. gamma (float): 초점 파라미터. 기본값 2.0. reduction (str): 감소 방식 ('none' | 'mean' | 'sum'). 기본값 'mean'. epsilon (float): 수치 안정성을 위한 작은 값. 기본값 1e-7. """ def __init__(self, alpha=0.25, gamma=2.0, reduction='mean', epsilon=1e-7): super(FocalLossSoftLabels, self).__init__() self.alpha = alpha self.gamma = gamma self.reduction = reduction self.epsilon = epsilon # log(0) 방지 def forward(self, inputs, targets): """ Focal Loss 계산 (소프트 레이블 지원). Args: inputs (torch.Tensor): 모델 로짓 (N, C). targets (torch.Tensor): 실제 레이블 (N) 또는 소프트 레이블 (N, C). Returns: torch.Tensor: 계산된 Focal Loss. """ num_classes = inputs.shape[1] # 1. 입력 로짓에 log_softmax 적용 log_probs = F.log_softmax(inputs, dim=-1) # 예측 확률 계산 probs = F.softmax(inputs, dim=-1) # 2. targets 형태 확인 및 변환 if targets.ndim == 1: # 하드 레이블인 경우 (Label smoothing 미적용 시) # 원-핫 인코딩으로 변환 (Cross Entropy 계산 위해) targets_one_hot = F.one_hot(targets, num_classes=num_classes).float().to(inputs.device) # pt 계산을 위한 정수 인덱스 target_indices = targets elif targets.ndim == 2 and targets.shape[1] == num_classes: # 소프트 레이블인 경우 targets_one_hot = targets.float().to(inputs.device) # pt 계산 및 alpha 적용을 위해 가장 확률 높은 클래스 인덱스 사용 target_indices = targets_one_hot.argmax(dim=1) else: raise ValueError("targets 텐서의 형태가 올바르지 않습니다. (N) 또는 (N, C)여야 합니다.") # 3. 기본 Cross Entropy 손실 계산 (소프트/하드 레이블 모두 처리) # ce_loss = - (targets_one_hot * log_probs).sum(dim=-1) # 수동 계산 # 또는 PyTorch 함수 사용 (내부적으로 소프트 레이블 처리) # 참고: F.cross_entropy는 log_softmax + NLLLoss 이므로, log_probs를 직접 사용 시 NLLLoss 사용 ce_loss_per_sample = F.cross_entropy(inputs, targets_one_hot, reduction='none') # 4. pt 계산 (예측 확률 중 '정답' 클래스에 해당하는 값) # target_indices를 사용하여 해당 클래스의 예측 확률(probs)을 가져옴 pt = probs.gather(1, target_indices.unsqueeze(-1)).squeeze(-1) # 수치 안정성 보장 (pt가 0이나 1에 매우 가까워지는 것 방지) pt = pt.clamp(min=self.epsilon, max=1.0 - self.epsilon) # 5. alpha 가중치 계산 (alpha_t) alpha_t = None if isinstance(self.alpha, (float, int)): # 단일 float alpha -> 모든 클래스에 동일하게 적용하거나 특정 로직 추가 가능 # 여기서는 우선 모든 샘플에 동일 alpha 적용 (리스트 형태 권장) # alpha_t = torch.full_like(ce_loss_per_sample, self.alpha) # 단순 적용 예시 # 클래스별로 다른 alpha를 적용하고 싶다면 아래 리스트/텐서 방식 사용 alpha_tensor = torch.full((num_classes,), self.alpha).to(inputs.device) alpha_t = alpha_tensor.gather(0, target_indices) elif isinstance(self.alpha, (list, np.ndarray, torch.Tensor)): # 리스트, ndarray, 텐서 형태 alpha 처리 if not isinstance(self.alpha, torch.Tensor): alpha_tensor = torch.tensor(self.alpha).to(inputs.device) else: alpha_tensor = self.alpha.to(inputs.device) if alpha_tensor.shape[0] != num_classes: raise ValueError(f"alpha의 길이({alpha_tensor.shape[0]})가 클래스 개수({num_classes})와 일치해야 합니다.") # target_indices를 사용하여 각 샘플의 alpha 값 선택 alpha_t = alpha_tensor.gather(0, target_indices) else: # alpha 가중치 없음 alpha_t = 1.0 # 6. Focal Loss 계산 focal_loss_component = alpha_t * (1 - pt)**self.gamma * ce_loss_per_sample # 7. reduction 적용 if self.reduction == 'mean': return focal_loss_component.mean() elif self.reduction == 'sum': return focal_loss_component.sum() else: # 'none' return focal_loss_component ``` ```python from transformers import Trainer class CustomTrainerWithFocalLoss(Trainer): """ Focal Loss (소프트 레이블 지원)를 사용하도록 손실 계산을 오버라이드한 커스텀 Trainer. """ def __init__(self, *args, focal_loss_alpha=0.25, focal_loss_gamma=2.0, num_classes=4, **kwargs): super().__init__(*args, **kwargs) self.num_classes = num_classes # 클래스 개수 저장 # alpha 처리: float이면 num_classes 길이의 리스트로 변환 effective_alpha = focal_loss_alpha if isinstance(focal_loss_alpha, (float, int)): effective_alpha = [focal_loss_alpha] * self.num_classes print(f"Focal Loss: 단일 alpha 값({focal_loss_alpha})을 모든 {self.num_classes}개 클래스에 적용합니다.") elif isinstance(focal_loss_alpha, list) and len(focal_loss_alpha) != self.num_classes: raise ValueError(f"focal_loss_alpha 리스트의 길이({len(focal_loss_alpha)})가 num_classes({self.num_classes})와 일치해야 합니다.") else: print(f"Focal Loss: 클래스별 alpha 값({effective_alpha})을 사용합니다.") # 최적화된 FocalLossSoftLabels 사용 self.focal_loss_func = FocalLossSoftLabels(alpha=effective_alpha, gamma=focal_loss_gamma) def compute_loss(self, model, inputs, return_outputs=False, **kwargs): """ Trainer가 손실을 계산하는 방식 오버라이드. Label Smoothing이 적용된 경우 targets는 (N, C) 형태의 소프트 레이블이 됩니다. """ # labels 키가 있는지 확인 (Trainer 내부적으로 label smoothing 적용 후 전달) if "labels" not in inputs: raise ValueError("모델 입력에 'labels' 키가 없습니다. 데이터셋 형식을 확인하세요.") labels = inputs.pop("labels") outputs = model(**inputs) logits = outputs.get('logits') # FocalLossSoftLabels 함수 호출 (소프트/하드 레이블 모두 처리 가능) loss = self.focal_loss_func(logits, labels) return (loss, outputs) if return_outputs else loss ``` `FocalLossSoftLabels` 클래스안에서 FocalLoss를 정의한다.  Focal Loss는 모델이 이미 쉽게 맞히는 샘플보다는, 계속 틀리는 어려운 샘플에 더 집중하도록 Lossfunction 자체를 조정한다. 즉 클래스별로 맞히기 어려운 샘플일수록 Loss 비중을 높인다. $$\gamma$$에 따라 Loss Function의 형태 자체가 달라짐을 볼 수 있다. $$\gamma$$가 0에 가까울수록 예측확률이 낮을때, 즉 확신이 없을때의 Loss가 매우 커서, 학습이 더 강하게 일어남을 확인할 수 있다. 이때 ground Truth Class의 확률이 적을수록, 즉 해당 레이블에 모델이 확신이 없을수록 Loss값이 커지는것을 알 수 있다. 따라서 모델이 확신을 갖지 못하는 각 step의 판단에서, Loss가 더 커지도록 한다. 그리고 $$\alpha$$는 Weighted Cross Entropy와 같이 불균형 클래스에서 클래스간의 가중치를 설정하는 하이퍼 파라미터이다. 우선은 WCE에서처럼 각 클래스 백분율의 역수를 가중치로 줬는데 $\alpha,\beta$는 추후 하이퍼파라미터 튜닝 툴로 튜닝을 해봐야겠다. ## 훈련 및 정규화 ```python from transformers import EarlyStoppingCallback # <--- 이 줄 추가 # 모델 저장 여부 및 wandb 사용 여부 설정 SAVE_MODEL = True USE_WANDB = True print("\n" + "=" * 50) print("모델 훈련 시작") print("=" * 50) # 훈련 파라미터 설정 training_args = TrainingArguments( output_dir="./results", num_train_epochs=NUM_EPOCHS, per_device_train_batch_size=BATCH_SIZE_TRAIN, per_device_eval_batch_size=BATCH_SIZE_EVAL, warmup_steps=WARMUP_STEPS, weight_decay=WEIGHT_DECAY, learning_rate=LEARNING_RATE, logging_steps=100, eval_strategy="epoch", save_strategy="epoch" if SAVE_MODEL else "no", load_best_model_at_end=SAVE_MODEL, metric_for_best_model="accuracy" if SAVE_MODEL else None, greater_is_better=True, save_total_limit=2 if SAVE_MODEL else 0, label_smoothing_factor=0.1, # 10% 레이블 스무딩 적용 report_to="wandb" if USE_WANDB else "none", # wandb 로깅 조건부 활성화 run_name="bert-movie-review-classification" if USE_WANDB else None, seed=RANDOM_STATE, fp16=torch.cuda.is_available(), dataloader_num_workers=2, remove_unused_columns=False, push_to_hub=False, gradient_accumulation_steps=1, logging_first_step=True, save_safetensors=SAVE_MODEL, # === 스케줄러 타입 변경 === lr_scheduler_type="cosine", # <--- 'linear'(기본값) 대신 'cosine'으로 설정 # === Early Stopping 관련 파라미터 추가 === # early_stopping_patience=3, # <--- 추가: 이 횟수만큼 평가 점수가 개선되지 않으면 중단 (예: 3 에폭) # early_stopping_threshold=0.001, # <--- (선택 사항) 개선으로 간주하기 위한 최소 변화량 ) early_stopping_callback = EarlyStoppingCallback(early_stopping_patience=3) # <--- 원하는 patience 값 # Trainer 초기화 trainer = CustomTrainerWithFocalLoss( model=model, args=training_args, train_dataset=train_dataset, eval_dataset=val_dataset, tokenizer=tokenizer, num_classes=NUM_CLASSES, focal_loss_alpha=[0.11, 0.45, 0.12, 0.32], # 예시 시작점 focal_loss_gamma=2.0, callbacks=[early_stopping_callback], # <--- 콜백 리스트 전달 data_collator=DataCollatorWithPadding(tokenizer=tokenizer), compute_metrics=compute_metrics, ) # 훈련 정보 출력 print(f"훈련 샘플: {len(train_dataset):,}개") print(f"검증 샘플: {len(val_dataset):,}개") print(f"훈련 에포크: {training_args.num_train_epochs}회") print(f"배치 크기: {BATCH_SIZE_TRAIN} (훈련) / {BATCH_SIZE_EVAL} (검증)") print(f"학습률: {LEARNING_RATE}") print(f"시드값: {RANDOM_STATE}") print(f"디바이스: {device}") print(f"wandb 사용: {USE_WANDB}") # 훈련 실행 try: training_results = trainer.train() print("\n훈련 완료") print(f"최종 훈련 손실: {training_results.training_loss:.4f}") # 훈련 로그 정보 출력 if hasattr(training_results, "log_history"): print(f"총 훈련 스텝: {training_results.global_step}") except KeyboardInterrupt: print("\n사용자에 의해 훈련이 중단되었습니다.") raise except Exception as e: print(f"\n훈련 중 오류 발생: {str(e)}") raise ``` `label_smoothing_factor=0.1,` 를 training_args로 줘서 label_smoothing을 해주었다. `lr_scheduler_type`을 `“cosine”` 으로 줘서 선형적으로 learning rate가 조정되는게 아닌 cosine개형으로 바뀌도록 설정해주었다. 일반적으로 Overfitting을 막고, Learning rate가 cosine개형으로 달라지기때문에, Regularization의 방법중 하나라고 한다.  실제로 wandb에서 learning_rate를 관찰해보면 주황색 그래프는 선형적으로 감소하는데 비해 코사인 개형을 따르는것을 볼 수 있다. Trainer에서는 `focal_loss_alpha=[0.11, 0.45, 0.12, 0.32]` 를통해서 기본적인 focal_loss의 각 클래스별 가중치를 클래스의 백분율의 역수로 설정해주었다. 그리고 `focal_loss_gamma=2.0` 를 통해 $$\gamma$$가 2를 갖는 focal loss의 개형을 설정해주었다. 이 $$\gamma$$값은 이후 하이퍼파라미터 튜닝으로 튜닝을 할 예정이다. # 결과  정규화를 해주었지만, 그럼에도 Training Loss는 감소할때 Validation Loss는 2epoch이후 계속 증가함을 볼 수 있다. 따라서 더 강한 정규화 전략을 짜고, 하이퍼파라미터 튜닝을 해봐야겠다.  에폭을 8로 설정한 탓이었을까? Focal Loss를 적용하고, Regularization을 도입했음에도 오히려 test성능이 줄어든 0.78을 기록했다. 이후실험에서는 하이퍼파라미터 튜닝을 통한 더 나은 정규화 방향을 찾아갈 예정이다. 그리고 Back Translation을 통한 데이터 증강, 확률적 가중치 평균 (Stochastic Weight Averaging - SWA) 기법을 이용해서 조금더 일반화 성능을 늘려볼 예정이다. 그리고 Early stopping의 기준을 Accuracy가 아니라 validationLoss로 설정해서 Validation Loss가 3에폭 이상에서 증가하면 학습을 종료하도록 설정을 해서 Overfitting을 막아봐야겠다. ### [Domain_Common_Project][모델최적화]-Feature_Engineering - Canonical URL: https://hyejunl33.github.io/projects/2025-10-26-[Domain_Common_Project]Feature_Engineering/ - Collection: Project - Published: 2025-10-25 - Tags: Domain_Common_Project, study, Feature_Engineering # 텍스트 전처리 및 정리 - 특수문자 제거, 공백 정규화 - 필요시 한국어 특화 전처리 처리 - 매우 짧거나 긴 텍스트 제거 또는 처리 - 중복 제거  - 자음, 모음만 있는경우를 제거한다. - 반복되는 표현을 정규화한다. 즉 “ㅋㅋㅋㅋ”나 “ㅎㅎㅎㅎㅎ”같은 표현을 “ㅋㅋ”, “ㅎㅎ”형태로 정규화 한다. - 비어있는 텍스트는 제거한다. - 중복되는 데이터도 모두 제거한다. # 텍스트 정규화 - 대소문자 정규화 - 구두점 처리 - 특수문자 처리 - URL/이메일/멘션 정리 ```python print("텍스트 정규화 과정 시작") print("=" * 50) # 대소문자 정규화 (BERT가 처리하지만 일관성을 위해) print("\n1단계: 대소문자 정규화 수행 중...") df_processed["review_normalized"] = df_processed["review_cleaned"].str.lower() print("✓ 소문자 변환 완료") # 구두점 정규화 print("\n2단계: 구두점 정규화 수행 중...") def normalize_punctuation(text): # 여러 개의 구두점을 하나로 정규화 # 1. (수정) 중립 구두점(.,)의 과도한 반복을 1개로 축소 (e.g., "..." -> ".") # BERT의 문맥 유지를 위해 제거하지 않고 '유지'합니다. text = re.sub(r"([.,])\1{2,}", r"\1", text) # 2. 감성 구두점(!, ?)의 과도한 반복을 2개로 축소 (e.g., "!!!!" -> "!!") text = re.sub(r"([!?])\1{2,}", r"\1\1", text) text = re.sub(r"[,]{2,}", ",", text) #3. (강화) 감성과 관련 없는 특정 노이즈 문자 제거 (확장된 Blacklist 방식) # 해시태그, 불필요한 강조, 리스트, 수학/화폐 기호, 일부 괄호 등 # (♥, 👍, ^^, >_< 같은 이모티콘/emoji는 이 목록에 없으므로 '유지'됩니다.) text = re.sub( r"[#*•■◆◇□○●※+=/\\%&{}\[\]$₩€£¥|`]", # <-- 대폭 확장된 노이즈 리스트 " ", text ) # 정규식 설명: # [#*•■◆◇□○●※] : 해시태그, 불릿, 특수 기호 # [+=/\\%&] : 수학/기술 기호 ( \는 \\로 이스케이프) # [{}\[\]] : 이모티콘에 사용되지 않는 괄호 ( []는 \로 이스케이프) # [$₩€£¥] : 화폐 기호 # [|`] : 파이프, 백틱 # 4. (수정) 전체 구두점 주변 공백 정리 text = re.sub(r"\s+([.,!?])", r"\1", text) # "정말 !" -> "정말!" text = re.sub(r"([.,!?])\s+", r"\1 ", text) # "최고! !!" -> "최고! !! " # 5. 과도한 공백을 단일 공백으로 최종 정리 text = re.sub(r"\s+", " ", text) return text.strip() df_processed["review_normalized"] = df_processed["review_normalized"].apply( normalize_punctuation ) print("✓ 구두점 정규화 완료") # 특수문자 추가 정리 print("\n3단계: 특수문자 정리 수행 중...") def clean_special_chars(text): # URL 패턴 제거 (있는 경우) text = re.sub( r"http[s]?://(?:[a-zA-Z]|[0-9]|[$-_@.&+]|[!*\\(\\),]|(?:%[0-9a-fA-F][0-9a-fA-F]))+", " ", text, ) # 이메일 패턴 제거 (있는 경우) text = re.sub(r"\S+@\S+", " ", text) # 멘션 패턴 제거 (있는 경우) text = re.sub(r"@\w+", " ", text) # 과도한 공백 정리 text = re.sub(r"\s+", " ", text) return text.strip() df_processed["review_normalized"] = df_processed["review_normalized"].apply( clean_special_chars ) print("✓ URL/이메일/멘션 제거 완료") # 정규화 후 빈 텍스트 처리 print("\n4단계: 정규화 후 빈 텍스트 확인 중...") empty_after_normalization = df_processed["review_normalized"].str.strip().eq("").sum() if empty_after_normalization > 0: df_processed = df_processed[df_processed["review_normalized"].str.strip() != ""] print(f"✓ 빈 텍스트 {empty_after_normalization}개 제거") else: print("✓ 빈 텍스트 없음") # 정규화 전후 비교 print("\n" + "=" * 50) print("정규화 결과 요약:") print(f"최종 데이터 크기: {len(df_processed):,}개") print(f"평균 길이 - 정리됨: {df_processed['review_cleaned'].str.len().mean():.1f}자") print( f"평균 길이 - 정규화됨: {df_processed['review_normalized'].str.len().mean():.1f}자" ) print("=" * 50) ``` - 모든문자를 우선 소문자로 정규화 한다. - 구두점처리 - 중복된 구두점은 1개나 2개로 축소해서 정규화한다. - 감성과 관련없는 특수문자는 노이즈로 여겨서 BlackList형식으로 제거한다. - 감성과 관련있는 이모티콘이나, 특수문자는 목록에 넣지 않아서 유지된다. - 구두점 주변 공백을 정리한다. - URL패턴이나 이메일패턴, 멘션패턴, 과도한 공백은 감성분류에 도움이 되지 않는 노이즈이므로 제거한다.  BaseLine코드에서는 최대한 자음/모음만 반복된 패턴, 특수문자, 이모지등을 모두 노이즈처리해서 전처리했었다. 하지만 이것들이 감성분류에 도움이 될수도 있지 않을까라는 생각에 해당 특수문자/ 이모지/ 감정을 나타내는 패턴등을 특수토큰으로 매핑해서 최대한 사용하고자 위의 코드처럼 구현했다. # 텍스트 전처리 파이프라인 재구성 - 앞서 정의한 함수들을 이용하여 파이프라인 구성 - DataLeakage를 방지하기 위한 전략을 포함해야 한다. - 전처리 파라미터는 학습 데이터에서만 학습 - Validation/Test데이터는 학습된 파라미터로만 변환 - 레이블 정보를 활용한 전처리는 학습 시에만 적용 ```python class TextPreprocessingPipeline: """ 텍스트 전처리 파이프라인 클래스 (정규식 오류 수정) - 전처리 로직을 단일 메서드로 통합 및 최적화 - fit 메서드: 커스텀 토크나이저를 위한 라벨별 감성 패턴 수집 """ def __init__(self): self.is_fitted = False # fit의 결과물: 라벨별 상위 감성 표현(이모티콘/emoji)을 저장 self.emotion_patterns_by_label = {} # 감성 표현을 찾는 정규식 # 1. (ㅋㅎㅠㅜㅡ): 한국어 감정 표현 (e.g., ㅋㅋ, ㅠㅠ) # 2. (T^>c<;:=_...): 아스키 이모티콘 (e.g., ^_^, T_T, :), >_<) # 3. (\U0001F...): 유니코드 이모지 (e.g., 😂, 👍, ♥) # --- [수정된 부분] --- self.EMOTION_REGEX = re.compile( r'([ㅋㅎㅠㅜㅡ]{2,})|' # 1. 한국어 # 2. 아스키 (맨 끝에 누락된 ')'를 '|' 앞에 추가) r'([T^>c<;:=_]{1,}(?:[-_oO\']{0,1})(?:[\)\]DdpP]|\[<]{1,}))|' # 3. 이모지 (캡처 그룹 '()'으로 묶고 맨 뒤의 불필요한 ')' 제거) r'([\U0001F600-\U0001F64F\U0001F300-\U0001F5FF\U0001F680-\U0001F6FF\U0001F1E0-\U0001F1FF\u2600-\u26FF\u2700-\u27BF♥👍😂])' ) # --- [수정 완료] --- def _clean_noise_patterns(self, text: str) -> str: """[1순위] URL, 이메일, 멘션 등 패턴 기반 노이즈 제거""" text = re.sub( r"http[s]?://(?:[a-zA-Z]|[0-9]|[$-_@.&+]|[!*\\(\\),]|(?:%[0-9a-fA-F][0-9a-fA-F]))+", " ", text ) text = re.sub(r"\S+@\S+", " ", text) text = re.sub(r"@\w+", " ", text) return text def _apply_preprocessing_rules(self, text: str) -> str: """ [핵심] 기본 전처리 및 정규화 규칙을 '올바른 순서'로 적용 """ if pd.isna(text): return "" text = str(text).strip() # 1. (가장 먼저) URL, 이메일, 멘션 등 노이즈 패턴 제거 text = self._clean_noise_patterns(text) # 2. 소문자화 (BERT가 처리하지만 일관성을 위해) text = text.lower() # 3. (강화) 감성과 관련 없는 특정 노이즈 문자 제거 (Blacklist) text = re.sub( r"[#*•■◆◇□○●※+=/\\%&{}\[\]$₩€£¥|`]", " ", text ) # 4. 한국어 특화 정리 (자음/모음만 있는 경우) # text = re.sub(r"[ㄱ-ㅎㅏ-ㅣ]+", "", text) # 5. 감정 표현 정규화 (e.g., ㅋㅋㅋ -> ㅋㅋ, ㅠㅠㅠ -> ㅠㅠ) text = re.sub(r"([ㅋㅎ])\1{2,}", r"\1\1", text) text = re.sub(r"([ㅠㅜㅡ])\1{2,}", r"\1\1", text) # 6. 구두점 정규화 text = re.sub(r"([.,])\1{2,}", r"\1", text) # e.g., "..." -> "." text = re.sub(r"([!?])\1{2,}", r"\1\1", text) # e.g., "!!!!" -> "!!" # 7. 구두점 주변 공백 정리 text = re.sub(r"\s+([.,!?])", r"\1", text) text = re.sub(r"([.,!?])\s+", r"\1 ", text) # 8. (마지막) 과도한 공백을 단일 공백으로 최종 정리 text = re.sub(r"\s+", " ", text) return text.strip() def fit(self, texts: pd.Series, labels: pd.Series): """ 학습 데이터(texts, labels)로부터 전처리 정보(감성 패턴)를 학습합니다. """ print("학습 데이터 기반 감성 패턴 수집 중...") if not isinstance(texts, pd.Series): texts = pd.Series(texts) if not isinstance(labels, pd.Series): labels = pd.Series(labels) # 1. 분석 전, 텍스트에 기본 정규화 규칙을 먼저 적용합니다. processed_texts = texts.apply(self._apply_preprocessing_rules) df = pd.DataFrame({'text': processed_texts, 'label': labels}) # 2. 라벨별로 순회하며 감성 패턴(이모티콘, emoji 등)을 찾습니다. for label in sorted(df['label'].unique()): label_texts = df[df['label'] == label]['text'] # findall과 explode를 사용해 모든 감성 표현을 추출 all_emotions = label_texts.str.findall(self.EMOTION_REGEX).explode().dropna() # 튜플로 반환되는 정규식 결과를 (e.g., ('ㅋㅋ', '', '')) 하나로 합침 # (튜플이 비어있는 경우 방지) cleaned_emotions = [] for tup in all_emotions: found = next((item for item in tup if item), None) if found: cleaned_emotions.append(found) # 3. 빈도를 계산하고 상위 10개를 저장합니다. top_emotions = Counter(cleaned_emotions).most_common(10) self.emotion_patterns_by_label[label] = top_emotions self.is_fitted = True print("✓ 감성 패턴 수집 완료 (파이프라인 학습 완료)") # 수집된 정보 예시 출력 print("\n--- 수집된 라벨별 상위 감성 패턴 (예시) ---") for label, patterns in self.emotion_patterns_by_label.items(): print(f" [Label {label}]: {patterns}") print("------------------------------------------") def transform(self, texts: pd.Series) -> pd.Series: """ 학습된 파이프라인(또는 기본 파이프라인)을 사용하여 텍스트를 변환합니다. """ if not self.is_fitted: print( "Warning: 파이프라인이 'fit'되지 않았습니다. 기본 전처리 규칙만 적용합니다." ) if not isinstance(texts, pd.Series): texts = pd.Series(texts) # _apply_preprocessing_rules 함수를 .apply로 효율적으로 적용 processed_texts = texts.apply(self._apply_preprocessing_rules) return processed_texts def fit_transform(self, texts: pd.Series, labels: pd.Series) -> pd.Series: """학습과 변환을 동시에 수행합니다.""" self.fit(texts, labels) return self.transform(texts) #파이프라인 인스턴스 생성 preprocessor = TextPreprocessingPipeline() ``` - 이전에 정의한 함수들을 이용해서 데이터 전처리 파이프라인 Class를 생성한다. - `clean_noise_pattens()` `,_apply_preprocessing_rules()` 함수를 통해 텍스트를 전처리한다. - `fit()` 메서드에서는 이후 k-fold방식으로 나눌 데이터들의 특징을 시각화하고, 확인하는 방법들을 사용한다. → 상위 10개 저장 - 데이터들의 특징(이모지 빈도, 감성표현 ‘ㅋㅋ’등의 빈도)을 확인하고 토크나이저에 특수토큰을 추가한다. - 파이프라인 인스턴스를 `preprocessor`로 선언한다. # BERT 전용 전처리 확인 - BERT 토크나이저를 사용해서 토큰화 - 토큰화 길이 제한 처리(BERT는 512 이하 토큰으로 제한) - 특수 토큰 추가([CLS],[SEP]) - 어텐션 마스크 생성 - 절단 및 패딩 전략 처리 ```python # BERT 토크나이저 초기화 # model_name = "klue/bert-base" model_name = "beomi/kcbert-base" tokenizer = AutoTokenizer.from_pretrained(model_name) print( f"BERT 토크나이저: {model_name}, vocab: {tokenizer.vocab_size}, max_length: {tokenizer.model_max_length}" ) ``` 모델 제한에 따라서 제한된 모델중 일단 `"beomi/kcbert-base"` 모델을 사용한다. 이 모델은 **온라인 댓글, 뉴스 리뷰 등 비정형적인 텍스트**를 포함한 대용량의 한국어 데이터로 학습되어있다고 한다. 따라서 영화리뷰를 분석할때, 신조어, 이모지, 구어체 문장에 대한 이해도가 가장 높을것으로 기대한다. ```python # --- 1단계: 특수 토큰 및 치환 규칙 정의 --- # 이 규칙은 preprocessor.fit()의 통계 결과를 바탕으로 '개발자가' 정의하는 것입니다. # (예시: {'Label 0': [('ㅠㅠ', 5000)], 'Label 3': [('ㅋㅋ', 8000), ('♥', 500)]}) # 1. 새로 추가할 특수 토큰 리스트 # (모델이 이 토큰을 하나의 의미 단위로 학습하게 됩니다) NEW_SPECIAL_TOKENS = [ "[LAUGH]", # 웃음 (ㅋㅋ, ㅎㅎ 등) "[CRY]", # 울음 (ㅠㅠ, ㅜㅜ 등) "[SMILE]", # 미소 (^^, :) 등) "[HEART]", # 하트 (♥, ♡ 등) "[EMOJI]", # 기타 이모지 (👍, 😂 등) ] # 2. 원본 텍스트를 위 특수 토큰으로 치환하기 위한 매핑 (정규식) # (순서가 중요합니다. 더 긴 것을 먼저 처리해야 합니다. e.g., ㅠㅠ > ㅠ) EMOTION_MAP = { re.compile(r'([ㅋㅎ]){2,}'): "[LAUGH]", # ㅋㅋ, ㅎㅎ, ㅋㅋㅋㅋ 등 re.compile(r'([ㅠㅜ]){2,}'): "[CRY]", # ㅠㅠ, ㅜㅜ, ㅠㅠㅠ 등 re.compile(r'(\^{2,})|(\:\))|(\:D)'): "[SMILE]", # ^^, :), :D 등 re.compile(r'[♥♡]'): "[HEART]", # ♥, ♡ # 기타 일반 유니코드 이모지 (fit에서 자주 보인 것들) re.compile(r'[👍😂😥🤔]'): "[EMOJI]", } def replace_emotions_with_tokens(text: str) -> str: """ 토크나이저에 넣기 전, 텍스트의 감성 표현을 특수 토큰 문자열로 치환합니다. """ for pattern, token in EMOTION_MAP.items(): text = pattern.sub(token, text) return text # --- 2단계: 토크나이저 로드 및 특수 토큰 추가 --- print("토크나이저 로드 및 특수 토큰 추가 중...") MODEL_NAME = "beomi/kcbert-base" # 우리가 선택한 모델 tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME) print(f"원본 어휘 사전 크기: {len(tokenizer)}") tokenizer.add_special_tokens({"additional_special_tokens": NEW_SPECIAL_TOKENS}) print(f"신규 토큰 추가 후 어휘 사전 크기: {len(tokenizer)}") # 중요: 이 작업 후, 모델을 로드할 때 반드시 # model.resize_token_embeddings(len(tokenizer)) 를 호출해야 합니다. # --- 3단계: 개선된 BERT 인코딩 함수 (배치 처리) --- def bert_tokenize_and_encode(texts: list, tokenizer, max_length=256, labels=None): """ (개선) BERT를 위한 텍스트 배치(batch) 토큰화 및 인코딩 - (신규) 감성 토큰 치환 기능 포함 - (개선) for 루프 대신 빠른 배치 인코딩 사용 """ # 1. (신규) 텍스트를 특수 토큰 문자열로 먼저 치환합니다. # (이 작업이 빠지면 [LAUGH] 토큰이 아무 의미가 없습니다) print("감성 표현을 특수 토큰 문자열로 치환 중...") try: processed_texts = [replace_emotions_with_tokens(text) for text in texts] except Exception as e: print(f"Error during text replacement: {e}") processed_texts = texts # 실패 시 원본 사용 print("배치 인코딩 수행 중 (대용량 처리)...") # 2. (개선) for 루프 대신, 리스트 전체를 한 번에 토크나이저에 전달 encoded_batch = tokenizer( processed_texts, add_special_tokens=True, # [CLS], [SEP] 토큰 추가 max_length=max_length, # 최대 길이 제한 padding="max_length", # 최대 길이까지 패딩 truncation=True, # 길이 초과시 절단 return_attention_mask=True, # 어텐션 마스크 생성 return_token_type_ids=True, # 토큰 타입 ID 생성 (BERT/KcBERT는 사용) return_tensors="pt", # PyTorch 텐서로 반환 ) # 'encoded_batch'는 이미 'input_ids', 'attention_mask' 등이 포함된 딕셔너리 if labels is not None: # labels를 파이토치 텐서로 변환 encoded_batch["labels"] = torch.tensor(labels, dtype=torch.long) print("배치 인코딩 완료.") return encoded_batch # --- (수정 없음) 토큰 길이 분석 함수 --- def analyze_token_lengths(texts, tokenizer, max_length=256): """토큰 길이 분포 분석 (tokenizer를 인자로 받도록 수정)""" token_lengths = [] # 감성 토큰 치환을 먼저 적용 processed_texts = [replace_emotions_with_tokens(text) for text in texts] print("토큰 길이 분석 중...") for text in processed_texts: tokens = tokenizer.tokenize(text) # .tokenize()는 특수토큰([CLS]) 미포함 token_lengths.append(len(tokens)) token_lengths = np.array(token_lengths) print( f"토큰 길이: 평균 {token_lengths.mean():.1f}, 중앙값 {np.median(token_lengths):.1f}, 범위 {token_lengths.min()}-{token_lengths.max()}" ) print( f"분석 기준 MaxLength {max_length} 토큰 초과: {(token_lengths > max_length).sum()}개 ({(token_lengths > max_length).mean() * 100:.1f}%)" ) return token_lengths ``` - 토크나이저에 커스텀하기 위해 특수토큰을 추가한다. ```python --- 수집된 라벨별 상위 감성 패턴 (예시) --- [Label 0]: [('ㅠㅠ', 33867), ('ㅋㅋ', 7427), ('ㅡㅡ', 2363), ('ㅎㅎ', 954), ('ㅜㅜ', 519), ('😡', 44), ('★', 33), ('ㅋㅋㅠㅠ', 30), ('ㅡㅡㅋ', 26), ('ㅜㅠ', 24)] [Label 1]: [('ㅠㅠ', 9489), ('ㅎㅎ', 2362), ('ㅋㅋ', 1856), ('ㅜㅜ', 86), ('ㅡㅡ', 78), ('★', 26), ('😊', 22), ('🌟', 18), ('ㅠㅜ', 12), ('♥', 11)] [Label 2]: [('ㅎㅎ', 19727), ('ㅋㅋ', 9407), ('ㅠㅠ', 5677), ('♥', 832), ('🌟', 640), ('✨', 510), ('ㅜㅜ', 477), ('😊', 415), ('♡', 360), ('👍', 351)] [Label 3]: [('ㅎㅎ', 5713), ('ㅠㅠ', 4948), ('ㅋㅋ', 3900), ('♥', 2067), ('♡', 571), ('ㅜㅜ', 391), ('🌟', 330), ('★', 206), ('✨', 142), ('👍', 137)] ------------------------------------------ ``` 수집된 라벨별 감성패턴을 보면 ‘ㅠㅠ’나 ‘ㅋㅋ’같은 감정패턴은 레이발과 상관없이 자주 등장함을 볼 수 있다. 따라서 노이즈처리를 해야하나 고민을 해보았다. 하지만 BERT기반 모델은 문맥을 이해하므로 이러한 토큰을 남겨두는게 유리하다. - Bidirectional Processing: BERT는 한방향으로만 학습을 하는게 아니라, 문장 전체를 한번에 어텐션으로 보고, 특정 단어의 의미를 파악할때 그 단어의 앞뒤 모든 단어정보를 동시에 활용한다. - Self-Attention: BERT는 Multi Head-self Attention(head는 12개)을 이용해서 문장 전체의 문맥을 병렬적으로 파악한다. # 데이터 분할 전략 - 훈련/검증 데이터 분할 - 클래스 분포를 유지하는 계층적 분할 우선 stratified K-Fold cross validation을 사용한다. 데이터셋을 5개로 나누고, 각각 validation데이터를 20%, train 데이터를 80%로 사용해서 서로 다른 경우의수 5번을 학습시킨다. 이후 추론단계에서는 5개의 모델을 앙상블해서 소프트 voting을 통해 추론결과를 도출해낸다. ```python from sklearn.model_selection import StratifiedKFold from sklearn.utils.class_weight import compute_class_weight from transformers import AutoTokenizer, AutoModelForSequenceClassification, TrainingArguments, DataCollatorWithPadding, Trainer import numpy as np import pandas as pd import torch import os import torch.nn.functional as F # 앙상블 시 필요 from torch.utils.data import DataLoader # 추론 시 필요 # (기존 변수들: USE_WANDB, SAVE_MODEL, df, RANDOM_STATE, ...) # (기존 클래스/함수 정의: TextPreprocessingPipeline, replace_emotions_with_tokens, ReviewDataset, CustomTrainer, compute_metrics, ...) USE_WANDB = True SAVE_MODEL = True # ★★★ 모델 저장을 True로 유지 # 사용할 전체 데이터 (전처리 파이프라인 적용 전 원본) X_full = df["review"] y_full = df["label"] ids_full = df["ID"] # Stratified K-Fold 설정 N_SPLITS = 5 skf = StratifiedKFold(n_splits=N_SPLITS, shuffle=True, random_state=RANDOM_STATE) print(f"\nStratified {N_SPLITS}-Fold Cross Validation 시작...") fold_metrics = [] all_fold_train_history = [] saved_model_paths = [] # ★★★ [추가] 각 Fold의 베스트 모델 저장 경로 리스트 # K-Fold 루프 시작 for fold, (train_index, val_index) in enumerate(skf.split(X_full, y_full)): print(f"\n===== Fold {fold+1}/{N_SPLITS} =====") # ... (1. 데이터 분할 ~ 7. 데이터셋 생성 까지는 동일) ... # 1. 현재 Fold의 훈련/검증 데이터 분할 (원본 데이터 사용) X_train, X_val = X_full.iloc[train_index], X_full.iloc[val_index] y_train, y_val = y_full.iloc[train_index], y_full.iloc[val_index] ids_train, ids_val = ids_full.iloc[train_index], ids_full.iloc[val_index] print(f"훈련 데이터: {len(X_train)}개, 검증 데이터: {len(X_val)}개") # 2. 전처리 파이프라인 적용 (각 Fold마다 새로 학습) preprocessor_fold = TextPreprocessingPipeline() # 매 Fold마다 새 인스턴스 print("현재 Fold 훈련 데이터에 대한 전처리 파이프라인 학습 및 적용...") X_train_processed = preprocessor_fold.fit_transform(X_train, y_train) print("현재 Fold 검증 데이터에 전처리 파이프라인 적용...") X_val_processed = preprocessor_fold.transform(X_val) # 3. 특수 토큰 치환 적용 print("훈련/검증 데이터에 특수 토큰 치환 적용 중...") X_train_replaced = [replace_emotions_with_tokens(text) for text in X_train_processed.tolist()] X_val_replaced = [replace_emotions_with_tokens(text) for text in X_val_processed.tolist()] print("✓ 특수 토큰 치환 완료") # 4. 모델 학습용 DataFrame 생성 (현재 Fold 용) train_data_fold = pd.DataFrame( {"ID": ids_train.tolist(), "review": X_train_replaced, "label": y_train.tolist()} ) val_data_fold = pd.DataFrame( {"ID": ids_val.tolist(), "review": X_val_replaced, "label": y_val.tolist()} ) # 5. 토크나이저 초기화 및 특수 토큰 추가 (매 Fold마다) print(f"\nFold {fold+1}: 토크나이저 로딩 및 수정 ({model_name})") tokenizer_fold = AutoTokenizer.from_pretrained(model_name) tokenizer_fold.add_special_tokens({"additional_special_tokens": NEW_SPECIAL_TOKENS}) print(f"Fold {fold+1}: 어휘 사전 크기: {len(tokenizer_fold)}") # 6. 모델 초기화 및 임베딩 크기 조정 (매 Fold마다) print(f"Fold {fold+1}: 모델 로딩 및 수정 ({model_name})") model_fold = AutoModelForSequenceClassification.from_pretrained( model_name, num_labels=NUM_CLASSES, ) model_fold.resize_token_embeddings(len(tokenizer_fold)) print(f"Fold {fold+1}: 모델 임베딩 크기 조정 완료.") model_fold.to(device) # 모델을 GPU로 이동 # 7. 데이터셋 생성 (현재 Fold 데이터 사용) print(f"Fold {fold+1}: 데이터셋 생성 중...") train_dataset_fold = ReviewDataset( train_data_fold["review"], train_data_fold["label"], tokenizer_fold, CHOSEN_MAX_LENGTH, ) val_dataset_fold = ReviewDataset( val_data_fold["review"], val_data_fold["label"], tokenizer_fold, CHOSEN_MAX_LENGTH, ) print(f"Fold {fold+1}: 훈련 {len(train_dataset_fold)}개, 검증 {len(val_dataset_fold)}개 데이터셋 생성 완료.") # 8. 클래스 가중치 계산 (현재 Fold 훈련 데이터 기준) print(f"Fold {fold+1}: 클래스 가중치 계산 중...") class_weights_fold = compute_class_weight( 'balanced', classes=np.unique(y_train), # 현재 Fold의 y_train 사용 y=y_train.to_numpy() ) class_weights_tensor_fold = torch.tensor(class_weights_fold, dtype=torch.float) print(f"Fold {fold+1}: 계산된 클래스 가중치: {class_weights_tensor_fold}") # 9. TrainingArguments 설정 (출력 디렉토리 변경) # ★★★ output_dir을 명확하게 지정합니다. output_dir_fold = f"./results_fold_{fold+1}" training_args_fold = TrainingArguments( output_dir=output_dir_fold, # Fold별 디렉토리 num_train_epochs=NUM_EPOCHS, per_device_train_batch_size=BATCH_SIZE_TRAIN, per_device_eval_batch_size=BATCH_SIZE_EVAL, warmup_steps=WARMUP_STEPS, weight_decay=WEIGHT_DECAY, learning_rate=LEARNING_RATE, logging_steps=100, eval_strategy="epoch", save_strategy="epoch", load_best_model_at_end=True, # ★★★ 훈련 종료 후 최고 모델 로드 metric_for_best_model="accuracy", greater_is_better=True, save_total_limit=1, report_to="wandb" if USE_WANDB else "none", run_name=f"kfold_{fold+1}_{model_name.split('/')[-1]}" if USE_WANDB else None, seed=RANDOM_STATE, fp16=torch.cuda.is_available(), dataloader_num_workers=2, remove_unused_columns=False, ) # 10. Custom Trainer 정의 (이미 완료됨) # 11. Custom Trainer 초기화 (현재 Fold 데이터 및 가중치 사용) print(f"Fold {fold+1}: Custom Trainer 초기화 중...") trainer_fold = CustomTrainer( model=model_fold, args=training_args_fold, train_dataset=train_dataset_fold, eval_dataset=val_dataset_fold, tokenizer=tokenizer_fold, data_collator=DataCollatorWithPadding(tokenizer=tokenizer_fold), compute_metrics=compute_metrics, class_weights=class_weights_tensor_fold ) print(f"Fold {fold+1}: ✓ Custom Trainer 초기화 완료") # 12. 모델 훈련 실행 print(f"Fold {fold+1}: 모델 훈련 시작...") try: train_result = trainer_fold.train() print(f"Fold {fold+1}: ✓ 모델 훈련 완료") # 13. 현재 Fold 검증 성능 평가 및 저장 print(f"Fold {fold+1}: 검증 데이터 평가 중...") eval_results = trainer_fold.evaluate() fold_metrics.append(eval_results) # 결과 저장 print(f"Fold {fold+1}: ✓ 검증 완료: {eval_results}") # --- ★★★ [수정] 앙상블을 위한 모델/토크나이저 저장 --- # load_best_model_at_end=True이므로, # trainer_fold.model은 이미 베스트 모델 상태입니다. if SAVE_MODEL: # TrainingArguments의 output_dir과 별개로 # 앙상블에 사용하기 쉬운 명확한 경로에 저장합니다. save_path = f"./best_model_fold_{fold+1}" trainer_fold.save_model(save_path) tokenizer_fold.save_pretrained(save_path) # [추가] 저장된 경로를 리스트에 추가합니다. saved_model_paths.append(save_path) print(f"Fold {fold+1}: 최고 성능 모델 저장 완료: {save_path}") # --------------------------------------------------- except Exception as e: print(f"Fold {fold+1}: 훈련/평가 중 오류 발생: {e}") fold_metrics.append(None) # 메모리 정리 del model_fold, tokenizer_fold, train_dataset_fold, val_dataset_fold, trainer_fold if torch.cuda.is_available(): torch.cuda.empty_cache() # K-Fold 루프 종료 print(f"\n===== Stratified {N_SPLITS}-Fold Cross Validation 종료 =====") # --- 최종 결과 분석 (기존 코드와 동일) --- # ... (avg_accuracy, std_accuracy 등 계산 및 출력) ... print("\n===== 최종 교차 검증 결과 분석 =====") valid_results = [m for m in fold_metrics if m is not None] if len(valid_results) > 0: avg_accuracy = np.mean([m['eval_accuracy'] for m in valid_results]) std_accuracy = np.std([m['eval_accuracy'] for m in valid_results]) # ... (기타 F1, Loss 계산) ... print(f"총 {len(valid_results)}개 Fold 결과 분석:") print(f" 평균 검증 정확도 (Accuracy): {avg_accuracy:.4f} ± {std_accuracy:.4f}") # ... (기타 F1, Loss 출력) ... else: print("오류로 인해 유효한 교차 검증 결과가 없습니다.") print("===================================") ```  무언가 잘못된것인지 각 Fold마다 Training Loss는 줄어드는 추세를 보이지만, Validation Loss는 줄어들지 않는 경향을 보였다. 그리고 Training Loss는 계속해서 줄어드는 추세를 보여서, 이후에는 과적합 문제를 해결한다음, epoch을 더 늘려서 Loss를 줄이는 방법을 고려해봐야겠다. 최종 Cross Validation을평균내보면 0.8318로 초기 모델의 acc인 0.8보다 3%정도 성능향상이 있음을 확인할 수 있다. ```python print("\n===== 앙상블 추론(Inference) 시작 =====") # 1. 테스트 데이터 로드 (e.g., Cell 37) print("테스트 데이터 로딩...") try: # (test.csv 경로는 실제 환경에 맞게 수정) df_test = pd.read_csv("test.csv") X_test = df_test["review"] ids_test = df_test["ID"] print(f"테스트 데이터 {len(df_test)}개 로드 완료.") except FileNotFoundError: print("Error: test.csv 파일을 찾을 수 없습니다. 추론을 중단합니다.") # 이 경우 아래 코드는 실행되지 않습니다. if 'df_test' in locals(): # 테스트 데이터가 성공적으로 로드되었는지 확인 # 2. 테스트 데이터 전처리 # ★★★ 중요: 전처리 파이프라인은 K-Fold에 사용한 *전체* 훈련 데이터로 # 다시 학습(fit)한 후, 테스트 데이터에 적용(transform)해야 합니다. # (K개 Fold 중 하나의 파이프라인을 사용하는 것은 편향될 수 있음) print("\n2. 전체 훈련 데이터로 최종 전처리기 학습...") final_preprocessor = TextPreprocessingPipeline() # K-Fold 루프 밖의 X_full, y_full 사용 final_preprocessor.fit(X_full, y_full) print("테스트 데이터에 전처리기 적용...") X_test_processed = final_preprocessor.transform(X_test) print("테스트 데이터에 특수 토큰 치환 적용...") X_test_replaced = [replace_emotions_with_tokens(text) for text in X_test_processed.tolist()] print("✓ 전처리 및 치환 완료.") # 3. K-Fold 모델 앙상블 추론 all_fold_logits = [] # K개 모델의 로짓(logits)을 저장할 리스트 saved_model_paths = [f"./best_model_fold_{i+1}" for i in range(N_SPLITS)] print(f"\n3. {len(saved_model_paths)}개 Fold 모델로 추론 수행...") for fold, model_path in enumerate(saved_model_paths): print(f"--- Fold {fold+1} 모델 추론 ({model_path}) ---") # A. Fold별 저장된 모델 및 토크나이저 로드 print("모델 및 토크나이저 로딩...") tokenizer_inf = AutoTokenizer.from_pretrained(model_path) model_inf = AutoModelForSequenceClassification.from_pretrained(model_path) model_inf.to(device) model_inf.eval() # B. 테스트 데이터셋 생성 (Fold의 토크나이저 사용) # ReviewDataset이 레이블을 필요로 하므로, 더미 레이블 생성 test_labels_dummy = [0] * len(X_test_replaced) test_dataset_inf = ReviewDataset( reviews=X_test_replaced, labels=test_labels_dummy, tokenizer=tokenizer_inf, max_length=CHOSEN_MAX_LENGTH ) test_data_collator = DataCollatorWithPadding(tokenizer=tokenizer_inf) # C. 추론 실행 (Trainer의 .predict() 메소드 활용) # 추론용 TrainingArguments (간단하게 설정) test_args = TrainingArguments( output_dir=f"./temp_inference_output_{fold+1}", per_device_eval_batch_size=BATCH_SIZE_EVAL, # 훈련 시 eval 배치 크기 사용 fp16=torch.cuda.is_available(), dataloader_num_workers=2, report_to="none", # 추론 시 로그 불필요 ) trainer_inf = Trainer( model=model_inf, args=test_args, tokenizer=tokenizer_inf, data_collator=test_data_collator, ) # .predict()는 (predictions, label_ids, metrics) 튜플 반환 # predictions는 로짓(logits)이 담긴 numpy 배열입니다. predictions_output = trainer_inf.predict(test_dataset_inf) fold_logits_np = predictions_output.predictions # numpy 배열을 torch 텐서로 변환하여 리스트에 추가 all_fold_logits.append(torch.tensor(fold_logits_np)) print(f"Fold {fold+1} 추론 완료. 로짓 shape: {fold_logits_np.shape}") # 메모리 정리 del model_inf, tokenizer_inf, test_dataset_inf, trainer_inf if torch.cuda.is_available(): torch.cuda.empty_cache() # 4. K-Fold 예측 결과 앙상블 (Averaging) print("\n4. K-Fold 예측 결과 앙상블 (Averaging)...") # all_fold_logits 리스트에는 (num_test_samples, num_classes) 텐서가 K개 있음 # torch.stack을 사용해 (K, num_test_samples, num_classes) 텐서로 만듦 stacked_logits = torch.stack(all_fold_logits) print(f"Stacked logits shape (K, N_samples, N_classes): {stacked_logits.shape}") # K개 모델의 로짓을 평균 (dim=0 : K(fold) 차원) mean_logits = torch.mean(stacked_logits, dim=0) print(f"Mean logits shape (N_samples, N_classes): {mean_logits.shape}") # 최종 예측 클래스 (가장 높은 로짓의 인덱스) final_predictions = torch.argmax(mean_logits, dim=1) # (참고) 최종 확률값이 필요한 경우 # final_probs = F.softmax(mean_logits, dim=1) # 5. 제출 파일 생성 print("\n5. 제출 파일 생성...") submission_df = pd.DataFrame({ 'ID': ids_test, # 테스트 데이터의 ID 사용 'label': final_predictions.numpy() # 텐서를 numpy 배열로 변환 }) submission_filename = "ensemble_submission.csv" submission_df.to_csv(submission_filename, index=False) print(f"✓ 제출 파일 '{submission_filename}' 생성 완료!") print(submission_df.head()) else: print("테스트 데이터가 로드되지 않아 추론을 건너뜁니다.") print("===================================") ``` 각 Fold마다 다른 모델을 써서 앙상블하는 방법도 있겠지만, 우선 `beomi/bert` 모델만을 사용해서, Stratified k-Fold cross Validation을 해주었다. 추론을 할때 k개 Fold중 하나의 파이프라인을 사용해서 dict를 사용하거나 하면 편향될 수 있으므로, 다시 전체 데이터셋을 파이프라인으로 `fit` 한후에 사용해주어야 한다. # 클래스 불균형 처리 - Weighted Cross Entropy ```python from sklearn.utils.class_weight import compute_class_weight # 클래스별 가중치 계산 print("\n클래스 가중치 계산 중...") # y_train은 train_test_split에서 반환된 pandas Series class_weights = compute_class_weight( 'balanced', classes=np.unique(y_train), y=y_train.to_numpy() # Series를 numpy 배열로 변환 ) # PyTorch 텐서로 변환 class_weights_tensor = torch.tensor(class_weights, dtype=torch.float) print(f"계산된 클래스 가중치: {class_weights_tensor}") ``` EDA에서 확인했듯이 데이터에서 클래스별 불균형이 있었다. 따라서 클래스비율의 역수를 CrossEntropy Lossfunction의 가중치로 사용해서 소수 클래스의 Loss는 그 비율의 역수만큼 더 많이 반영되게 처리를 해주었다. # 결과 및 이후 실험계획  베이스 모델의 성능  베이스모델인 마라탕후루후루에 비해 Feature Engineering을 한 모델이 오히려 성능이 떨어졌음을 알 수 있다. 왜일까… ### Weighted Cross Entropy Weighted Cross Entropy는 소수 클래스에 대한 recall을 향상시켜주지만, 대다수를 차지하는 클래스에 대해서는 정확도가 낮아질 수 있다. 이 대회의 metric은 accuracy 하나이므로 어쩌면 weighted cross entropy를 사용하지 않는게 metric인 accuracy를 높일 수 있는 방법인지 모르겠다. ### 커스텀 토크나이저에 특수토큰 추가하기 기존에는 뭉뚱그려서 [emoji]토큰을 매핑해서 이모지를 구분하지 않는 문제가 있었다. 이모지에는 화난 이모티콘, 웃는이모티콘등 다양하다. 이들을 구현하지 않아서 성능이 잘 안나온 것 같다. ```python --- 수집된 라벨별 상위 감성 패턴 (예시) --- [Label 0]: [('ㅠㅠ', 33867), ('ㅋㅋ', 7427), ('ㅡㅡ', 2363), ('ㅎㅎ', 954), ('ㅜㅜ', 519), ('😡', 44), ('★', 33), ('ㅋㅋㅠㅠ', 30), ('ㅡㅡㅋ', 26), ('ㅜㅠ', 24)] [Label 1]: [('ㅠㅠ', 9489), ('ㅎㅎ', 2362), ('ㅋㅋ', 1856), ('ㅜㅜ', 86), ('ㅡㅡ', 78), ('★', 26), ('😊', 22), ('🌟', 18), ('ㅠㅜ', 12), ('♥', 11)] [Label 2]: [('ㅎㅎ', 19727), ('ㅋㅋ', 9407), ('ㅠㅠ', 5677), ('♥', 832), ('🌟', 640), ('✨', 510), ('ㅜㅜ', 477), ('😊', 415), ('♡', 360), ('👍', 351)] [Label 3]: [('ㅎㅎ', 5713), ('ㅠㅠ', 4948), ('ㅋㅋ', 3900), ('♥', 2067), ('♡', 571), ('ㅜㅜ', 391), ('🌟', 330), ('★', 206), ('✨', 142), ('👍', 137)] ------------------------------------------ ``` 특히 감성패턴을 추출해서 토큰화했는데, 레이블간 구분없이 ‘ㅎㅎ’,’ㅠㅠ’,’ㅋㅋ’등은 모두 자주 등장함을 알 수 있다. 이러한 감성 패턴들을 차라리 노이즈로 구분하는게 좋을지 아니면 특수토큰처리하는게 좋을지, 나머지 변인들을 통제변인 처리하고 실험을 통해서 답을 찾아봐야겠다. 추가로 불용어 처리를 BaseModel에서는 의미가 있는것 같은 단어들도 모두 처리를 했었는데, 수정한 모델에서는 불용어를 기본적인 조사, 어미로 대폭 줄였다. 즉 ‘진짜’같은 단어들은 불용어처리가 되어있었는데, ‘진짜’라는 단어는 의미를 담고있지만, 레이블에 상관없이 모든문장에서 자주 등장하는 단어이다. 따라서 불용어를 해제하니깐, 성능이 하락한게 아닌가 싶다. 이것도 나머지 변인들을 통제변인 처리하고 실험을 통해서 불용어처리를 어떻게 해나갈지 답을 찾아나가봐야겠다. 한번에 여러가지 기능을 구현해보니깐, 어떤 요인이 성능에 어떻게 영향을 미쳤는지 비교하기가 어려웠다. 나머지 변인들을 통제변인으로 설정하고, 한가지씩 베이스라인 코드에 적용해보면서 실험결과를 바탕으로 나중에 한번에 모델로 구현해봐야겠다. ### [영화리뷰 감성분류][모델최적화]-EDA - Canonical URL: https://hyejunl33.github.io/projects/2025-10-24-[Domain_Common_Project]EDA/ - Collection: Project - Published: 2025-10-24 - Tags: Domain_Common_Project, study, EDA # [모델최적화]-EDA ## 데이터셋 형태 및 기본정보  - 28만개의 데이터가 4개의 클래스를 갖는 형태를 띠고있다. - review가 결측인 데이터가 6개가 있다. - 중복리뷰는 3350개있다. 이떄 중복면서 label이 서로다른 리뷰가 있는것이 보인다. ## 타겟변수 분석  일단 데이터셋은 Imbalance함을 알 수 있따. 강한 긍정과 약한 부정데이터가 상대적으로 적고, 강한 부정과, 약한 긍정 데이터가 많음을 알 수 있다. 모델이 일반화된 학습을 할 수 있도록 Focal Loss나 Weighted Cross Entropy를 사용해야한다. ## 입력변수 분석  .png) - 텍스트 길이를 분포로 확인해보면 문자수 분포랑 단어수분포가 일반적으로 일치함을 알 수 있다. → 다를이유가 없으니깐 - 일반적으로 x축이 작은곳에 분포가 몰려있고, 그 이후에 종모양의 분포가 있음을 알 수 있다.  매우 짧은 리뷰와 매우 긴 리뷰를 살펴보면 직관적으로 봤을때는 짧은리뷰나, 긴리뷰나 데이터로 사용할 가치가 있어보인다.(레이블과 리뷰가 일치해보인다.) 일단 데이터로 모두 사용해보고, 이 이상치들을 뺴거나 넣거나 해보자. 특히 짧은 리뷰를 모두 필터링하기에는 데이터셋의 대다수가 필터링되어버리기 때문에, 만약 이상치를 거른다면, 매우 긴 리뷰를 걸러보는 실험을 해볼 수 있을것 같다. ## 텍스트 품질 평가 - 비어있거나 null인 텍스트 확인 - 잠재적인 데이터 품질 문제 식별 - 언어 일관성 확인  - null값이 6개가 있는데 Feature engineering에서 빼야겠다. - 중복리뷰는 중복되는 값들을 빼고 한개의 데이터만 남겨서 학습을 해야겠다. - 특수문자만 있는 리뷰는 특수문자를 특수토큰으로 토크나이징하는 기법을 이용해서 사용해봐야겠다. - 다만 감정을 표현하는 특수문자인 하트, 느낌표, 물음표등이 있긴 하지만, ;이나 ,같은 특수문자가 있는 리뷰도 있기때문에 일단 빼고 학습하는게 맞는것 같다. - 이부분은 정규식을 이용해서 !,?,ㅋ,ㅠ,하트이모티콘,~,간단한 이모티콘(^^,:)) 등 몇가지 경우의수를 정해두고, 감성을 포함한 특수문자만 학습데이터에 넣고, 아닌 경우는 데이터에서 빼야겠다.  - 숫자만 있는 리뷰는 0점이라면 0, 4점이라면 4 라는식의 리뷰인지 직접 확인해보고 뺄지 넣을지 생각해봐야겠다. - 한글이 없는 리뷰는 영어로 리뷰를 작성한게 대부분같은데, Tokenizer를 이용할때, 한글이 아닌경우 영어단어도 voca에 추가해서 처리할 수 있는지 고려해봐야될것 같다.  ## 클래스별 텍스트 특성  클래스별 텍스트 길이에 유의미한 차이가 있진 않다.→ 텍스트 길이에따라 과적합될 걱정은 안해도 될 것 같다.  클래스별 어휘의 다양성(TTR)도 유의미한 차이가 보이지는 않는다. ```python # 한국어 불용어 리스트 확장 # 일단 불용어를 최소화하여 감성 단어가 포함될 수 있도록 조정 stopwords = [ # --- 조사 --- "은", "는", "이", "가", "을", "를", "의", "에", "와", "과", "도", "로", "으로", "에서", "에게", "께", "한테", "한테서", "께서", # --- 연결 어미 (일부) --- "고", "며", "면", "나", "니", "다", "서", "아", "어", # --- 대명사/지시사 (문맥 의존성 높음, 최소화) --- "그", "저", "이", "것", "곳", "때", "수", # '수 있다/없다' 등에서 중요할 수 있어 포함 여부 실험 필요 # --- 접속사 (문맥 의존성 높음, 최소화) --- "그리고", "그러나", "하지만", "그런데", # --- 기타 (문맥 의존성 높음, 최소화) --- "한", # '한 번' 등 수식 역할 # --- 주석 처리된 기존 불용어 중 감성 가능성 있는 단어 --- # "있다", "없다", "되다", "하다", "이다", "아니다", "같다", "많다", # "좋다", "나쁘다", "정말", "너무", "매우", "아주", "참", "좀", # "사람", "것들" ] ``` - 불용어 리스트를 봤을때, 감성분류 task인 만큼, 좋다, 나쁘다, 정말등등은 불용어가 아니라 감성을 담고있는 단어라고 생각이 들어서 주석처리를 했다. 감성을 담고있지 않은 단어들을 불용어처리 해야하기 때문에 일단 주석처리한 위의 리스트를 학습에 활용해야 겠다. - BERT는 문맥을 이해하기 때문에 제외할 불용어는 최소화하는걸 추천한다고 한다. - 어휘사전을 데이터셋이 나뉘기전에 만들어버리면 Data_leakage문제가 발생한다! → k-Fold등으로 데이터셋을 나누고 난 후에 각각 만들어야됨. ```python 클래스별 상위 빈출 단어 (불용어 제외): 0 (강한 부정) - 총 114066개 샘플: 1. '너무': 106022회 (3.2%) 2. '진짜': 82753회 (2.5%) 3. '보는': 55270회 (1.7%) 4. '정말': 52786회 (1.6%) 5. '이런': 52545회 (1.6%) 6. '영화': 49829회 (1.5%) 7. '영화는': 44978회 (1.4%) 8. '보고': 44776회 (1.4%) 9. '영화를': 40348회 (1.2%) 10. '내내': 39208회 (1.2%) 1 (약한 부정) - 총 27216개 샘플: 1. '너무': 16454회 (2.2%) 2. '보고': 10499회 (1.4%) 3. 'ㅠㅠ': 8538회 (1.1%) 4. '뭔가': 7251회 (1.0%) 5. '영화': 7061회 (0.9%) 6. '보는': 6857회 (0.9%) 7. '진짜': 6833회 (0.9%) 8. '정말': 6658회 (0.9%) 9. '그냥': 6467회 (0.9%) 10. '영화는': 6200회 (0.8%) 2 (약한 긍정) - 총 99416개 샘플: 1. '진짜': 60021회 (2.3%) 2. '정말': 56003회 (2.1%) 3. '너무': 45092회 (1.7%) 4. '영화': 34369회 (1.3%) 5. '보는': 29527회 (1.1%) 6. '특히': 28620회 (1.1%) 7. '영화는': 26255회 (1.0%) 8. '내내': 22921회 (0.9%) 9. '영화를': 20993회 (0.8%) 10. '보고': 19278회 (0.7%) 3 (강한 긍정) - 총 38952개 샘플: 1. '진짜': 46041회 (4.4%) 2. '정말': 24398회 (2.4%) 3. '너무': 22577회 (2.2%) 4. '영화': 17807회 (1.7%) 5. '영화는': 15968회 (1.5%) 6. '보는': 12402회 (1.2%) 7. '특히': 11121회 (1.1%) 8. '내내': 10439회 (1.0%) 9. '보고': 9783회 (0.9%) 10. '영화를': 9369회 (0.9%) ``` - ‘진짜’를 불용어처리를 막으니깐, 강한긍정, 약한긍정, 강한부정 모두에서 상위권에 속함을 알 수 있다. 이게 실제 모델이 validation할때 어떤 영향을 미칠지는 아직 잘 모르겠는데, 불용어 리스트를 바꿔가며 실험을 해봐야겠다. ### [영화리뷰 감성분류][study]메트릭 선택은 기술이 아니라 의사결정의 정치다. - Canonical URL: https://hyejunl33.github.io/projects/2025-10-22-[Domain_Common_Project]Select_Metrics/ - Collection: Project - Published: 2025-10-22 - Tags: Domain_Common_Project, study, metrics, FocalLoss, WeigtedCrossEntropy, Lossfunction 이 글은 원본글을 바탕으로 학습목적으로 정리한 글임을 밝힙니다. 원본 글: https://stages.ai/en/competitions/370/board/community/post/3051 # 메트릭 선택은 기술이 아니라 의사결정의 정치다. 모델 개발에서 성능이 좋다는건 특정 메트릭의 값이 좋다는 의미다. → 어떤 메트릭을 우선시 해야할까? - **Accuracy**: 전체 예측 중 맞춘 비율. 간단하지만, 데이터 불균형에서는 무의미할 수 있음. - **Precision**: Positive로 예측한 것 중 실제로 Positive인 비율. False Positive 줄이는 데 초점. - **Recall**: 실제 Positive 중에서 모델이 Positive로 잡아낸 비율. False Negative 줄이는 데 초점. - **FPR (False Positive Rate)**: 실제 Negative 중에서 Positive로 잘못 분류한 비율. 각 metric마다 데이터에서 중점으로 여기는 부분이 다르다. # 불균형 데이터에서 acc의 의미 어떤 질병이 있는 환자의 비율이 1%라고 할때 질병이 없는 환자의 비율은 99%이다. 어떤 모델은 input과 상관없이 질병이 없다라고만 판단을 내릴때 Accuracy는 99%이다. 얼핏보면 좋은 모델인것 처럼 보이지만, 인풋과 상관없이 질병이 없다라고만 판단을 내리므로 좋은 모델은 아니다. 즉 Classification에서 Class간 불균형 데이터에서는 ACC만을 올리는것이 좋은모델은 아니다. ### 예시2: Multi-class classification 영화리뷰 감성분류를 한다고 해보자. - positive: 70% - Neutral: 20% - Negative: 10% Positive의 학습데이터가 많으므로 당연히 모델을 돌렸을떄 positive는 잘 맞히지만, Neutral과 Negative를 Positive로 많이 오분류 한다. ## Macro-F1 vs Micro-F1  일단 F1은 정밀도와 재현율의 조화평균으로 정밀도와 재현도룰 둘다 반영한 Metric이다. - **Micro-F1:** 전체 클래스의 TP/FP/FN을 한 번에 합산해 Precision·Recall을 계산 → 샘플 수가 많은(다수) 클래스의 영향이 크다. 따라서 불균형 데이터에서는 Micro-F1이 높더라도 모델의 성능이 안좋을 수 있다. - **Macro-F1:** 클래스별 F1을 구해 단순 평균 → 각 클래스를 동일 가중으로 취급하므로 소수 클래스 성능 저하를 잘 드러냄. - 클래스별로 F1값을 따로 계산하고, 각 클래스를 동일 가중으로 취급하여 평균내므로, 어떤 클래스의 데이터가 매우 적더라도, 최종 F1값에 잘 반영될 수 있음. - **Weighted-F1**: 클래스별 F1에 **표본 비율 가중치**를 곱해 평균 → Micro와 Macro의 중간 성격. ## Loss를 통한 Metric 개선 일반적은 Cross Entropy Loss는 모든 클래스의 오류를 동일하게 취급한다. 따라서 어떤 클래스의 데이터만이 매우 큰 비중을 차지하면 학습과정에서 다수 클래스에 치우쳐서 소수클래스의 Loss는 거의 무시된다. ### Class Weighted Cross Entropy 데이터가 적게 나오는 클래스일 수록 Loss 계산시 더 큰 가중치를 부여한다. 만약에 어떤 클래스의 데이터가 10%이고 다른 클래스의 데이터가 70%면 어떤 클래스의 Loss를 7배 가중치를 줘서 계산한다. 즉 각 클래스의 표본개수 비율을 반대로 뒤집어서 가중치로 사용한다. 이를 통해 모델이 소수 클래스도 무시하지 않고 학습하도록 유도한다.  이미지출처: [https://stages.ai/en/competitions/370/board/community/post/3051](https://stages.ai/en/competitions/370/board/community/post/3051) ### Focal Loss 모델이 이미 쉽게 맞히는 샘플보다는, 계속 틀리는 어려운 샘플에 더 집중하도록 Lossfunction 자체를 조정한다. 즉 클래스별로 맞히기 어려운 샘플일수록 Loss 비중을 높인다. $$\gamma$$에 따라 Loss Function의 형태 자체가 달라짐을 볼 수 있다. $$\gamma$$가 0에 가까울수록 예측확률이 낮을때, 즉 확신이 없을때의 Loss가 매우 커서, 학습이 더 강하게 일어남을 확인할 수 있다.   이미지출처: [https://stages.ai/en/competitions/370/board/community/post/3051](https://stages.ai/en/competitions/370/board/community/post/3051) # Living Point - 메트릭 선택은 우선 데이터에 대한 이해를 기반한다. 데이터가 불균형 데이터인지, 소수클래스에대한 판별을 더 민감하게 반응해야하는지 등을 우선 먼저 파악하고, 무엇을 위해 모델을 학습하는지에 따라 Metric을 선택해야 한다. - 메트릭과 Loss function의 일관성도 중요하다. Loss를 줄이는 방향이 실제로 Metric을 올리는 방향과 일치해야 한다. 이를 위해 Class-weighted Cross Entropy나 Focal Loss같은 방법을 사용할 수 있다. ## Study ### 우리 아이가 달라졌어요: 텍스트에 워터마크를 어떻게 넣을까 - Canonical URL: https://hyejunl33.github.io/study/2026-10-07-text-watermark-kgw-synthid-textgrain/ - Collection: Study - Published: 2026-10-07 - Tags: Study 이 글은 DEVOCEAN에도 게재되었습니다. [DEVOCEAN에서 읽기](https://devocean.sk.com/blog/techBoardDetail.do?id=168550&isShared=Y) ## 우리 아이가 달라졌어요: PRD 에이전트가 이상한말을 해요. 뤼튼에서 인턴으로 일하던 올해 여름, 같은 IAB중 PM들이 사용할 PRD Generator Agent를 만드는 동료 인턴이 있었다. 8월쯤 PM분들이 에이전트 성능이 이상하다는 이야기를 들었다. 심지어 클로드가 이상한말을 해서 직접 타자를 쳐서 PRD를 작성까지한다고 들었다..!(AI없이, 26년 8월에..?) Claude Fable API 출력에 텍스트 워터마크가 들어가기 시작한 뒤 단어 선택이 눈에 띄게 어색해졌고, PM들이 결국 Agent에서 Fable 대신 gemini나, GPT계열 모델들을 쓰게 됐다는 내용이었다. 아니 근데 어떻게 text에 워터마크를 넣나? 궁금했다. 이미지는 픽셀값을 미세하게 변형하거나 메타데이터에 워터마크를 박는게 쉬울텐데.. 먼저 PM들이 작성하는 PRD는 누가 읽어도 요구사항을 같은 뜻으로 이해해야 하는 문서다. 문장은 얼핏 그럴듯한데 단어가 어색하면, 읽는 사람이 의도를 다시 해석해야 한다. 문서 작성을 도와주는 Agent가 오히려 문장을 고치는 일을 늘린다면 사용하는 입장에서는 모델을 바꿀 이유가 충분하다. ## 텍스트에 흔적을 남긴다는 건 최근 내가 자주보는 유튜버인 임커밋님의 [「텍스트 워터마크..? 어떻게?」](https://www.youtube.com/watch?v=8CV9GHclD0c)도 참고했다. 다음 단어를 고르는 과정에 어떻게 흔적을 남길 수 있는지 이해하는 데 도움이 됐다.