문과지만 괜찮아

*주의!* 작년에 정리하지 못했던 Project Joing의 문서입니다. 포스팅은 아래의 순서로 진행될 예정입니다.이미지 생성 모델 선정 3 - Flux.1 Schnell vs Flux.1 DevFlux.1 Dev Fine-tuning: LoRa & PEFTFlux.1 Dev Fine-tuning: AI-ToolkitFlux.1 Dev Fine-tuning: 학습데이터 수집Flux.1 Dev Fine-tuning: 학습 및 결과 비교마무리 및 회고 작년(2024년)에 '이미지 생성 모델 선정 2'를 작성한 내 자신에게 소리치고 싶다. '야 그거 아니야!!!' 문제상황 1: Flux.1 Schnell의 특징Flux.1 Schnell을 사용하기로한 결정적인 이유 'GPU를 상대적으로 적게 사용하고', '생성..

이전의 포스트에 이어 이번에는 모델 선정의 결과와 선정 배경에 대해 정리했다. 먼저 모델 선정 결과는 'Flux.dev'이다.(schnell의 경우 비용 문제와 용량 문제로 인해 불가능하다.) 먼저 선정에 있어 아래의 내용들을 먼저 각 모델별로 테스트해 봤다. 구체적인 Prompt를 구성한 뒤 생성Prompt 변경에 따른 생성 차이 비교Prompt에 대한 이해도 및 세부적인 지시 사항 이행여부 판단연속생성 및 리소스 네개의 이미지를 순차적으로 생성하기에 그 시간 또한 중요하다리소스가 얼마나 사용되는지는 리소스가 제한적인 상황에서 가장 중요한 부분이라고 할 수 있다. Prompt의 경우 추후에도 신경 써야 하는 부분이기 때문에 프로젝트 생성을 위해 기본적인 구조 구성을 감안하여 진행하였다. PromptPr..

이번 포스트에서는 콘티 생성기에 사용될 모델에 대한 선정과정을 정리해 봤다. Diffusion Model에 대해서는 추가적으로 '도대체 Diffusion Model은 뭘까?'에서 설명할 예정이다. 먼저 현재 가장 많이 쓰이고 있는 모델들을 추려냈다. 처음 사용하다 보니 사용경험들이나 관련 정보가 많아야 한다는 게 첫 번째 기준이었다.  그래서 추려낸 모댈은 Stable Diffusion(이하 SDXL)과 Flux다. 선정기준은 아래와 같았다.콘티를 생성해야하니 스케치의 특징인 핵심 표현 가능 여부역으로 말하자면 쓸데 없이 디테일한 생성은 필요가 없다.비용, 물론 현재 로컬에서 클라우드 저장소로 업데이트를 하는 로직을 구상했으나 중요한 점은 로컬에서도 벅차서는 안된다.현재 사용하고 있는 로컬환경은 Cola..

현재까지 구현한 기능들은 단순하다. 공통적인 로직은 아래와 같다.요청이 들어온다.요청에 대한 평가를 진행한다.텍스트를 평가한다.이미지로 평가한다.평가 결과를 생성한다.그리고 모든 평가 기준들이 Prompt로 들어가 있기 때문에 특별한 기술이 들어가 있는 상태는 아니다.  그렇기 때문에 새로운 나의 개발 능력을 어필할 수 있는 새로운 기능에 대해 고민해봤고 Project Joing이 기획자와 크리에이터를 매칭해 주는 플랫폼이라는 사실을 바탕으로 기획자의 기획안을 시각화해 주는 기능에 대해 생각하게 됐다. 그래서 아래의 과정을 통해서 기획자의 기획안을 시각화해주는 콘티 생서기: Storyboard Generator를 만들기로 했다.  먼저 현재 기준으로 생각중인 작동 로직은 아래와 같다.작성된 기획안 중 콘..

이전의 RecSystem을 위한 데이터 수집의 경우 데이터를 Youtube Data API를 통해 가져온 뒤에 어떤 정보에 대한 수정 및 조작도 하지 않았다. 하지만 기획안의 경우에는 상황이 다르다. 그 어떤 곳에서도 기획안을 찾기가 힘들다.기획안이 있다 하더라도 우리의 서비스에서 진행하는 양식과 다르다.이 두 가지 이유 때문에 어쩔 수 없이 기획안의 경우에는 직접 생성해야 하는데 팀원들과 함께하기엔 팀원들에게 미안하고 직접 하기에는 양이 너무 많고 가장 중요한 점은 기획안의 퀄리티에 차이가 우려됐다. 그래서 위와 같은 문제를 해결하기 위해 어쩔 수 없이 LLM을 활용하여 기획안을 생성하기로 했다. 그래서 아래의 영상의 도움을 받아 기획안 생성 Workflow를 생성했다.노코드캣님의 Youtube 요약생..

