Cover image

도메인 특화 임베딩 모델 만들기: RAG 성능 개선을 위한 가이드

한 줄 요약 — 일반적인 임베딩 모델이 해결하지 못하는 도메인 특화 지식을 단 하루 만의 파인튜닝(Fine-tuning)으로 최적화하여 RAG 시스템의 검색 성능을 극대화하는 방법론을 다룹니다. 이 주제를 꺼낸 이유 검색 증강 생성(Retrieval-Augmented Generation, RAG) 시스템을 구축하다 보면 반드시 마주치는 벽이 있습니다. 범용 임베딩(Embedding) 모델은 인터넷의 방대한 데이터는 잘 이해하지만, 우리 회사의 내부 계약서, 제조 공정 로그, 독자적인 화학식이나 고유 명사는 제대로 처리하지 못한다는 점입니다. 단순히 상위 모델을 쓴다고 해결될 문제가 아닙니다. 도메인 특화 용어 사이의 미세한 맥락 차이를 구분하지 못하면 검색 단계에서 엉뚱한 문서를 가져오고, 이는 곧 생성된 답변의 품질 저하로 이어집니다. ...

March 31, 2026 · 4 min · 764 words · gnosyslambda

넷플릭스는 어떻게 LLM을 자사 서비스에 맞게 길들이는가

왜 지금 이게 문제인가 “GPT-4를 그냥 API로 쓰면 되지 않나?” 많은 기업이 이 질문에서 출발하지만, 넷플릭스는 다른 답을 내렸다. 범용 LLM은 넷플릭스의 콘텐츠 카탈로그, 추천 알고리즘, 사용자 행동 패턴을 모른다. “이 영화가 한국 30대 남성에게 왜 매력적인가"를 GPT-4에게 물어봐야 일반론만 돌아온다. 넷플릭스 AI 플랫폼 팀은 범용 모델을 가져다가 자사 데이터로 **Post-Training(사후 학습)**하는 내부 프레임워크를 구축했다. 이는 단순한 파인튜닝을 넘어, 프로덕션에서 추천·검색·개인화에 직접 투입되는 모델을 대규모로 생산하는 LLM 공장이다. API 의존의 한계: 외부 LLM API는 자사 데이터로 학습되지 않았고, 모델 업데이트 시점을 통제할 수 없으며, 민감한 사용자 데이터를 외부로 보내야 한다. 넷플릭스 규모에서 이 세 가지는 모두 수용 불가능하다. 파인튜닝의 인프라 복잡성: 수십~수백 대의 GPU 노드에서 분산 학습을 돌리는 것은 모델 코드를 짜는 것보다 10배 어렵다. 노드 하나가 죽으면 수일간의 학습이 날아가고, 체크포인팅은 네트워크 대역폭을 잡아먹으며, GPU 메모리 관리는 악몽이다. 한국적 맥락: 쿠팡, 토스, 카카오 같은 데이터 기반 서비스가 “우리만의 LLM을 만들어야 하나"를 고민 중이다. 넷플릭스의 사례는 Pre-training(처음부터 학습)이 아닌 Post-Training(기존 모델 위에 학습)이라는 현실적 경로를 보여준다. 어떻게 동작하는가 넷플릭스의 Post-Training Framework는 세 개의 레이어로 구성된다. ...

February 19, 2026 · 4 min · 830 words · gnosyslambda