처음 이직을 하고 느꼈던 점은, 스프린트마다 50개가 넘는 유저스토리가 생기고,
이거에 대해서 나는 다 파악해야 하고, 예외케이스도 커버해야 하는데 언제 다하지? 였다.
물론 이에 대해서 각 담당자가 유저스토리를 파악하고, 서로 공유하기는 했지만 아무래도
기존에 있었던 user story 까지 파악하면서 새로운 유저스토리를 파악하는 것도,
그리고 수정되는 user story 를 실시간으로 파악하는 것도 리소스적 한계에 부딪히곤 했다.
그래서 예전부터 userstory 를 모아서 AI 를 만들자! 라는 막연한 생각을 갖고 있었는데,
이번에 QA conference 를 다녀오며 AI를 활용하여 QA를 진행하시는 분들이 많다는 것을 깨닫고
이를 계기로 조금 local AI 를 만들 수 있는 방법을 찾아보려고 시작하게 되었다.
RAG 를 사용한 LLM application 생성을 위해서는 3가지 배경지식이 필요하다.
RAG와 Vector Database와 Embedding Model 의 성능 비교이다.
RAG 은 LLM 개발에서 중요한 개념으로, Retrieval Augmented Generation (검색, 증강, 생성) 이다.
- retrieval : 언어모델이 가지고 있지 않은 정보를 제공하는 것.
- Augmented : retrieval된 데이터를 LLM에게 주면서, 알고있었던 것처럼 정보를 제공하는 것.
- Generation : 제공한 정보를 기반으로 알고있던 것처럼 정보를 제공.
여기서 답변을 생성하는 것은 LLM의 역할로, 우리는 데이터를 잘 가져와서 LLM에게 전달해줘야 한다.
그렇다면 데이터를 잘 가져오기 위해서는 잘 저장해야 하며, 잘 전달해야 한다.
특히 이 때 프롬프트를 잘 활용해야 하며, 문맥을 어떻게 제공할 것인가 또한 굉장히 중요하다.
특히 Langchain 을 활용하면 적절한 프롬프트를 제공해주므로 효율적으로 서비스를 운영할 수 있다.
두번째로 Vector Database 와 Embedding Model 을 이야기할 수 있다.
먼저 사용자의 질문에 대답할 때 사용되는 Data는 사용자가 원하는 정보일 가능성이 높다.
사용자의 질문과 Data 가 관련이 있음을 파악하기 위해 vector을 활용하는데,
vector는 단어 또는 문장의 유사도를 파악하여 관련성을 측정하는 기술로, vector생성을 위해서
문장에서 비슷한 단어가 자주 붙어있는 것을 학습하는 Embedding model 을 활용한다.
즉, Vector Database란 Embedding 모델을 활용해 생성된 데이터베이스를 의미하며,
Hallucination 을 방지하기 위해 단순 vector 뿐 아니라 metadata 도 같이 저장되어야 한다.
이후 Vector을 대상으로 유사도 검색을 실시하여 사용자 질문과 가장 비슷한 문서를 가져온다.
그러나 문서 전체를 활용하면 속도가 느리고 토큰수 초과로 답변 생성이 되지 않을 수 있으므로
문서를 chunking 을 통해 나눠서 저장하는 것이 무엇보다 중요하다.
※ embedding 모델의 경우, 한국말을 사용한다면 upstage embedding 이 좋은 편이다.