최근 10월 22일에 이프카카오라는 개발자 컨퍼런스를 다녀왔어요.(감사하게도 회사에서 보내줌..!) 생성형 AI가 보물처럼 쏟아지는 이 시기에 LLM의 현재 상황과 앞으로 미래에 어떻게 AI가 발전할 지, 그리고 카카오에서는 어떻게 AI 기술을 활용하고 있는지를 볼 수 있는 유익한 시간이었습니다. 더불어 카카오의 새로운 AI 서비스 카나나를 처음으로 공개한 날이어서 설레는 마음으로 다녀왔어요. 그 과정에서 기록한 것들을 공유하고자 합니다. 도움이 되었으면 좋겠습니다!

Keynote 세션

모든 연결을 새롭게

소개

정신아 카카오 대표이사는 생성형 AI의 급속한 발전을 바탕으로 94개의 세션을 준비했다고 밝혔습니다. 이 세션들은 주로 카카오에 적용되고 있는 AI 기술을 소개하며, 초개인화와 모델 오케스트레이션을 통해 사용자 경험을 극대화할 방안을 논의합니다.

Kanana에 관하여

카카오는 Kanana라는 초개인화 AI를 선보였습니다. Kanana는 사용자의 감정과 맥락을 이해하며, **AI 메이트 '나나'**를 통해 개인화된 경험을 제공합니다. 이 AI는 상황을 기억하고, 필요한 순간에 적절한 대응을 할 수 있도록 설계되었습니다. 연말에는 사내 테스트 버전을 시작으로 지속적인 발전을 예고했습니다.

카카오에서 진행한 AI 서비스

카카오는 여러 혁신적인 AI 서비스를 제공하고 있습니다:

안티어뷰징 시스템: 페이크 시그널을 이용해 유해 콘텐츠를 필터링합니다.
AI 커머스: 개인화된 선물 추천 기능이 곧 일반 사용자에게도 제공될 예정입니다.
음성 생성 AI: 사용자가 원하는 감정을 선택해 즉시 음성을 생성할 수 있는 기능을 지원합니다.
AI 보험 관리사: 금융 전문가 AI를 통한 MoE(Mixture of Expert) 서비스가 도입되었습니다.
자율주행 택시: 현재 판교에서 11대의 자율주행 택시가 운행 중이며, 내년에는 더 확대될 계획입니다.

AI 안전성 강화

AI의 안전성을 보장하기 위한 SafeGuard by Kanana 프레임워크를 개발하여, 부적절한 답변을 필터링하고 있습니다. 카카오는 생성형 AI 모델과 다양한 멀티모달 언어 모델을 준비하며, 모델 오케스트레이션 전략을 통해 AI의 효율성을 극대화하고자 합니다.

마지막 말씀

사람을 이해한다는 기술이라는 것은, 학습이 아니라 사용자의 눈높이에 맞춰 쉽게 해석되는 AI라고 생각합니다.

사용자에 맞춰 AI가 활용될 수 있다면, 대화하듯 쉽게, 가깝게 다가갈 수 있을 것입니다.

원하는 순간에 먼저 다가가주고 말을 걸어주며 소외되지 않도록 하는 서비스,

청소년 어린이들이 유해 콘텐츠에 노출되지 않도록 해주는 서비스.

이런 것들이 AI에도 십분 발휘될 수 있도록 하겠습니다.

사람을 이해하는 기술로 다가가기 위한 카카오의 노력을 지켜봐주시기 바랍니다.

AI Mate와의 새로운 연결, Kanana

소개

카카오의 AI 서비스 담당 이상호는 생성형 AI의 시대에 카카오가 어떤 서비스를 개발하고 어떤 가치를 전달하고자 하는지 설명합니다. 특히 Kanana라는 AI 서비스에 대한 자세한 정보를 제공할 예정입니다.

Preview: 카카오톡 이야기

카카오는 연결과 관계, 커뮤니케이션에 집중하며 기술을 발전시켜 왔습니다. 1:1 대화는 물론 지인, 비지인, 오픈채팅 등 다양한 커뮤니케이션 환경을 제공하며, AI 시대에도 사용자의 편의를 높이기 위해 지속적으로 노력하고 있습니다.

우리 모두의 짝꿍 AI mate

Kanana는 사용자와의 깊은 연결을 통해 모든 대화 내용을 기억하고 이해하는 AI 메이트입니다. 시간이 지남에 따라 사용자와 함께 성장하며, 새로운 일상을 함께 만들어가는 가장 나다운 AI입니다.

당연히 카카오톡을 기반으로 AI 서비스를 할 거라 생각하지 않으셨나요?

