장소: 4F 401호 (코엑스)
시간: 11:10 ~ 11:50
강연 선택 이유: 누구나 이용해봤을 스타벅스이기 때문에 친숙했고 실제로 인공지능을 접목한 서비스가 체감될 것으로 기대하고 참석하게 되었다.
강연자: 이승민 AWS, 이환기 스타벅스 코리아, 백준선, AWS
강연 내용: 내부 직원용 챗봇 개발한 사례
AWS 생성형 AI 생태계
생성형 AI를 통한 도전을 하기위한 여정을 소개하였다.
도전 과제로는 다음과같은 3가지가 있다.
- 신뢰성 문제
- 환각
- 기술적 문제
- 많은 리소스가 필요함
- 윤리적 문제
생성형 AI를 활용하기위한 AWS 서비스들을 소개하였다.
챗봇의 주요 구성요소를 소개하였다.
그 중에 가장 결정적인 요소는 평가 파이프라인이다.
사람이 평가하게되면 시간이나 비용이 많이 들어가기 때문에 평가 파이프라인을 기반으로 객관적으로 의사결정 하는 것이 중요하였다.
인덱스 파이프라인
원본 문서를 검색이 잘되게 하기 위해서 텍스트를 추출하고 메타데이터를 주입하고 문서를 특정 길이로 자려서 embedding 모델에 넣어서 벡터를 추출하게 되는데 이때 람다를 활용해서 병렬처리를 하였다.
검색 증강
환각을 일으키지 않게 검색결과와 함께 질의를 합쳐서 구성하였다. 실제로 체감도가 높았다
프롬프트 엔지니어링
프롬프트 엔지니어링이 가성비가 좋은 방법이라고 체감하였다고 한다.
하나의 프롬프트에서 나완 결과를 다음 프롬프트에 프롬프트 체인 기업을 사용하였다.
사용자의 검색을 최적화하기위해
평가 파이프라인
가상 데이터를 가지고 설명하셨다.
많은 조합을 활용해서 개선하였다.
1000-e5 1000 titan은 잘린 문서 텍스트 크기를 의미한다.
검색엔진이 돌려주는 갯수 k값이라던지 맥시컬(키워드 기반의 검색) 벡터기반의 결과를 몇대 몇으로 6대4 등으로 비율을 두어서 가장 성과가 좋은 조합을 운영환경에 적용하였다.
RAG 라그스를 활용하였다.
어플리케이션 스택 소개
사내 인증시스템과 통함을 위해 자바스크립트를 활용하였고 그중에서 인기가많은 React.js를 활용하였다.
스타벅스는 쿠버네티스에 대한 숙련도가 놓었고 그래서 EKS위에 올려서 서비스를 하였다. 피크타임에 확장성이 좋았다.
데이터베이스도 확장성을 고려하여 다이나모DB를 구성하였다.
스타벅스의 디지털 혁신 여정
스타벅스의 현재, 과거에 어떻게 성장하였고 사랑받았는지에 대해서 설명하였다.
그끝에 최신에 사이렌 포탈을 중점적으로 이야기하려고한다.
고객이 많거나 음료가 많이 버려진 상태에서 알람 기능을 활용해 직원이 모니터링하기 편하게 개발중이다.
판매량을 예측하여 미리 준비할 수 있게 도움을 받고있다.
파트너들의 다양한 질문들
반복적인 질문에 대한 반복적인 대응이 필요했다.
데이터를 모아서 해당 문서를 기반으로 답변을 해주는 (정확히는 어떤 문서에 있는지 문서를 찾아주는 서비스였다.) 이후 시나리오가 복잡해지고 확장성이 떨어지는 문제가 존재하였다.
RAG엔진을 통해서 스타벽스에 초점이 되어있는 챗봇을 만들 수 있었다.
크게 2가지 스텝이 있다.
1. 스타벅스 정보들을 토대로 정보를 추출
2. 답변을 구성
할루시네이션에 대한 통제가 관건이었다.
gen AI 체인을 활용하였고 문서를 찾을지 데이터베이스를 찾을지 등등을 gen AI 체인을 구성해서 총 4개를 구성하였다.
반응형으로 구성하였고 자세한 예시는 사진으로 대체
평가에 대한 지침이 필요했다. 그러면서도 사람이 평가할 수는 없었다
그래서 이를 위해 별도의 Gen AI를 구성하였다.
1. 프롬프트 (what)
2. Chain of Thought (How)
3. Form filling (질문과 답변을 넘겨서 채점을 진행한)
GenAI가 어디로 튈지 모르겠다는 문제, 여기서는 되는데 여기서는 안되는 답변을 주는 것에 대해서 앵커데이터를 통해 일관성과 퀄리티를 높이게 되었다.
실제로 반응이 좋았다고 한다.
점심메뉴 추천을 처음에는 많이 질문했는데 지금은 잘 질문하고 있고 95%정도는 잘 답변하고 있다.
RAG를 활용하면 반응속도가 좀 느리긴하다. 그래서 리전, 스트링기반 답변, 프롬프트 엔지니어링, 토큰 최적화를 통해 반응속도를 개선하였다.
인풋데이터에 대한 정제가 필요하다.
질문을 했는데 답변이 잘 안되면 실제로 문서 업데이트를 하는 상황이 되었다.
정보의 제공방식이 바뀌니까 정보의 생산방식이 바뀌더라 라는 인사이트를 얻었다.
사이렌 포탈 프로젝트 소개
주요 요구사항
1. 응답성능: 10초안에
2. 인덱싱 파이프라인
3. 도메인 지식 기반 RAG: 용어 단어 축약어, 스타벅스에서만 쓰는 단어가 많았다.
4. 운영: 챗봇의 환각증상을 제어했어야했다.
응답성능
Chain과 Agent방식중에 고민을 많이 하였다.
Chain방식은 주어진 조건에 따라 순차적으로 수행되는 방식
Agent방식은 일반화된 확장가능한 AI를 활용하는 방식 AI에 대해서 자율성을 부과하는 방식
이 중에서 가장 중요한 요구사항이었던 유저에게 10초안에 답변을 주도록 하기 위해 Chain 방식을 선택하였다.
시스템에 질의가 왔을 때 질의는 조건분기 체인을 먼저 타게 된다.
각각의 체인에 원하는 목적에 따른 세부선택이 가능했다. AW 서비스가 다앙해서라고 하였다.
Bedrock으로 꾸준한 학습을 통해 응답 개선
인덱스 파이프라인
문서의 추출, 인덱스 작업은 람다에서 구성해서
동시성과 가시성을 확보하여 파이프라인 구조를 확보하였다.
문서를 청크단위로 나누고 청크를 단어들의 묶음으로 Embedding으로 바꾸어서 Indexing이 가능하게 변환하는 작업이 진행되었다.
사람마다 표를 작성하는 방식이 다 달랐기 때문에 표를 어떻게하면 정형화된 방식으로 바꿀지가 중요한 부분이었다. 큰 표를 나누어서 인덱싱가능하게 바꾸게 되었다.
도메인 지식 기반 RAG
환각증상을 줄이는데 노력하였다.
LLM이 본인의 생각을 억누르고 검색기반으로, 유저와 문서 사이의 인터페이스 역할만을 하도록 제어하였다.