일전의 포스트에서 말했듯이 두 가지 문제가 있었다.Selenium을 사용하기에 한 가지의 보조기능을 위해 너무 많은 클라우드 컴퓨팅 리소스가 Chrome Driver에서 사용된다.실제로 이미지 평가가 정확성을 떠나 작동하지 않는 경우가 있다.먼저 Youtube Data API를 활용하여 첫 번째 문제의 경우 확실히 해결을 했다. 그리고 두 번째 문제의 경우 Youtube Data API에서 Thumdnail과 동시에 조회해 올 수 있는 title과 description을 활용하여 text_evaluation을 추가하기로 했다. 그래서 아래와 같은 로직으로 FastAPI로 전환을 마무리했다. Youtube Data API로 최근에 업로드한 영상 4개 조회해당 영상들읠 Title, Description 그리..

현재 구현된 Profile Evaluation의 경우 아래와 같은 로직으로 작동한다.사용자(크리에이터)에게서 자신의 Youtube Channel URL을 받는다.사용자에게 건네받은 URL을 Selenium을 통해 스크린숏을 찍는다.우리가 Youtube Channel 처음들어갈때의 첫인상을 느끼는 것과 유사한 로직으로 구성했다.스크린숏은 LLM에게 전해지고 유해성 평가를 진행하게 된다.위와 같이 구현한 이유는 언급한 거와 같이 스크린숏이라는 방식이 우리가 느끼는 채널의 첫인상과 유사하다고 판단했기 때문이다.하지만 이를 위해서 Selenium이 필요 했고 추가적으로 Chrome Driver를 설치해야만 했다. 이는 Chrome Driver를 서비스 서버에 설치해야 하고 용량이 너무 커서 로직을 변경해야만 하..

프로젝트의 추천 시스템은 두종류의 추천을 진행한다.기획안 to 크리에이터크리에이터 to 기획안이 두 추천에 있어서 크리에이터에 대한 특징을 잡을 수 있는 정보가 지금 현재 필요하다. 그래서 아래의 로직 바탕으로 크리에이터(Youtube)에 대한 데이터를 수집하려고 한다. Youtube Handles 확보Handles를 Channel ID로 전환Channel ID로 Youtube Channel 정보 조회조회된 정보를 RecSystem 요구 조건에 맞춰 전처리Youtube Handles 확보먼저 Youtube Handles의 경우 대한민국 유튜버 분야별 구독자수 탑 200위까지를 기준으로 확보했고 총 확도한 Handle의 수는 7729개이다.  Handles를 Channel ID로 전환안타깝게도 Handle..

현재까지 Project Joing에서 구현된 기능은 간단하다.기획안과 Youtube 채널을 간단하게 평가하고 평가에 대한 이유와 해당하는 부분에 대한 피드백을 생성해 낸다. 그리고 이번 프로젝트에서작동 로직의 특별함 보다는 구현을 하게된 동기와 과정에 대해 좀 더 집중했다.  하지만 평가 말고도 추천 시스템이 현재 있고 또한 기획안에 대한 추가기능으로 인해 결국 데이터를 가져오고 가져온 데이터를 바탕으로 새로운 데이터를 만들기로 결정 했다. 그래서 먼저 Youtube Data AI를 통해 영상과 채널에 대한 데이터를 수집하고 수집한 데이터를 가공하여서 추천과 새로운 기능에 사용 할 수 있도록 이어 나갈 예정이다. 그리고 이와 더불어 저번처럼 Python 코드만으로 수집과정을 구성하는게 아닌 추가적으로 n..

벡터 유사도 검색 aka. Vector Similarity Search 서로 다른 두 벡터의 유사도가 얼마나 높은지 확인하고 가장 높은 유사도를 갖은 벡터부터 나열하여 검색을 진행한다.  기본적으로 벡터간의 비교를 하는것이기 때문에 우리가 예측하지 못하는 결과가 나올수 있고 특히 자연어나 객체를 Embedding을 하는 과정에 따라 차이가 발생할수 있다.  그리고 이와 같은 Vector간의 유사도를 직접적으로 볼 수 있는 웹사이트로 Embedding Projector라고 있다. Embedding Projector Embedding projector - visualization of high-dimensional dataVisualize high dimensional data.projector.tensor..