카카오는 기존의 틀을 깨고 새로운 시도를 통해 더 나은 AI 서비스를 개발하기 위해 노력하고 있습니다.

개인 메이트 나나와 그룹 메이트 카나

나나

나나는 카나나 앱 내에서 언제나 사용자의 곁에 있으며, 다양한 상황에서 도움을 줍니다. 주요 기능은 다음과 같습니다:

기억력: 나나는 사용자의 모든 대화와 활동을 기억하여 개인 맞춤형 서비스를 제공합니다.
대화 형태: 음성 인식 기능을 통해 자연스럽게 대화할 수 있으며, 특히 야외에서 걷는 중이나 타이핑이 불편할 때 유용합니다.
정보 접근: 사용자가 참여 중인 모든 그룹의 내용을 참고할 수 있으며, 각종 문서에 질문을 던질 수 있습니다.
비서 역할: 다양한 일상 업무를 지원하며, 사용자의 일상에 자연스럽게 녹아듭니다.

카나

카나는 그룹 대화에서 도움을 주는 AI로, 주요 특징은 다음과 같습니다:

그룹 대화 지원: 현재 참여 중인 그룹의 대화 내용을 기억하며, 대화의 흐름을 이끌어가는 역할을 합니다.
분위기 메이커: 그룹의 대화를 더욱 즐겁고 활기차게 만들어주는 분위기 조성 역할을 합니다.
가족 및 친구 추천: 가족의 취향을 이해하고, 숙소나 회식 장소를 추천하며, 사용자에게 유용한 정보를 제공합니다. 예를 들어, "저번에 갔던 곳 어디였지?" 같은 질문에 적절한 답변을 제공합니다.
적응력: 카나는 그룹 대화에 최적화되어 있어, 사용자가 필요한 순간에 맞춤형 대응을 합니다.

기능에 대한 설명

1:1 대화: 친구 요청을 통해 1:1 대화를 가능하게 하며, 대화 상대를 추가 초대할 수 있습니다.
보안: 사용자의 모든 메시지는 암호화되어 보안 존에 저장됩니다. 암호화된 키는 사용자의 휴대폰에 저장되어, 사용자만 복호화하여 볼 수 있습니다.
데이터 동기화: 새로운 휴대폰으로 전환할 때 모든 대화 내용이 자동으로 동기화되어 백업 없이 사용할 수 있습니다.

결론

카카오는 AI를 활용하여 사용자와의 연결을 더욱 강화하고, 미래를 창조하는 데 앞장서겠다는 포부를 가지고 있습니다. Alan Kay의 말인 "미래를 예측하는 가장 좋은 방법은 미래를 창조하는 것"이라는 원칙 아래, 발전하는 카카오의 모습을 기대해 주세요.

기술 세션

최적의 LLM을 선택하는 방법 : DUO

소개

카카오뱅크 금융기술연구소에서 LLM 평가 시스템 DUO(Diverse Understanding Observation of LLM)의 개발 과정을 공유합니다. 이 시스템을 통해 LLM의 성능이 단순히 뛰어난 것 이상의 의미를 가질 수 있음을 알리고자 합니다. 매니저는 개인적인 경험을 통해 LLM을 사용하여 중요한 정보를 정리하는 방법을 소개하며, 사용자의 필요에 따라 LLM의 활용 가능성을 강조합니다.

생성형 AI의 황금기 : 끝없이 등장하는 LLM들

2022년 이후 LLM의 수가 폭발적으로 증가하면서, 어떤 모델이 가장 좋은지에 대한 궁금증이 커지고 있습니다.

현재 보통의 LLM 벤치마크 : Open KO-LLM LeaderBoard

기존의 LLM 평가 방식은 질문에 대한 답변의 일치성을 판별하는 기본적인 평가 방식으로 이루어져 있습니다. 이를 통해 언어 모델은 크게 문장을 완성하는 프리트레인 모델과 특정 도메인에 특화된 인스트럭션 튜닝 모델로 나눌 수 있습니다. 하지만 Ground Truth의 기준은 실제 사용성과 차이가 있으며, 사람의 선호도를 반영해야 합니다.

그래서 등장한 벤치마크

챗봇 아레나

유저가 질문을 넣으면 두 모델이 각각 다른 답변을 내놓고, 사람의 선호도 기준으로 순위를 매기는 방식입니다. 하지만 최신 모델의 반영이 느리고, 질문 범위가 넓어 편향이 발생할 수 있습니다.

MT-Bench

