문과지만 괜찮아

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

이번 포스트에서는 콘티 생성기에 사용될 모델에 대한 선정과정을 정리해 봤다. 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를 서비스 서버에 설치해야 하고 용량이 너무 커서 로직을 변경해야만 하..

기획안을 평가하고 요약하는 기능을 프로젝트를 위해 구현하기 전 Evaluation Bot에 대한 MVP를 정의하고 아래와 같이 구현했습니다.  먼저 기획의도에 맞게 아래의 내용들을 MVP에 선정하였습니다.1차 평가: 정량평가2차 평가: 내용평가3차 평가: 영상 심의 평가그리고 추가적으로 이번 구현과 추후 프로젝트 진행에 있어 핵심인 좋은 기획안과 나쁜 기획안 데이터를 확보했습니다. 먼저 Evaluation Bot의 각 평가에 대한 구현 동기와 과정은 아래와 같습니다.구현 동기1차 평가: 먼저 프로젝트 핵심 목표로써 기존의 서비스에서의 효율적이 AI 사용기준이 존재해야 한다고 판단했습니다. 그래서 간단한 수치적인 평가를 통해 2,3차 평가에서의 AI 사용에 대한 기준점으로 삼게 됐습니다. 2차 평가: 현재..

Project Joing: Intro에서 언급했듯이 이번에는 기능별 도메인에 따른 구체적인 개발 계획에 대해 정리했습니다.기획안 평가 및 요약기획자가 작성한 기획안에 대한 평가를 통해 평가통과한 기획안의 경우 요약을 진행요약이 완료된 시점 부터 추천 대상으로 전환Evaluation Bot(aka. Clean Bot)역할 및 기능기획안의 내용과 구성을 바탕으로 평가한다. 총 3차의 평가를 진행하며 기획안이 최초 생성혹은 기획안이 수정 됐을 때 작동한다.총 3차로 나눈 이유는 각 평가별로 기획자에게 주어지는 피드백이 다르기 때문에 나누게 됐다. 1차 평가: 정량평가2차 평가: 내용평가3차 평가: 영상 심의 평가구체적인 사용 예시기획안 생성 및 수정 직후 총 3가지의 평가가 진행된다.1차 평가: 양 → 양이 ..

Joing은전문적인 기획자 혹은 아이디어만 있는 초보 기획자를 위한 메칭 플랫폼입니다. 또한 트렌드를 바탕으로 만들어진 새로운 아이디어를 찾고 있는 크리에이터를 위한 메칭 플랫폼입니다.  Joing은 메칭 플랫폼으로써 기획자와 크리에이터를 연결하고 소통할 수 있는 공간입니다. 또한 AI를 적극적으로 도입하여 더 원활한 메칭이 가능하도록 만들어진 플랫폼입니다. 그래서 기본적으로 Joing이라는 플랫폼은 아래와 같은 기획자와 크리에이터 유저 플로우를 가지고 있습니다. 기획자자신의 아이디어를 바탕으로 영상 기획안을 작성할 수 있다.작성된 기획안에 어울리는 크리에이터에 대한 추천을 받을 수 있다.추천 크리에이터에게 자신의 기획안을 제안할 수 있다.크리에이터자신의 프로필을 등록할 수 있다.자신의 프로필을 바탕으로..

Vector Store에서의 TPM 문제 개선에 이어 이번에는 Generation과 Query Translation파트에서의 개선을 진행해 봤다.Vector Store 생성 파트사용 토큰 수 지정Batch API 사용Embedding Model 변경Query Translation & Generation 파트Tenacity 혹은 Backoff 적용 문제 개선에 대한 동기와 그 선정과정이 궁금하다면 아래의 링크로 가면 된다.Project HowAbout RAG API - Outro: Optimization - TPM 문제 정의 실시간 응답이 필요한 경우 Tenacity나 Backoff를 사용해야 한다. 하지만 여기서 중요한 부분이 있는데 OpenAI에서 이 방식을 추천하나 절대로 장담하지 못한다는 사실이다...