| description |
|---|
2024년 12월 18일 |
.png)
제 7회 Kakao Tech Meetup
짜잔! 작년 6회 Kakao Meetup에는 아쉽게도 선발되지 않아 참가할 수 없었지만 이번에는 더욱 더 큰 기대감을 안고 다행히 당선되었다! 사실 if Kakao 2024에 가장 기대하던 영상이 있어서 그 세션에 대한 추가적인 내용을 들을 수 있을까 했는데 아쉽게도 해당 세션은 존재하지 않았다.. (흡,,ㅜ 아쉽지만,, 링크를 남긴다.)
1등으로 도착!!
퇴근하고 판교까지 가야해서 서두르다보니 1등으로 도착해버렸다.. 와우,, 이렇게 빨리올줄은 몰랐다..
6시반이 되어 본격적으로 시작한 MeetUp! 각 세션을 들으며 간단히 필기한 내용을 아래 공유한다.
# *1. AI Agent 기반 스마트 AI 마이노트*
과거에도 연말평가의 자동화시도가 존재함.
- Jira, Slack같은 tool을 활용함과 동시에 KPI 같은 기준을 결합하여 시도
- But, 모든 상황과 현상에 대한 예외케이스 처리할 수 없었음.
사용자를 위한 AI Agent 서비스?
- 대부분은 Chat Interface
- 앞으로의 방향성이 알잘딱갈센
주요기능 1. 성과 노트 작성
- 데이터 소스의 다양성
- 맥락 파악
- 회사 평가기준 반영
주요기능 2. 성과 평가 초안 작성
- AAT, SBI 피드백
- 개발 과정에서의 어려움
Data Preprocessing
Prompt Engineering
- 요약데이터, 원본데이터, 구조화 변경 (매우 중요하며 수많은 시행착오가 존재함)
- 실제 적용시 고려해야할 리스크
- AI 윤리 원칙
- AI 편향성
- 개인 정보 보호
- 노동법 고용 규정
- 다양한 업무 관리 방식
- 비용 관리
# *2. TDD로 앞서가는 프론트엔드 : 디자인, API 없이도 개발을 시작하는 방법*
웹서비스의 병목지점에 있는 FE의 부하를 어떻게 줄일 수 있는지 항상 고민
"아직 FE 개발이 진행 중입니다." -> 흔한 개발 지연 사유
그 이유는�타 협업자의 단계가 수행된 이후에야 작업할 수 있음.
"굳이 다른 협업자의 작업을 기다리지 않고 작업할 수는 없나?"
- 기획서를 보고 일정산정
- PoC 및 기술검증
- 기술스택 논의
- 페이즈에 따른 개발 환경 논의
- 배포방식 논의
- 개발 인프라 세팅
- 공통 컴포넌트 및 유틸 개발
문제 해결의 키워드
-> Component & Test(단위)
일반적인 FE 개발 플로우에서 벗어나 화면이 아닌 테스트를 보고 개발 할 수 있다면 생산성이 올라갈 것.
# *3. 업무 효율화를 위한 카카오 사내봇 개발기*
Introduction
- 많은서비스에 따라 서로다른 형태의 테이블 구조
- 타 서비스에 대한 데이터 분석이 어려움.
0뎁스 데이터봇
- RAG 구조 채용
- 많은 데이터변경으로 인해 RAG를 사용
Process
- table에 대한 description이 혼재함.
- Document 생성 프로셋스
- 수집, 가공, 생성, 검수(사람)
- Retriever
- 테이블 명을 정확히 검색했음에도 낮은 스코어로 검색됨.
- 칼럼 명을 정확히 검색했음에도 테이블을 찾지 못함.
- 원인 분석
- Document에 담겨있는 정보가 많아서 유사도가 희석됨.
- 즉, 데이터 특징에 따라 분리해서 Pool을 생성
- 서비스 이름
- 테이블 이름
- 테이블 설명
- 테이블 칼럼
- LLM
- 적절한 문서만 뽑는것이 관건
- 목표에 fit한 내용을 반영하는 것이 관건
- 범용성 필요없음
- 사내용어 학습 필요
- 7B 이하 모델 학습
- 학습 데이터셋 직접 구축
- LIMA 참조
- 정답 테이블의 랭크비율을 비슷하게 유지?
- 질문의도에 맞는 답변을 생성하지 못하는 issue 발생
- 즉, Task별 전문모델 개발
- 이때, RAFT 사용
- Multi-LoRA Adapter를 베이스모델에 붙여 서비스 앞단에 쿼리 유형에 따라 선택하게 함.
- History
- history유형을 분리하여 2가지로 구분
- 새로운 맥락 질의
- 히스토리 삭제
- 이어지는 질의
- 앞선 대화를 히스토리로 사용
Conclusion
- Garbage in Garbage out
- Query 유형에 따라 개별 Pool을 구축
- LLM은 비용싸움, Task별 전문 모델 선호
- 히스토리 관리가 필수적
# *QnA*
검색 플로우에서 Lexical, Semantic Search시 3개의 Pool에 대해 각각 top 3의 결과를 검색하고 Scoring을 통해 그 중에서 top 3를 뽑아 최종적인 검색결과로 활용하신것인지 궁금하며 이때, Scoring을 어떤방식으로 하셨는지 궁금합니다.
- 각각의 pool에서 결과를 가져오는 것은 맞으며 Scoring은 각 Pool에 따라 다른 Weight를 주고 종합하였다.
"업무 효율화를 위한 카카오 사내봇 개발기"에 관해 궁금한 점이 있습니다. 성능평가를 위한 평가셋을 약 200개 QA를 사용하셨다고 자료에 기재되어있는데, 이때 평가셋 구축과정이 궁금합니다.
- 처음에는 LLM으로 시도, 근데 학습 셋이랑 비슷하게 나와서 pending. 내부적으로 demo page를 만들고 그 사람들이 직접 사용한 log를 수집해서 gt를 만들었다.
"업무 효율화를 위한 카카오 사내봇 개발기" 아키텍쳐에 따르면 사용자 쿼리 유형이 특정된 환경에서 유효한 구조로 보여지는데, 전사확대를 진행하신다고 하신 경우 쿼리유형이 많이 늘어날 것이라고 생각이 듭니다. 그때마다 하나하나 정해놓기도 많은 소요가 있을 것 같은데 사용자 쿼리 유형에 구애받지 않은 인사이트가 있으실까요?
사내봇 개발 시 멀티턴에서 새로운 질의인지 이어지는 질문인지 어떻게 판단하나요?
- Generation 모델이 판단한다..? 아무래도 Routing을 LLM으로 하는듯.
AI Agent 플랫폼 개발 세션과 관련하여, 실제 서비스 운영 시 발생할 수 있는 hallucination(환각) 문제를 어떻게 해결하셨는지 궁금합니다.
- semantic entropy와 같은 지표를 활용할 수 있지만, 사실 나오는 결과를 보고 환각여부를 정하는 것을 선호한다.
초반 질문중 Router를 Generation 모델로 판단한다고 하셨는데, LLM을 사용하여 Routing을 한다는 것으로 이해했습니다. 만약 맞다면 Routing만을 위한 학습을 따로 진행하시는지, 아니면 Prompt Engineering으로 진행하는지 궁금합니다.
- 선정 안됨ㅜㅜ
이 제품을 LLM 으로 구현한 Data Catalogue 라고 이해해도 될까요? 만약 그렇다면, 각 팀의 문서 관리 상태에 따라 테이블들의 퀄리티가 현저하게 다를 것 같아서, 전체적인 퀄리티를 어떻게 상향 평준화 할 계획인지 궁금합니다
- 상향평준화는 어렵다. 데이터 퀄리티를 결정하는게 아닌, 잘 이쁘게 전처리하는 (몇단계의 전처리 step을 활용했다고 함.)
작은 모델들을 파인튜닝 하는 것보다 LLM을 활용하는 것이 더 좋은 성능을 내는 것으로 보입니다. 최근에는 랭킹을 매기거나 특정 형식으로 출력하는 것 또한 LLM으로 수행했을 때 더 정확하다고 하는데, 이 LLM이 도출한 결과가 정말 더 정확한지 신뢰할만한 값으로 볼 수 있을지 궁금합니다.
- 1 ~ 7B 짜리 모델을 이용해서 task specific하게 진행개인적으로 너무나 알차고 재미난 시간이었다. 아참, 위에 Router에 관한 질문은 선정되지 않아 부끄러움을 무릅쓰고 따로 연사자분들께 다가가 여쭤보았더니 너무나 친절하게 잘 설명해주셨다. LLM을 활용하고 Prompt Engineering으로 진행하셨다고 하는데, 사용하고자 하는 상황이 굉장히 명확해서 충분한 효율을 보였다고 하셨다. (tory, jennie님 감사합니다 😍) 필자의 경우 RAG에 매우 큰 관심을 가지고 있기에 3번째 Session이었던 "업무 효율화를 위한 카카오 사내봇 개발기"에 큰 중점을 두었다. 덕분에 다양한 아이디어와 카카오에서 시도한 인사이트들을 얻을 수 있었고 좋은 경험이 된 것 같다. 해당 세션에 대한 내용은 RESEARCH ARTICLE에 따로 정리하겠다.