MT-Bench는 사람의 선호도를 모방한 LLM이 모델의 성능을 평가하는 방식입니다. 그러나 Judge LLM이 특정 분야에 대한 지식이 부족할 경우 평가가 어려울 수 있으며, 환각 문제와 편향성도 존재합니다.

그 외

Prometheus 2, HumanEval, IFEval 등의 다양한 벤치마크도 존재합니다.

프로젝트 과정

처음에는 가장 좋은 모델 하나를 선택해 평가하려 했으나, 벤치마크의 한계점을 마주했습니다. 이 과정에서 Limited Scope와 Short Life Span의 두 가지 한계를 발견했습니다. 이로 인해 여러 벤치마크를 동시에 사용할 수 있는 프레임워크의 필요성이 대두되었습니다.

LLM을 어떻게 이해해야 하는가

LLM의 다양하고 복잡한 세상을 이해하기 위한 평가 기준으로 Data, Method, Metric의 세 가지에 집중해야 한다고 강조합니다. 전체 평가 구조는 Topic, Ability, Data, Method, Metric으로 나뉩니다.

Topic 평가 분야

금융(FCA)과 일반 분야(FMT)로 나뉘며, FCA에서는 금융 분야 계산의 정확도를, FMT에서는 질문 맥락을 유지하는 것이 중요합니다.

FMT : Financial Multi Turn FMT 설계 과정에서는 대화 맥락의 연속성을 반영하여 사용자의 경험을 더욱 자연스럽게 만드는 것이 중요합니다. FMT 적용 예시는 세법 판례 해석을 통해 제시됩니다.

결과 분석

DUO를 사용하여 21개 모델을 평가한 결과, GPT 기반 모델의 성능이 우수하다는 결론에 도달했습니다. 또한 두 가지 결론을 도출할 수 있습니다:

적정 성능 이상 달성 시, 파라미터 사이즈와 성능의 관계가 낮음.
모델의 최신성과 성능의 상관관계가 높음.

결론적으로, LLM을 이용한 AI 서비스 설계 시, 최신 버전을 기반으로 유연한 개발이 가능한 아키텍처 선정이 중요합니다.

Lesson Learn

평가하고자 하는 분야와 목적을 초기에 명확히 할 것
세상에 데이터는 많지만, 우리가 찾는 데이터는 없다.
→ 다양한 분야의 시드 데이터 필요
동일 실험을 반복하여 성능에 대한 신뢰도 확보 필요
데이터를 자의적으로 해석해서, 사용자의 의도와 다른 결과를 야기시키는 경우가 많았음
→ 프롬프트 엔지니어링 등의 도구를 통해 완화가 필요했음
정답을 맞춘 건지, 임의로 선택해서 맞춘 것인지에 대한 검증 필요
LLM Judge에 대한 검증 필요

데이터 분석과 머신러닝을 통한 유저 방문 맛집 발굴하기

먼저 기본 용어 설명

POI (Point of Interest): 관심 지점으로, 이 세션에서는 맛집 정보를 의미합니다.
위치 로그: 카카오맵 서비스의 현위치 정보로, 특정 사용자가 아닌 낮은 해상도로 제공되며, 카카오맵에서 현위치 버튼을 클릭할 때만 생성됩니다.

why? 왜 시작되었는가

이 프로젝트는 조직 내 실험성 프로젝트로, 데이터 자산을 축적하고 실현 가능성을 체크하는 것이 목적이었습니다.

데이터 현황 조사

예측 가능한 데이터: 카카오맵의 도착 로그 및 예약 로그.
예측 불가능한 데이터: 위치 로그.

위치 로그에서 방문 맛집을 찾는 게 가능한 일일까?

레퍼런스 조사(POI 예측 관련 서베이)
- next POI recommendation
- next location prediction
- trajectory segmentation

→ 우리가 풀고자 하는 문제와 정확히 매칭되는 레퍼런스는 없었습니다.

문제1: 구역을 구분하기

방문 정보를 구분해낼 수 있을까?
위치 로그 자체로는 방문 지역을 알 수 없습니다. 이에 따라 예측에 방해되는 데이터를 필터링하는 과정이 필요합니다.

→ 정밀도가 높을 수 있도록 보수적으로 진행했으며, 다음의 방법론을 적용했습니다.

POI와 매핑되지 않는 위치 로그는 필터링
특정 기준 이상 체류하면 방문으로 판단
동일 구역에 기준치 이상의 차이로 로그 남기면, 방문했다고 판단

문제2: 오차 해결하기

넓은 방문 구역은 어떻게 처리할까요? 위치가 정해져도 다음의 문제가 존재했습니다.
- 위치 로그의 낮은 해상도
- 고도 측정 불가(몇 층 방문한 건데?)
- 기타 오차(위치 로그의 오차는 건물 내부에서 더욱 발생)

