문과지만 괜찮아

구현 동기프로젝트의 기획자의 입장에서의 기획안 평가와 유해성 검사를 구현했듯이 반대로 크리에이터에 대한 평가도 필요하다고 생각했다. 구현과정

기획안을 평가하고 요약하는 기능을 프로젝트를 위해 구현하기 전 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에서 이 방식을 추천하나 절대로 장담하지 못한다는 사실이다...

이전 포스트에서 TPM 문제에 대한 해결책을 실제로 구현해 보고 비교해 봤다. 먼저 Vector Store를 개선해보려고 한다.Vector Store 생성 파트사용 토큰 수 조정Batch 적용Embedding Model 변경Query Translation & Generation 파트Tenacity 혹은 Backoff 적용 문제 개선에 대한 동기와 그 선정과정이 궁금하다면 아래의 링크로 가면 된다.Project HowAbout RAG API - Outro: Optimization - TPM 문제 정의  사용 토큰 수 조정먼저 토큰이 정확히 얼마나 어디서 쓰이는지 확인하기 위해 진행했다. 그래서 먼저 tiktoken을 활용해서 사용되는 토큰의 규모를 파악했다. 또한 기본적으로 시도할 수 있는 부분이 적절한 ..

개선 동기현재 프로젝트를 위해 만든 RAG API의 경우 Retrieval과정에서 들어오는 Query에 대한 Embedding과 Multiple Query Generation 생성과정에서도 외부 Model API를 사용한다.(OpenAI API: text-embedding-3-large & gpt-4o) 그렇다 보니 TPM이라는 에러가 발생할 요소가 있었다. 또한 Vector Store를 만드는 과정이었던 Data Ingestion 파트에서도 일정 수준의 데이터가 들어가면 바로 TPM 문제가 발생할 가능성이 다분했었다. 물론 발생하기 전까지는 그런 문제가 전형 없다고 생각했으나 되려 발생해서 다행이라고 생각했다. 그래서 추후 외부 Model API를 사용할 수 있는 상황을 대비하여 구현된 프로젝트에서 개..

Project:HowAbout - Intro에 구현하기로 한 기능을 다 구현하지는 못했으나 4주간의  MVP를 달성했다. 그리고 이 포스트는 4주간의 과정에 대한 회고다. 먼저 처음에 예상했던 구성 사용하기로 한 기술스택들과 실제로 만들어지고 사용된 내용에 대해서 확인해 보자. 프로젝트 구현 전 예상 Software Architecture 예상 기술스택PlatformHuggingfaceFramework: RAGLangChainFramework: APIFastAPIEmbedding ModelKoBart, KcBert, KoBertVector DBFaiss, Chroma, PineconeLLMchatGPT 3.5 Turbo 프로젝트 구현 후 실제로 만들어진 Software Architecture 실제로 사용..

RAG 구현 Step-by-Step: Intro가상환경 설정 및 MVP 구현Dataset과 Vector DB 구현Dataset 확보Vector DB 구현Embedding & Searching 구현Generation  구현 및 API 전환드디어 RAG 구현의 마지막 부분인 Generation과 API 전환 단계로 넘어왔다. Retrieval 파트 구현에 대한 시간 투자로 인해서 이번 포스트에는 간단히 구현동기, 구현과정 그리고 문제상황에 대해서만 간단히 정리해 봤다. 먼저 Generation을 구체화한 부분에 대한 구현동기는 아래와 같다.구현동기챗봇이 아닌 API 요청으로 작동하기 때문에 클라이언트로 반환해야 하는 응답이 일정해야 한다. 특히, 클라이언트로의 응답을 json으로 Restful api를 만들..

RAG 구현 Step-by-Step: Intro가상환경 설정 및 MVP 구현Dataset과 Vector DB 구현Dataset 확보Vector DB 구현Embedding & Searching 구현Generation  구현위의 그림은 LangChain에서 RAG를 필요에 맞춰 수정할 수 있는 부분을 도식화한 그림이다. 위의 그림과 같이 단순히 RAG는 조회와 조회된 결과를 바탕으로 생성하는 간단한 구성이 아니었다. 조회와 생성 그리고 데이터 확보 부분 또한 기획한 서비스 의도에 맞춰 다양하게 변형할 수 있었다.  그래서 이번 Embedding & Searching에서는 Query에 대한 Embedding을 진행하고 그다음 가장 유사한 Vector들을 찾는 유사도 방식에 추가적으로 Query에 대한 분석과 ..