Transcript
00:00:00간단한 질문 몇 가지 먼저 하고 바로 시작하도록 하겠습니다. 여기 계신 분들 중에
00:00:19음성 AI 에이전트를 직접 만들어 보신 분이 얼마나 되나요? 네, 청중 중에 꽤 많으시네요. 그럼
00:00:28실제 프로덕션 환경에 AI 에이전트를 배포해 보신 분들은 또 얼마나 되시나요? 나쁘지 않네요. 좋습니다. 그럼 보통
00:00:38어떤 일이 벌어지는지 이야기해 보죠. 다들 음성 AI 에이전트에 대해 이야기하잖아요? 아시다시피
00:00:47요즘 세상의 거의 모든 문제에 대한 만병통치약처럼 여겨지는 게 바로 음성 AI 에이전트입니다. 그래서 모두가
00:00:51에이전트를 만들고 배포하려고 하죠. 개발 환경에서
00:00:57만들어 볼 때는 아주 그럴듯하게 작동합니다. 그러다 개념 증명(PoC) 단계에서 프로덕션으로 전환하는 순간
00:01:03난관에 부딪히기 시작하죠. 그래서 오늘은 PLEVO의 음성 AI 에이전트 경험을 바탕으로
00:01:09어떤 문제들이 발생하는지 다섯 가지 관점에서 살펴보겠습니다. 그 전에 먼저 제 소개를 간단히 하겠습니다. 저는 창업자이자 CAO인 벤키입니다.
00:01:19다른 친구는 에이전트 엔지니어링 매니저라는 직함을 쓰는데, 저는 직함상 최고 에이전트 책임자(CAO)라고 부르고 있습니다.
00:01:28직함상으로는 그렇다는 거죠. 자, 그렇다면 우리가 왜, 왜 이런 논의를 할 자격이 있고
00:01:35설명해 드리겠습니다. 먼저 우리가 지금까지 걸어온 여정에 대해 조금 이야기한 뒤에 본격적으로
00:01:42들어가겠습니다. 저희는 약 14년 동안 비즈니스를 해왔습니다. 개발자 API 플랫폼으로 시작해서
00:01:48지금은 AI 에이전트 비즈니스를 하고 있죠. 2011년 당시 음성과 SMS API로 시작했습니다.
00:01:54그리고 지금은 풀스택 AI 에이전트 제품에 주로 집중하고 있습니다.
00:02:01플랫폼의 전체 스택 말이죠. 저희 플랫폼은 전 세계적으로 매달 10억 건 이상의 음성 통화를 처리하고 있으며,
00:02:08이를 통해 고객들과 함께 일하면서 프로덕션 환경의 음성 AI 에이전트에서 어떤 패턴들이 나타나는지
00:02:16많이 목격할 수 있었습니다.
00:02:20저희는 90명 규모의 팀이며, 5천만 달러의 투자금을 확보하고 있습니다.
00:02:25재미있는 사실은, 이것이 외부 VC 투자금 덕분이 아니라는 점입니다. 수년 동안 회사를 운영하며 이익을 내고
00:02:33곳간에 차곡차곡 쌓아둔 현금이라는 것이죠.
00:02:38저희가 전 세계에 걸쳐 지원하고 있는 일부 고객들의 로고를 슬라이드에 남겨두었는데요.
00:02:42제공하는 제품 관점에서 이것을 크게 세 가지로 분류해 볼 수 있습니다.
00:02:49하지만 제공하는 서비스 관점에서 보면, 저는 이것을 세 가지
00:02:54다른 영역으로 나눌 수 있습니다. 첫째는 프로그래밍 가능한 AI 에이전트 서비스입니다.
00:03:00아직 완전한 음성 대 음성 제품은 아니지만 음성 파이프라인 형태의 프로그래밍 가능한 서비스죠.
00:03:05또한 AI 에이전트 스튜디오도 가지고 있습니다. 노코드 시각화 빌더인데요. 그리고 앞서 말씀드렸듯
00:03:11음성 API로 시작했기 때문에, 지난 14년 동안 당연히 이를 발전시켜 왔습니다.
00:03:16SIP 트렁킹과 오디오 스트리밍 레이어 말이죠. 그래서 저희는 텔레포니나
00:03:22통신사 레이어를 다른 곳에 의존하지 않습니다. 그게 바로 수년간 구축해 온 핵심 비즈니스입니다.
00:03:26그리고 그 위에 저희의 AI 에이전트 플랫폼이 얹혀 있는 것입니다.
00:03:32자, 그럼 본론으로 들어가 볼까요? 여러분도 모두 AI 에이전트를 만들어 보셨으니
00:03:39이런 것들을 한 번쯤 보셨거나 어떤 방식으로든 직접 구현해 보셨을 겁니다. 전체적인 파이프라인이
00:03:44어떻게 생겼는지에 대해 더 많은 시간을 할애해 살펴보겠습니다. 고객들을 보면 알 수 있듯이,
00:03:51여러분도 충분히 공감하실 텐데요. AI 에이전트를 고민하는 누구나
00:03:56이러한 오케스트레이션 프레임워크들을 가져다가 꽤 훌륭하게 활용하곤 합니다.
00:04:01라이브킷(LiveKit)이나 파이프캣(Pipecat)을 써서 그 위에 AI 에이전트를 구축하는 식이죠. 이들은
00:04:06음성 인식(STT), LLM, 음성 합성(TTS)이라는 네 가지 서로 다른 레이어를 오케스트레이션하고
00:04:13그 사이에 발화 감지(Turn Detection)만 넣으면 바로 끝난다고 생각합니다. POC 단계에서 AI 에이전트가 잘 작동하니
00:04:19프로덕션에서도 잘 작동할 거라고 생각하는 거죠. 보통은 그렇게 시작합니다. 지연 시간을 측정해 보면
00:04:24이 슬라이드에서 각 레이어별 대략적인 지연 시간을 보실 수 있습니다. 사람들은 이를 보고
00:04:30네, 이 정도면 제가 필요한 용도에 충분하겠네요라며 프로덕션 배포를 진행합니다. 그러다
00:04:36프로덕션 환경이 가동되기 시작하면 온갖 종류의 장애 모드(Failure mode)가 나타나게 됩니다.
00:04:41이번 발표에서는 주로 그 부분에 대부분의 시간을 쓰게 될 것 같습니다. 질문이 있으실 경우를 대비해
00:04:48마지막에 질의응답 시간을 조금 남겨두었지만, 바로 이어서
00:04:53저희가 마주하는 다양한 장애 모드들에 대해 이야기해 보겠습니다. 먼저 누구나 입에 올리는
00:05:01첫 번째 주제부터 시작하죠. 가장 많이 회자되는 장애 모드인 바로 '지연 시간(Latency)'입니다. 오늘
00:05:07AI 에이전트나 음성 AI 에이전트에 관한 세션이 몇 개 더 있는 것으로 알고 있는데요. 아마
00:05:12다들 이 특정 장애 모드를 짚고 넘어가실 겁니다. 그래서 제가 이 이야기를 곧바로 꺼내는 이유는
00:05:17사용자 입장에서 이 전체적인 경험이 실제로 어떠한지 설명하기 위해서입니다. 보통
00:05:26대부분의 사람들은 이를 첫 번째 오디오가 출력되는 시간(Time to first audio), 즉 사용자가 발화를 멈춘 순간부터
00:05:34에이전트가 말하기 시작할 때까지의 시간이죠? AI 에이전트를
00:05:39구축해 보셨다면 어떤 느낌이 좋고 자연스러운지, 어떤 느낌이
00:05:46거슬리는지, 혹은 완전히 짜증 나는지 단계별로 체감해 보셨을 겁니다.
00:05:52대부분 플랫폼이나 솔루션에서 광고하는 550밀리초 미만을 원하지만,
00:06:00실제로는 대부분 750밀리초에서 1.2초 사이에 머무는 경우가 많습니다.
00:06:07대다수가 이 범위에 속하고, 성능이 정말 떨어진다면
00:06:131.2초를 훌쩍 넘겨서 결국 사용자가 전화를 끊어버리게 되죠.
00:06:19이제 다양한 계층에서 고객들과 함께 프로덕션 환경에서 실제로 겪은 사례와
00:06:26그에 대한 해결책들을 공유해 드리겠습니다. 우리가 이 레이어를 접근할 때
00:06:33생각해야 할 점은 비용, 지능, 지연 시간이라는 세 가지 요소 사이의 균형입니다.
00:06:42왜 이 세 가지를 이야기하냐면 서로 밀접하게 연관되어 있기 때문입니다.
00:06:48밖에서 몇 분과 이야기를 나누다가 이런 말을 나눴는데요.
00:06:51지난 1년 동안 LLM 분야에서는 엄청난 혁신과 지능의 급상승이 있었습니다.
00:06:58대부분의 지능 향상은 심층 사고나 강화 학습 등을 중심으로 이루어졌죠.
00:07:05그런데 음성 에이전트의 아이러니는 말하는 LLM이나 에이전트의
00:07:11생각 기능이 거의 항상 꺼져 있어야 한다는 점입니다.
00:07:19지난 1년 동안 LLM 레이어에서 이뤄진 발전 중 여기서는 적용되는 게 거의 없습니다.
00:07:25물론 지시사항을 더 잘 따르거나 툴 콜링을 잘 수행하는 더 나은 모델들은 있지만,
00:07:29생사고 레이어에 내장된 지능은 충분히 빠른 속도를 내기 위해
00:07:34기본적으로 전부 꺼두어야 하거든요. 이게 바로 우리가 직면하는 아이러니 중 하나입니다.
00:07:39그렇다면 지능, 비용, 지연 시간의 균형을 어떻게 맞춰야 할까요?
00:07:44시중에 나와 있는 몇 가지 옵션들을 한번 살펴보죠.
00:07:48이전 차트에서 보셨듯이 LLM은 지연 시간을 가장 크게 유발하는 주범이기 때문에
00:07:55특별히 LLM을 짚어서 이야기하는 것입니다.
00:08:02대부분 기본적으로 선택하는 프론티어 모델, 즉 OpenAI, 클로드, 제미나이를 보면
00:08:09P50 기준 첫 토큰 생성 시간(TTFT)이 평소에는 450~500밀리초 정도이지만 튀어 오를 수 있습니다.
00:08:17P90이나 P95 같은 경우는 쉽게 1.2초, 심지어 1.3초 이상으로 치솟을 수 있으며,
00:08:25이는 전체 에이전트 경험에 좋지 않습니다. 자, 그게 바로 프론티어 모델입니다.
00:08:31다른 옵션으로는 토큰을 아주 빠르게 뱉어내는 것으로 유명하고 인기 있는 세레브라스나 그록이 있습니다.
00:08:38이런 방식도 작동은 하지만, 여기서 전용 지연 시간이나 첫 토큰 생성 시간을 보장받으려면
00:08:45전용 용량이 필요하고 비용이 엄청나게 비쌉니다.
00:08:51아까 균형을 맞춰야 할 요소 중 하나로 비용을 언급했던 이유가 바로 그 때문입니다. 정말 비싸죠.
00:08:56그록 팀이나 세레브라스 팀 누구에게 물어보더라도 이렇게 말할 겁니다.
00:09:01전용 용량을 쓰려면 12개월 전에 미리 예약해야 한다고요. 향후 1년 치가 전부 예약되어 있습니다.
00:09:05그러니까 꽤 비용이 많이 드는 옵션이죠. 게다가 배포하려는 모델이
00:09:11이러한 인프라 레이어에서 12개월 뒤에도 살아남을지 확실히 알아야 해요.
00:09:17이는 엄청난 투자이자 큰 미지의 영역입니다. 그렇다면 프로덕션 급에
00:09:27이 세 가지 요소를 잘 균형 잡힌 고품질의 에이전트 말입니다.
00:09:34우리에게 효과가 있었던 것은 바로 오픈 소스 모델이었습니다.
00:09:41선택할 수 있는 종류와 변형도 당연히 아주 많습니다. 제가 특별히 말씀드리고 싶은 것은
00:09:47저희가 함께 다루고 있는 두 가지 모델, Qwen 3.5와 Gemma 4입니다. 현재 시장에 나와 있는
00:09:56최첨단 오픈 소스 모델이라고 볼 수 있죠. 이 모델들의 성능에 대해 많은 벤치마크를 진행해 보았습니다.
00:10:02'모델이 생겼으니 이제 직접 호스팅하고 내 GPU에서 돌려야 하네'라고 생각하면 겁이 날 수도 있습니다.
00:10:10하지만 300밀리초 미만을 꾸준히 목표로 한다면 이 방식이 지연 시간, 비용, 지능 사이의
00:10:17훌륭한 균형점이라는 것을 알 수 있었습니다.
00:10:23자, 조금 더 깊이 들어가 볼까요? 영어만 다룬다면 Qwen 3.5나 Gemma 모두 잘 작동합니다.
00:10:29하지만 다국어 서비스, 즉 글로벌 청중이나 다양한 언어를 다뤄야 한다면 Gemma 4가 훨씬 더 나은 모델입니다.
00:10:35토큰 효율성 평가를 진행해 보았는데요. 쉽게 풀어서 설명하자면,
00:10:44해당 언어로 단어 하나를 생성하는 데 토큰이 얼마나 소모되는지를 뜻합니다.
00:10:48다국어 관점에서 Gemma가 Qwen 3.5보다 최소 2.5배에서 3배 이상 훨씬 더 뛰어납니다.
00:10:56따라서 다국어 기준에서는 다른 조건이 모두 같을 때 Gemma 4의 응답 속도가 훨씬 더 빠릅니다.
00:11:04다국어 처리를 기준으로요. 자, 그럼 LLM 계층에서는 어떤 크기의 모델을 선택해야 할까요? 혼합 전문가(MoE) 모델이 보통
00:11:12잘 작동합니다. 30억 또는 40억 파라미터 규모의 MoE 모델이면 대개 무난하게 쓸 수 있죠. 다만
00:11:17혼합 전문가 모델의 문제는 누군가 파인튜닝을 시도하려고 할 때 까다로워질 수 있다는 점입니다.
00:11:22MoE 모델 파인튜닝은 그리 간단하지 않거든요. 자칫하면 모델이 망가지거나
00:11:28오류가 나는 경우가 많습니다. 그래서 이게 MoE 모델을 쓸 때 겪는 대표적인 어려움 중 하나지만, 보통 별도의
00:11:35파인튜닝이나 커스텀 작업 없이도 곧바로 원하는 수준의 90% 정도는 달성할 수 있습니다.
00:11:42이것이 바로 MoE 모델의 장점이죠. 자, 그런데 만약 파인튜닝을 하고 싶거나
00:11:48더 깊이 들어가서 '나는 헬스케어 같은 특정 도메인에서 일하고 있으니
00:11:53모델을 반드시 파인튜닝해야겠다'고 생각하신다면, 현재 기준으로 볼 때는 적어도
00:11:588억이나 12억, 아니 80억이나 120억 파라미터 모델부터 시작하는 것이 좋습니다. 어쩌면 6개월 뒤에는
00:12:0440억 모델이 80억 모델을 가볍게 뛰어넘을지도 모르지만요. 하지만 오늘날의 기준으로 보면
00:12:11최소한 80억이나 120억 모델이 필요하다는 것을 알 수 있습니다. 이 모델들에서 기대하는 바가 두 가지이기 때문이죠.
00:12:16하나는 당연히 빠른 토큰 생성이고요, 다른 하나는 훌륭한 지시 따르기 능력입니다. 알겠죠? 그리고
00:12:23두 번째는 툴 호출(Tool Calling) 성공률이 매우 높아야 한다는 점입니다. 이 두 가지를 잘 해내면
00:12:29모델을 전혀 파인튜닝하지 않아도 이미 70~80%는 달성한 셈이며, 모델들이 곧바로 잘 작동하게 됩니다.
00:12:35이것이 바로 저희의 비법입니다. 실제로 저희는
00:12:42두 가지 방식을 운영하고 있습니다. 특정 산업군을 위한 파인튜닝 모델을 하나 쓰고요, 그리고 대부분의
00:12:50일반적인 유스케이스에는 MoE 모델을 그냥 기본으로 사용합니다. 실패 사례에 대해 이야기하게 될
00:12:56다다음 슬라이드에서 몇 가지 팁과 노하우를 더 다루겠지만, 지연 시간과 LLM 관점에서의
00:13:00입장은 이렇습니다. 음, 자, 시간이 부족하니까
00:13:07속도를 좀 내겠습니다. 자, 여기에는 몇 가지 다른 방식들도 더 있습니다. 사람들이
00:13:12여러 모델을 조합해서 에이전트를 구축하기도 하는데요. 대화 부분에는
00:13:19훨씬 작고 가벼운 대화용 모델을 사용하고, 예를 들어 30억 파라미터 모델을 쓰고요,
00:13:24툴 호출용으로는 훨씬 더 큰 모델을 두어서
00:13:27툴 호출 성공률을 높이는 식입니다. 음,
00:13:35죄송합니다. 두 번째는, 음성 인식(Transcriptions)이 불안정할 것이라고 가정하라는 것입니다. 이것은
00:13:42AI 에이전트를 만들 때 마음속에 새겨두어야 할 원칙입니다. 시중에 나와 있는
00:13:49최고의 음성 인식 엔진을 쓰더라도 말이죠. 그 이유를 보여드리겠습니다. 시중에 나와 있는
00:13:55최첨단 음성 인식 엔진들은 대개 단어 오류율(WER)을 4~6% 수준으로 낮춰줍니다.
00:14:02물론 이것은 알려진 평가 세트 기준이고요. 현실 세계의 잡음이 섞인 통화에서는
00:14:10사람마다 다른 다양한 억양이나 도메인 전문 용어 등이 섞이면서
00:14:15단어 오류율이 두 자릿수로 치솟는 경우가 보통입니다.
00:14:21물론 오픈소스 모델을 가져다가 파인튜닝을 할 수도 있겠지만요,
00:14:25보통 어디서 문제가 자주 발생하는지 살펴보면 일정한 패턴이 존재합니다.
00:14:31고유명사, 전문 용어, 전화번호 같은 경우 뜬금없이 숫자가 누락되기도 하고요,
00:14:38잘못된 단어로 대체되기도 합니다. 이런 주소 문제들을 어떻게 해결하는지 몇 가지 예시를 통해
00:14:43짚어보겠습니다. 긴 주소를 수집하려고 할 때 음성 인식 엔진이
00:14:48주소의 일부를 그냥 놓쳐버릴 수도 있습니다. 언어간 코드 스위칭(Code-switch) 문제도 있죠. 제가 구사하는 언어의 예를 하나 들어보겠습니다.
00:14:55슬라이드에 넣기가 가장 쉬웠거든요. 예를 들어 영어이긴 한데 다른 문자로 적혀 있는 경우인데요,
00:15:01이것이 바로 힌디어에서 쓰이는 방식입니다. 맞죠? 이렇게 다른 문자로 적힌 영어인 셈이죠.
00:15:06반면 이것의 실제 영어 버전은 “hello, how are you?”입니다. 따라서 다른 국가의 청중을 상대할 때
00:15:11이처럼 언어간 코드 스위칭이 일어나고, 영어 음성이 엉뚱한 다른
00:15:16문자 체계로 인식되기 시작하면, 음성 인식 엔진부터 LLM 계층에 이르기까지
00:15:21모든 것이 망가지기 시작합니다. LLM이 엉뚱하게도 그 이상한 문자로 된 결과물을
00:15:26계속 뱉어내기 시작하고, 결국 TTS(음성 합성)까지 망가져 버리거든요. 알겠죠? 따라서 이것은
00:15:32매우 주의해야 할 부분입니다. 만약 음성 인식 엔진과 독립적으로 에이전트를 구축하고 싶다면,
00:15:38이 모든 것을 정규화하는 계층을 만들어야 합니다. 이에 대한 해결책은 잠시 후에 이야기해 보겠습니다.
00:15:44그리고 또 다른 사례로는 라틴 문자나 로마자로만 표기된 힌디어가 있습니다.
00:15:48말하자면 힌디어인데 읽기는 영어처럼 읽히는 경우죠. 이 역시 하위 시스템 전체를
00:15:54엉망으로 만들어 버립니다. 지금 든 예시들뿐만 아니라 아랍어, 만다린어,
00:15:59일본어 등 거의 모든 언어에 공통으로 적용되는 문제입니다. 그렇다면
00:16:04음성 인식 계층에서 실제로 확실한 변화를 만들어내는 것은 무엇일까요? 고유명사의 경우,
00:16:11단순히 키워드 부스팅만 사용하는 것은 권장하지 않습니다. 많은 음성 인식 엔진들이
00:16:16특정 단어를 엔진에 입력할 수 있는 키워드 부스팅 기능을 제공하지만,
00:16:21동적 키워드 부스팅을 사용하는 것이 좋습니다. 이게 무슨 뜻이냐면, 통화가 진행되는 내내 똑같은 키워드를 유지하지 말고
00:16:26그 답변이 필요하다고 판단되는 시점에만 동적으로 추가하라는 것입니다. 그래야 가장 높은
00:16:32정확도를 얻을 수 있습니다. 즉, 통화의 단계에 따라 음성 인식 엔진이 부스팅하는
00:16:38키워드가 국면별로 달라지게 하는 것이죠. 바로 이 방식이 가장 효과적이라는 것을 확인했습니다.
00:16:43만약 수많은 키워드로 음성 인식 엔진의 컨텍스트를 그저 오염시켜 버리면 다시 엉뚱한 소리를 만들어내기 시작하거든요.
00:16:49그렇기 때문에 이 방법이 가장 효과적입니다. 네, 그리고 LLM으로 트랜스크립트를 후처리하세요.
00:16:55LLM에는 도메인 컨텍스트가 있지만 음성 인식 엔진에는 없기 때문입니다. 그래서 인식된 단어 중에는
00:17:02말도 안 되는 것들이 많을 수 있습니다. 몇 가지 예를 들어보죠. 이것은
00:17:07음성 인식 엔진이 인식한 전화번호 데이터인데요. 저기 저 'E'가 뭐라고 생각하시나요?
00:17:13그렇죠? 이걸 LLM에 넘겨주면 저게 숫자 3이라는 걸 알아챕니다. 마찬가지로 저기 저 숫자 1도
00:17:18디지털 1이라는 것을 알 수 있죠. 음성 인식 엔진은 종종 이런 부분을 망가뜨리지만,
00:17:24LLM 계층으로 후처리하면 정보 수집 관점에서 즉시 바로잡을 수 있습니다. 제 말은,
00:17:30그리고 마지막으로 말씀드렸듯이, 음성 인식 출력 결과인 다국어 번역 표기(Transliteration) 역시
00:17:37LLM을 사용해 먼저 변환하거나 신경망 기반의 변환 엔진을 활용해 정규화해야 합니다.
00:17:46오픈소스 형태의 도구도 아주 많으니 그중 하나를 골라 쓰시면 됩니다.
00:17:49음성 인식 엔진과 상관없이 항상 정제된 트랜스크립트를 LLM으로 전송하세요.
00:17:55음성 인식 엔진과 관계없이 말입니다.
00:18:00좋습니다. 세 번째로 흔히 마주치는 문제는 데이터 수집입니다. AI 에이전트의 50~60%
00:18:05가 여기서 아주 심하게 망가진다고 생각합니다. 우리는 이걸 음성을 위한
00:18:14UX 문제로 바라보려 합니다. 즉, 트랜스크립트가 LLM으로 들어와서 그 내용을 파악하려 애쓰는 대신 데이터 모델을 생각하라는 거죠.
00:18:21여기에 참석하신 분들 대부분이 개발자이실 테니 개발 관점에서 영감을 얻어봅시다.
00:18:27파이썬의 데이터 클래스나 파이단틱(Pydantic),
00:18:32타입스크립트의 Zod, 혹은 UI의 폼 필드 같은 것에서 영감을 얻어보세요. 만약 이 문제에 대해
00:18:39그런 관점으로 접근하기 시작하면, 데이터 수집 측면에서 정확도가 30%에서 95%까지
00:18:46치솟는 것을 볼 수 있습니다. 그러니 질문하기 전에 형태를 먼저 결정하세요. 무언가를 개방형으로 두는 대신
00:18:52제약을 걸어두는 겁니다. 예를 들어 전화번호를 전화번호 타입 필드로 지정할 수 있을까요?
00:18:58그 순간 몇 자릿수가 필요한지 알 수 있게 됩니다. 그 위에 유효성 검사를
00:19:03추가할 수도 있고, 어떤 허용 가능한 값들이 들어올 수 있는지도 정의할 수 있죠. 따라서 앞서 본 예시에서
00:19:10전화번호 중간에 'E'가 끼어 들어왔을 때, 그것이 전화번호라는 걸 안다면
00:19:15스마트하게 숫자 3으로 유추해서 사용자에게 확인을 거치거나,
00:19:20아니면 오류임을 인지하고 유효성 검사를 통해 사용자에게 다시 말해달라고 요청할 수 있습니다.
00:19:26이것이 바로 수집 패턴 관점에서 우리가 봐온 흔한 방식 중 하나입니다.
00:19:31이름 수집은 아주 흥미로운 부분입니다. 제가 방금 발음하기 어려운
00:19:36이름을 하나 골라봤는데요. 인간이라도 이걸 제대로 알아듣기는 불가능합니다. 우리의
00:19:43음성 인식 엔진이 이걸 제대로 맞힐 리도 없고요. 몇 번을 시도하든 마찬가지일 겁니다.
00:19:47따라서 이 문제를 필드로 생각하기 시작하고, 규칙을 세운 뒤에
00:19:53철자를 한 자 한 자 확인하는 검증 메커니즘을 둘 때 비로소 제대로 맞출 수 있게 됩니다. 그렇지 않으면
00:19:58음성 통화로 이를 수집할 때 완전히 엉망이 되거든요. 그리고 이것은
00:20:03데이터 수집 측면에서 제가 말씀드리고 있는 내용의 한 가지 예시일 뿐입니다.
00:20:11상대적 값들, 즉 날짜 같은 데이터를 다룰 때도 상황이 극단적으로 나빠지곤 합니다.
00:20:18누군가 '다음 주 수요일 8시'라고 말하면 이는 오전 8시를 의미할 수도 있고 오후 8시를 의미할 수도 있습니다. 그리고
00:20:25그 날짜가 실제로 언제인지 파악하는 것 역시 매우 제약된 문제가 됩니다. 만약 이것이
00:20:30날짜/시간 필드라는 것을 알고 있고, 날짜/시간 필드를 수집하고 있다면 현재 날짜를 기준으로 삼고
00:20:35그에 맞춰 이 값이 무엇이 될지 계산해 낼 수 있겠죠. 바로 이런 방식으로 처리해야 합니다.
00:20:39LLM과 툴 호출의 조합을 통해 이 작업을 수행하는 것이죠. 여기서 툴 호출은
00:20:44필드 관점에서 이러한 무거운 작업들을 상당 부분 대신 처리해 줍니다.
00:20:50네. 그리고 단위 테스트 관점에서 이를 실행하는 것입니다. 따라서 모든 평가(evals)는
00:20:58이러한 필드들을 단위 테스트로 취급하기 시작해야 합니다. 그리고 단위 테스트들이
00:21:06에이전트가 어느 정도 신뢰할 수 있고 일관성 있게 작동할 것입니다. 여러분이 굳이,
00:21:10단 하나의 필드 수집에 문제가 생겼다는 걸 알기 위해 수백 개의 엔드투엔드
00:21:15에이전트 테스트 케이스를 실행할 필요가 없습니다. 평가를 필드 레벨과 단위 테스트 레벨에서 수행하세요.
00:21:24그리고 앞서 말씀드렸듯이, 이러한 사고방식을 가지면 프롬프트를 왕창 넣고 매번
00:21:30몇 글자씩 계속 수정하면서, 왠지 내 프롬프트 엔지니어링 덕분에 LLM이 훨씬 더 지시를 잘 따르고
00:21:36마법처럼 이런 사항들을 따르게 될 거라고 기대하는 대신, 모든 것이 훨씬 더 체계적으로 변합니다.
00:21:41사실, 말씀드린 것처럼 저희는 모델을 파인튜닝하지 않고도 95%, 97%의 정확도를 달성하는 것을 보아왔습니다.
00:21:47모델을 파인튜닝하지 않고도 95%, 97%의 정확도를 달성하는 것을 보아왔습니다.
00:21:53좋습니다. 그리고 요령은 기본적으로 에이전트가 거치는 구체적인 상태를 바탕으로,
00:21:57해당 시점에 에이전트가 무엇을 하고 있는지에 대한 컨텍스트를 잘게 쪼개는 것입니다.
00:22:04좋습니다. 시간 관계상 이 부분은 빠르게
00:22:10넘어가겠습니다. 3분밖에 안 남았네요. 버그이길 바라지만, 일단 이 정도로 넘어가죠.
00:22:16좋습니다. 자, 여기가 문제 발생하는 네 번째 영역입니다. 대부분의 사람들은 LLM 출력을 가져와서
00:22:24TTS로 보냅니다. 물론 시장에는 많은 복잡한 작업을 처리해 주는 훌륭한 TTS들이 많이 있지만,
00:22:30종종 엉망이 되곤 합니다. 저희가 권장하고 실제로 확인한 바에 따르면, 보통은 LLM과
00:22:37TTS에 입력되는 데이터 사이에 정규화 레이어를 두는 것이 좋습니다. LLM 출력을
00:22:43직접 TTS로 보내면 안 됩니다, 그렇죠? 몇 가지 예시를 통해 살펴보겠습니다.
00:22:50기본적인 것으로는, TTS로 합성하기 전에 이모지와 마크다운을 제거하는 것입니다.
00:22:58대부분의 오케스트레이션 파이프라인은 LiveCAD나 PipeCAD 같은 경우 플래그 몇 개만 설정하면
00:23:02이를 대신 처리해 줍니다. 하지만 이런 도구를 쓰지 않거나 직접 구축하는 경우라면,
00:23:08읽어주는 내용에 이모지가 나타나거나 마크다운이 그대로 노출되는 것을 원치 않을 테니
00:23:12이 부분을 명시적으로 설정해 주어야 합니다.
00:23:17좋습니다. 좀 더 흔한 예로 사용자 지정 사전을 들 수 있습니다. 대부분의 TTS 엔진은
00:23:23고유명사, 브랜드, 약어 등 사용자 지정 단어를 어떻게 발음할지 설정하는 기능을 제공합니다.
00:23:30따라서 LLM 출력이 TTS로 넘어갈 때 이 설정을 적용해야 합니다. 그렇지 않으면 발음이 엉망이 되거든요.
00:23:36우리가 이를 어떻게 테스트하는지 예시를 보여드리겠습니다.
00:23:40다른 하나는 대부분의 엔진이 속도 조절 기능도 제공한다는 점입니다. 특정 개체를 발음할 때
00:23:47에이전트의 속도를 0.8배나 0.7배로 늦춰서 해당 개체를 정확히 발음할 수 있도록 하세요.
00:23:54특정 개체에 대해 정확히 발음하고 이메일이나 전화번호,
00:24:00이름의 철자를 하나씩 읽을 때 발음이 꼬이지 않도록 합니다. 그리고 이메일, 통화, 날짜 같은 복잡한 요소들은 모두 정규화하세요.
00:24:09TTS에만 맡겨두지 마세요. 대부분 처리할 수 있긴 하지만,
00:24:15TTS에만 의존하지 마세요. 자체적인 정규화 계층을 직접 구축하여, 나중에 TTS를
00:24:21교체해야 하거나 어떤 이유로 첫 번째 서비스에 장애가 생겨서
00:24:25다른 TTS를 사용하고 싶을 때, TTS 엔진에만 의존하지 않고 이를 직접 관리할 수 있도록
00:24:32내부에 구축하는 것이 좋습니다. 그리고 음, 제 배지가 여기에 없는데, 제 성이 거기에 안 나와 있네요.
00:24:39그래서 제 첫 번째 테스트는 제 성이나 회사 이름을 제대로 발음하지 못하면
00:24:44이미 기본도 못 하고 있는 겁니다. 제 성은 '발라수브라마니안'인데,
00:24:50음성 AI 에이전트를 사용해 이 이름을 제대로 발음하지 못한다면, 제 기준에서는 탈락입니다. 저는 알 수 있죠,
00:24:56에이전트가 매일 철자를 그대로 읽어야 하는 많은 단어들을 제대로 발음하지 못할 거라는 걸요.
00:25:04두 번째는 저희 회사 이름인 Pliwo입니다. 많은 엔진들이 이를 Pliwo나
00:25:09기타 여러 방식으로 발음합니다. 하지만 파이프라인에서 이를 제어할 수 있다는 점이
00:25:16매우 중요합니다. 만약 고객 대상 제품을 구축하고 계신다면,
00:25:21이러한 옵션을 고객에게 제공하는 것이 좋습니다. 좋습니다,
00:25:26마지막 두 슬라이드는 빠르게 훑고 넘어가겠습니다. 시간이 꽤 많이 지났거든요.
00:25:32발화 종료 감지는 별도의 주제이지만, 핵심 포인트들을 빠르게
00:25:36띄워드려서 여러분이 훑어보실 수 있도록 하겠습니다. 이 후에 따로 이야기가 필요하다면
00:25:41그때 이야기 나누면 됩니다. 이 화면을 5초 정도만 띄워두고
00:25:49오프라인에서 이야기 나누도록 하겠습니다. 시간이 꽤 초과되었네요. 그리고 마지막으로,
00:25:53마지막 주제는 끼어들기와 백채널링입니다. 이와 관련된 기능을 수행하는
00:25:58음성 대 음성 모델에 대한 이야기가 많지만, 저희는 음성 대 음성 파이프라인에서 이 모든 것을
00:26:03어떻게 구현할 수 있는지 확인해 보았습니다. 이 모든 것을 구현하는 데 굳이 음성 대 음성 모델이 꼭 필요한 것은 아닙니다.
00:26:07이 역시 슬라이드에 띄워두는 것으로 갈음하고 마무리하겠습니다. 음,
00:26:15알겠습니다. 질문을 받을 시간은 없을 것 같네요. 혹시 시간이 있으시다면 나중에 개별적으로 질문해 주세요.
00:26:19아무쪼록 이번 내용이 수십억 건 규모의 프로덕션 환경에서 저희가 확인하고 있는 바에 대해
00:26:24통찰을 얻는 데 유익한 시간이 되었기를 바랍니다. 감사합니다.
00:26:29다음에 뵙겠습니다.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video