이를 위해 떠올린 방안들은 다음과 같습니다.

위치 로그의 오차 반경을 좁혀서 정확한 위치 예측 → 높은 수준의 기술이지만 ML 엔지니어한테 적합한 접근은 아닙니다.
오차 반경을 감안해서, 데이터 적인 접근으로 해결해당 위치 로그의 POI 풀을 모두 불러와서, 모델에게 가장 높은 가능성을 가진 POI를 뽑도록 했습니다. 이를 통해 POI 후보 중 어디를 갔을 지 어떻게 예측할 수 있을까? 라는 풀 수 있는 문제로 바꾸고자 노력했습니다.

문제 3: 방문 맛집 예측하기

가장 높은 확률을 가진 맛집을 방문 맛집으로 확정하기 위해, 다음과 같은 절차를 통해 학습 데이터 수집과 모델 학습을 진행했습니다.

학습 데이터 수집

정답 데이터 확보: 정확한 예측을 위해 카카오맵의 도착 로그와 클릭 로그를 활용했습니다.
로그 분석: 방문하려는 장소가 로그와 다를 경우(예: 강남역 맛집을 찾으려는데 강남역 찍은 경우), 도착 로그의 POI에 위치 데이터가 남아 있는지 확인하여 도착 로그로 판단했습니다. 특정 기간 동안 검색한 적이 처음인 도착 로그만 남기기로 결정했습니다.
클릭 로그 처리: 반경 내의 N개 장소를 모두 클릭했더라도, 실제 방문 여부를 판단하기 위해 위치 로그 지점과 POI 지점이 동일한 경우에만 활용했습니다. 또한, 클릭 로그에서 같은 구역에 2개 이상의 장소가 남아 있으면 정답에서 배제했습니다.

피쳐 데이터 가공

유저 데이터 활용: 성별 및 연령대에 따라 장소 선호가 다를 수 있으므로, 이러한 정보를 피쳐로 활용했습니다. 방문 시간대에 따른 장소 선호도 반영하기 위해 방문 시간과 지역 정보도 피쳐로 포함시켰습니다. 유저가 이전에 방문한 장소의 정보도 예측에 영향을 미칠 수 있습니다.
장소 데이터 활용: 장소의 검색 로그를 사용하여, 동일한 유저가 동일한 시간에 방문한 기록을 기준으로 모델의 입력으로 삼았습니다.

모델 학습

모델 후보 선정: LLM, 시퀀셜 모델, 분류 모델 중에서 검토했습니다.
- LLM: 데이터가 부족해 오버스펙 우려가 있었고, 입력할 히스토리 정보가 부족해 후보에서 제외했습니다.
- 시퀀셜 모델: 방문 로그가 균일하지 않아 좋은 시퀀스 데이터로 간주하기 어려웠습니다. 콜드 유저가 전체 유저의 50%를 차지하는 문제도 있었습니다.
분류 모델 확정: 분류 모델이 피쳐를 바로 활용할 수 있고, 시계열 요소를 포함하지 않아 유리하다고 판단했습니다. 다양한 분류 모델 중 LightGBM을 선택했으며, 이는 예측 속도가 빠르고 피쳐의 중요도를 파악할 수 있었습니다.

결과 소개

예측에서 백화점, 아울렛, 테마파크와 같은 대규모 장소의 맛집은 제외하였습니다. 이 부분은 예측이 거의 불가능하다고 판단했습니다.

Next Step

방문 위치 정보 모수 확장
POI 예측 모델 고도화

Q & A 세션

흥미로운 주제였습니다. 가상 데이터가 많이 인풋으로 들어올 것 같은데, 예를 들면 올리브영 들린 경우 → 어떻게 처리했는지 / 주변 음식점 검색을 하는 경우(가끔 궁금해서 검색 해보잖아요?) → 이럴 땐 어떻게 했는지 궁금합니다.
- 음식점이 아닌 경우에 대한 대처
  - 음식점 POI에 대해서만 진행했습니다. / 예측 시에는 올리브영 같은 것도 풀에 들어가긴 합니다. → 이런 게 1순위로 나왔을 때는 그냥 배제 시켰어요.
  - 주변 음식점 검색의 경우에는, 검색의 경향이 강한 로그가 남게 되어서 다른 장소가 여러 번 검색된 경우에는 정답에서 배제를 했습니다.
유저한테 피드백 정보가 가는 경우도 있나요?
- 내부 실험성 프로젝트로 진행한 거라 그런 건 아직 없습니다. 가능성을 확인해본 프로젝트였다고 생각해주시면 될 것 같습니다.
두 가지 궁금한 점. 내용을 보면, 맛집이라기 보다 음식점 추천 느낌이 있더라구요? 사용자 리뷰 관련 기준은 없던데 왜 그런가요?
두 번째는 데이터 가공을 하고 나면 데이터 양이 많이 없었을 거 같은데, 필터링 된 데이터가 얼마나 있었는지 궁금하고, 적다면 오버피팅이 있었을 수도 있을 거라 생각하는데 어떻게 생각하시는지 궁금합니다.
- 첫 번째 : 장소 추천 목적이라기보단, 맛집 방문 했는지 여부로 발굴해보고자 한 거라서 목적이 다른 거라고 이해해주면 될 것 같습니다.
- 두 번째 : 적어서 N개월 치를 모았습니다. 못해도 학습 데이터셋이 10만 단위 이상으로 갔었어요. 오버피팅은 아직까지 발견되지 않았습니다.

AI Agent 기반 스마트 AI 마이 노트

1부 : AI 에이전트 기반 서비스 개발에 대하여

개요

AI 서비스는 2022년 11월 30일 챗GPT의 등장 이후 급격히 발전해왔습니다. 그러나 많은 서비스가 여전히 채팅창 형태로, 사용자가 질문을 잘해야 원하는 정보를 얻을 수 있는 한계가 있습니다. 이런 문제를 해결하기 위한 보다 직관적이고 편리한 AI 서비스의 필요성이 대두되고 있습니다.

그 전에 AI Agent란?

AI Agent는 동적인 환경에서 자율적으로 목표를 달성하기 위해 행동하는 시스템입니다. LLM의 등장은 에이전트가 추론을 통해 더 지능적으로 행동할 수 있도록 하였습니다. RAG와 Tools 등을 통해 에이전트의 역량이 더욱 강화되고 있습니다. 그러나 에이전트를 개발하기 위해서는 CoT(Chain of Thought)와 RAG, Tools, Long-term Memory와 같은 여러 요소들을 깊이 있게 고려해야 합니다. 특히 Long-term Memory는 발전이 더딘 분야로, 잠재적인 가치는 크지만 많은 연구와 개발이 필요합니다. 현재 카카오에서는 Kakao AI Platform을 개발해서 자체 채팅 인터페이스 및 API를 제공하고 있습니다.

서비스 이야기로 다시 돌아가보자

챗봇과 AI 에이전트의 차이를 이해하는 것이 중요합니다. 많은 사람들은 이 둘의 기능적 차이(정적 vs 동적)에 집중하지만, 에이전트를 단순히 고급 챗봇으로만 보는 경향이 있습니다. 챗봇은 특정 서비스를 제공하는 반면, 에이전트는 객체로서 존재하며 그 자체로 서비스가 아닙니다(물론 서비스로 발전할 수는 있습니다). 에이전트는 자연어를 통해 프로그램 내부에서 자율적으로 소통할 수 있으며, 사용자는 에이전트와 직접 상호작용할 필요 없이 AI 서비스 개발자가 어떻게 활용할지를 고민하는 것이 중요합니다.

능동적으로 동작하는 대표 AI 서비스

코파일럿, 아이패드 계산기와 같은 서비스들은 사용자 반응을 적극적으로 살펴보며, 더 나은 경험을 제공하는 AI 에이전트의 예입니다. 이러한 서비스들은 사용자의 필요를 세심하게 분석하며 실질적인 도움을 주고 있습니다.

정말 편한 서비스, 근데 이제 AI Agent를 곁들인…

사용자를 꼼꼼히 뜯어보고 연구해서 기존과는 다르게 사용자에게 실질적인 서비스를 제공할 수 있다고 생각합니다. 그래서 PoC 개념으로 만들어 본 서비스가 있습니다.

Jira, Widi, Agit 등 업무 툴이 많아서 공유하기도, 싱크를 맞추기도 힘든 문제를 발견했습니다.
이를 해결해보고자 프로토 타입을 제작했어요. 업무 내용을 위키에 정리하고 링크를 전달하면, 에이전트가 이를 요약해서 주간 업무 공유 글을 작성해주는 시스템을 만들었습니다.
생각보다 너무 잘해주던데? 이거보다 더 재밌는 것도 가능하겠는데? 라는 생각이 들었고, 그렇게 디벨롭이 시작되었습니다.

2부. 에이전트 도입 사례 - 스마트 AI 마이노트

개요

연말 평가 등을 해결하고자 했음
개발 배경 및 동기, 주요 기능, 개발 과정에서의 어려움, 실제 적용 시 고려해야 할 리스크 순으로 진행

개발 배경 및 동기

연말 평가와 같은 중요한 프로세스는 종종 고통스러운 과정을 수반합니다. 성과 정리 및 파악이 주된 Pain Point로, 이를 해결하기 위한 방안을 고민하게 되었습니다.

이전에 자동화를 위한 시도들의 실패

과거 시도들은 데이터의 질이 좋지 않거나, 맥락을 이해하지 못하는 등 여러 문제로 실패하였습니다. 그러나 LLM의 등장은 이러한 문제를 해결할 수 있는 새로운 가능성을 열어주었습니다. 자연어 처리 능력, 맥락 이해 능력 향상 측면에서 자연어로 소통이 가능하며 사용자 경험을 개선시켜 줄 것을 기대했습니다.

에이전트까지 도입하면 해볼만 하다!

AI 에이전트를 도입하면, 백그라운드에서 자동으로 작업을 수행할 수 있어 사용자 개입이 필요 없습니다. 이로 인해 사용자가 인지하지 못하는 사이에 도움을 주기에 부담을 덜 수 있습니다.

모으기, 분류하기, 요약하기

데이터를 모으고
목표와 업무를 매핑시키고(분류)
간단 명료하게 요약시키기

→ 이 세가지 업무를 잘 수행하겠다고 판단했습니다.

주요 기능

성과 노트 초안 생성: JIRA 티켓을 가져와 이슈 및 에픽을 요약하고, OKR에 매핑하여 성과 노트 초안을 생성합니다.
성과 평가 초안 생성: 피평가자의 성과 노트를 조회하고, 피드백 질의응답을 통해 초안을 작성합니다. AAT 및 SBI와 같은 피드백 방법론을 적용합니다.
- - Action Appreciation Thanks - 룰에 맞추어 ~해주셔서 감사합니다. 덕분에 ~ 했습니다. 등의 형태
  - Situation Behavior Impact - 상황을 객관적으로 전달(예 : 이번 주 ~에서 ~한 상황으로 ~가 되었습니다. 다음엔 ~해주시기 바랍니다.)

개발 과정에서의 어려움

데이터 전처리: 일관되지 않은 데이터를 정제하는 데 많은 노력이 필요했습니다.
프롬프트 엔지니어링: LLM의 성능을 극대화하기 위한 적절한 프롬프트 설계가 중요하며, 문구, 구조, 길이 등이 결과에 큰 영향을 미쳤기에 매우 많은 테스트를 진행했습니다.(머리가 지끈했어요.)

실제 적용 시 고려해야 할 리스크

AI 윤리, 편향성, 개인정보 보호, 노동법 등 다양한 이슈를 고려해야 하며, API 및 인프라 비용 관리도 중요한 요소입니다.

AI 에이전트를 서비스에 적용하는 것은 많은 가능성을 가지고 있으며, 이에 대한 연구와 개발이 지속적으로 필요합니다.

지연 시간 순삭! LLM 추론 구조와 효율적 애플리케이션 설계

소개

카카오 엔터테인먼트 AI Lab의 AI 엔지니어가 지연 시간을 초과하는 서비스를 최적화하기 위해 고민했던 과정을 공유하고, 속도 최적화에 초점을 맞춰 설명하겠습니다.

실시간 LLM 애플리케이션

코파일럿, 퍼플렉시티, 챗봇, 버추얼 휴먼 등 다양한 애플리케이션에서 즉각적인 응답은 매우 중요합니다. LLM(대형 언어 모델)의 추론 과정에서 자원을 효율적으로 처리하고 응답 지연 시간을 단축시키는 방법에 대해 살펴보겠습니다.

다양한 사용자 요청 처리 방안

LLM 단독 처리
LLM 외부 데이터 이용 (RAG)
AI 에이전트의 도움

이러한 과정에서 요청과 응답의 품질을 높이기 위한 다양한 프로세스가 존재하며, 여러 LLM이 관여할 경우 지연 시간이 늘어날 우려가 있습니다. 따라서 처리량을 최대화하고 지연 시간을 최소화하기 위한 방법을 공유합니다.

LLM 큰 그림

LLM은 "텍스트의 다음 단어(토큰) 예측"을 기반으로 하는 autoregressive 모델입니다. 여기서는 Decoder-Only Transformer 아키텍처를 중점적으로 다룹니다. 매 토큰 생성 시 추론이 일어나므로 최적화가 중요합니다.

최적화 방법 1. Closed Question

프롬프트에 형식을 지정하여 생성되는 토큰 수를 줄이는 방법입니다. 예를 들어, 질문에 대해 맞으면 1, 틀리면 2를 출력하도록 설정하여 효과를 극대화할 수 있습니다. 간단하면서도 큰 효과를 볼 수 있는 방법입니다.

LLM 입력

토큰: 시퀀스를 구성하는 최소 단위입니다.
다양한 Tokenizer: 주로 사용되는 토크나이저는 character-based, whitespace, subword-based 등입니다. 일반적으로 서브워드 기반 토크나이저가 가장 많이 사용됩니다.
처리 과정: 토큰 임베딩과 포지셔널 임베딩이 결합되어 트랜스포머 블럭으로 이동합니다.

최적화 방법 2. Tokenizer

자체 용어집을 활용한 토크나이저 최적화는 세분화를 줄이는 데 도움을 줍니다.

LLM 출력

최종 hidden state를 여러 토큰들과 비교(내적)하면서, 가장 적절한 다음 토큰을 찾음
토큰 출력을 임의로 조정한다면?
- 1, 2만 출력하도록 한 위의 예시에서 1, 2 외의 확률 값을 -inf로 수정한 후 소프트맥스 태우기

최적화 방법3. Structured Output

모델의 출력을 JSON 형식으로 얻고자 할 때 예를 들어보죠.
- 그냥 프롬프트로 JSON을 지정했을 때의 위험
  - 프롬프트로 JSON 형식을 지정할 경우, 항상 원하는 형식으로 출력된다는 보장이 없습니다.
  - 또한, JSON에서 부수적인 토큰(대괄호, 따옴표 등)도 추론하게 되어 처리 시간이 길어질 수 있습니다.
- Structured Output
  - JSON 형식의 괄호와 따옴표는 고정된 형식으로 자동 출력하고, LLM은 key에 맞는 value만 추론하게 합니다. 이렇게 로짓 값을 수정하면 원하는 형식의 출력을 더욱 정확하게 얻을 수 있습니다.

LLM 내부

LLM은 셀프 어텐션과 피드포워딩으로 이루어져 있으며, 토큰의 문맥적 의미는 주변 토큰에 의해 생성됩니다.

최적화 방법 4. KV Cache 사용

이전에 수행한 연산을 캐시하여 다음 연산에 활용하는 방법입니다.

최적화 방법 5. 병렬 추론

서로 다른 프롬프트에 대해 병렬 처리가 가능하여, KV Cache 메모리 점유율을 높이고 전체 throughput을 향상시킵니다. 하지만, 메모리 파편화 문제 발생해서, 이를 완화하기 위해 vLLM이 등장했습니다.

최적화 방법 6. 병렬 처리

프롬프트 처리 단계와 텍스트 생성 단계로 나뉘며, 프롬프트 처리는 한꺼번에 수행하는 것이 유리합니다. vLLM, Orca, DeepSpeed-FastGen과 같은 다양한 처리 방식이 존재합니다.

최적화 방법 7. Prefix

서로 다른 프롬프트에서는 KV Cache를 공유할 수 없는 것이 원칙입니다. 하지만, 동일한 프롬프트에서 뒷부분만 다르면 서로 다른 시퀀스 간 KV 캐시를 공유할 수 있습니다. 이를 위해서는 비슷한 두 시퀀스를 감지하는 기능에 대한 연구가 필요합니다.

발표 정리

LLM 구조 : 입력, 출력, 내부 형태로 전체 흐름을 진행했습니다.
최적화 기법 7가지를 소개했습니다.
구조와 원리를 알아야 좋은 플랫폼, 라이브러리, 도구 선택이 가능하다는 사실을 강조합니다.

카카오클라우드 MLOps 활용 방안 소개

소개

MLOps: 머신러닝 개발과 운영을 통합하는 시스템 및 프로세스를 의미하며, 데이터 및 모델의 복잡성이 증가함에 따라 컴퓨팅 자원의 최적화가 필요합니다.

개요

MLOps는 기본적으로 DataOps와 Machine Learning Flow로 구성됩니다.

DataOps: 데이터 수집, 전처리(정제 및 변환), 버저닝 과정을 포함합니다.
Machine Learning Flow: 모델 개발, 학습, 평가, 배포 및 서빙, 성능 모니터링 및 버전 관리가 포함됩니다.

MLOps on KakaoCloud

Ingestion, Preparation, Analytics, ML 단계로 분류
Preparation : 수집 정제 등의 ETL 작업 수행
Analytics : 데이터 분석 및 인사이트 도출
ML : Kubeflow 컴포넌트 활용하여 ML Flow 지원

활용 예제

트래픽 예측: 로드밸런서 접근 로그를 활용하여 시스템의 이상 징후를 실시간으로 탐지하고 대응 속도를 향상시키고자 합니다.
트래픽 예측 모델 구현 Flow: 버튼 클릭으로 생성할 수 있으며, 파이프라인을 통해 자동화됩니다.
- 머신러닝 파이프라인은 학습과 추론으로 나뉘며, 모델 평가는 지난 1주일 치 데이터 기반으로 이루어집니다.

그 다음은?(Next)

초거대 AI 모델 학습을 최적화하기 위한 tracing 기능을 강화할 예정입니다. 많관부.

AI 기반 광고 추천 파이프라인에서 스파크 스트리밍의 배포 및 모니터링 전략

소개

본 발표에서는 고객 행동 데이터를 실시간으로 분석하여 맞춤형 광고를 제공하는 방법과 배포 및 모니터링 전략에 대해 다룹니다.

카카오의 광고 추천

카카오는 모델 서빙과 랭킹 → 모델 학습 및 실험 → 데이터 ETL → 광고 플랫폼이라는 순환 구조로 광고 추천을 수행합니다.
드루이드에 적재된 데이터는 익명화 과정을 거친 데이터로, 복잡한 스트림 데이터 처리 과정이 필수적입니다.

기존 & 신규 지표 시스템 아키텍처

기존 시스템에서 발생한 주요 이슈:
- 언어와 배포의 파편화
- 스키마 하드코딩
- 배치 및 스트리밍 파이프라인의 모니터링 부재
- 파이프라인 리니지 확인의 어려움
이러한 문제를 해결하기 위해 신규 지표 시스템 아키텍처를 설계했습니다.

파이프라인 배포 아키텍처

각 파이프라인의 설정값 형태가 달라 스키마리스한 몽고디비를 선택하였습니다.
도커 이미지를 생성하고 entrypoint.sh를 통해 실행합니다.
최종적으로 사내 하둡 서비스인 Spark Job에서 실행됩니다.

파이프라인 모니터링 아키텍처

모니터링 파이프라인은 Kafka, Sender, tsCoke, Grafana로 구성되어 있습니다.
확장 가능한 모니터링 지표 수집을 위해 이 파이프라인이 구축되었습니다.

스파크에서 제공하는 StreamlingQueryListener

이 도구를 통해 데이터의 입력, 커밋에 사용할 데이터, 그리고 출력 데이터를 확인할 수 있습니다.
오프셋 커밋을 수행하기 전, 파티션별 오프셋을 JSON으로 파싱해야 합니다.

성과

배포 과정을 일원화하고 간소화하여 안정성을 개선했습니다.
모니터링 파이프라인 구축으로 실시간 모니터링이 가능해졌습니다.
향후 더 나은 지표 시스템을 위해 지속적인 발전을 목표로 하고 있습니다.

Q&A

스파크 스트리밍 말고도 다양한 도구들이 있는데 스파크 스트리밍을 접목한 결정적인 이유가 궁금하고, 성능 이슈가 없었는지 궁금합니다.
- 첫 번째 : 많은 논의가 있었어요. 이전에 있던 지표 시스템을 / 배치 단위 + 실시간으로 실행되는 스키마를 모두 처리할 수 있었어야 했습니다. 그와 동시에 배치와 스트림을 한 번에 처리할 수 없을까? 라는 고민이 있었고, 그 과정에서 스파크를 선정했습니다.. 그리고, 사내 하둡 서비스를 이용하는데 거기서 많은 도움을 받을 수 있었기 때문에 선정했습니다.
- 두 번째 : 실제 이벤트 타임 대비 데이터 적재되는데 걸리는 시간이 1ms, 10ms로 낮아야 할 니즈가 없었습니다. 그렇기에 지속적으로 스파크를 선택할 수 있었습니다.

저작자표시 비영리 변경금지

'AI tech' 카테고리의 다른 글

EDA의 중요성 및 내가 겪은 시행착오 (0)	2024.11.24
Text2SQL: 예약 어시스턴트를 위한 기술 탐구 (1)	2024.11.10
밑바닥부터 시작하는 딥러닝2 정리 Chapter 2 - 자연어와 단어의 분산 표현 (0)	2024.04.16
Transformer 기본 개념 (0)	2024.04.13
모델 학습 시작 또는 종료 시, Slack 알림 가게 하기 (1)	2024.02.14

IF (Kakao AI) 2024 - 모든 연결을 새롭게 (1일차, 컨퍼런스 참여 후기 및 요약)