TL;DR / Key Takeaways
당신의 음성봇은 언어적으로 갇혀 있습니다.
어떤 스마트 스피커에 질문을 영어로 해보세요, 그런 다음 문장 중간에 스페인어로 바꿔보세요. 대부분의 시스템은 멈추거나, 잘못 전사되거나, 잘못된 언어로 이상한 대답을 하곤 합니다. 오늘날의 주류 음성 인식 기술은 효과적으로 단일 언어로 동기화되어 작동합니다: 한 세션당 하나의 언어, 설정 메뉴에서 선택하거나 개발자가 하드코딩한 언어입니다.
인간은 반대로 행동합니다. 이중 언어 사용자들은 "내일의 예약을 할 수 있어요?"와 같이 "코드 스위칭"을 끊임없이 하며, 어떤 모델이 어떤 지역을 지원하는지에 대해 생각하지 않습니다. 런던, 뉴욕, 또는 멕시코시티와 같은 도시에서는 단 하나의 대화가 10초도 안 되어 영어, 폴란드어, 프랑스어 사이를 넘나들 수 있으며, 누구도 먼저 자신의 언어를 선언하기 위해 양식을 작성하지 않습니다.
음성 AI는 주로 휴고 포드가 Tier 1이라고 부르는 영역에 존재합니다: 여러 언어를 처리할 수 있지만, 어떤 언어를 기대해야 하는지를 사전에 알려줘야만 가능합니다. 이는 고정된 통화 흐름과 IVR에서는 잘 작동하지만, 발신자가 영어로 "스페인어를 할 수 있나요?"라고 묻고 실제로 스페인어로 전환할 경우에는 문제가 발생합니다. 상담원은 계속해서 영어로 답변하거나, 더 나쁜 경우, 전사 내용을 엉망으로 만들어 LLM을 혼란스럽게 만듭니다.
Tier 2는 업그레이드입니다: 문장 중간에 언어를 감지하고 전환하는 다국어 에이전트로, 수동 전환 없이, "스페인어는 2번을 누르세요" 없이, 재시작 없이 진행됩니다. 사용자가 영어로 시작했다가 폴란드어로 전환하고, 프랑스어 문구를 추가할 수 있으며, 시스템은 이를 모두 실시간으로 추적합니다. 이러한 유연함 덕분에 음성봇은 설정 패널이 아니라 대화로 변화합니다.
Tier 2 에이전트를 구축하기 위해서는 세 가지 요소가 긴밀히 협력해야 합니다: - 실시간 오디오와 에이전트 로직을 조율하는 스마트 프레임워크인 LiveKit - 여러 언어로 자연스럽게 응답할 수 있는 강력한 두뇌 (LLM) - 낮은 지연 시간과 높은 정확도로 코드 전환을 수행하는 하이퍼 인식 귀 (STT)
대부분의 LLM(대형 언어 모델)과 텍스트 음성 변환 엔진은 여러 언어를 상당히 잘 처리합니다. 진짜 병목 현상은 "스페인어를 할 수 있나요?"라는 질문을 듣고 나머지 문장이 스페인어로 올 때 끊김 없이 계속해서 멀티링구얼 이해를 하는 음성 인식 기술입니다. 재구성이나 하드 리셋 없이 단순히 지속적인 이해가 필요한 상황입니다.
1유형 vs. 2유형: 다국어 간극
1티어 다국어 에이전트는 문서상으로는 유연해 보입니다: 하나의 시스템, 다양한 언어. 하지만 실제로는 누군가 한마디를 하기 전에 미리 언어를 선언해야만 작동합니다. “스페인어”, “폴란드어” 또는 “프랑스어”를 세션 매개변수로 설정하면, 전체 대화는 그 선택에 고정됩니다.
그 디자인은 IVR 전화 트리부터 고객 지원 봇에 이르기까지 어디에서나 나타납니다. 드롭다운에서 선택하거나 “2번을 눌러 스페인어 선택” 또는 깃발 아이콘을 탭하면, 그때서야 음성-텍스트 변환 파이프라인이 올바른 음향 및 언어 모델을 로드합니다. 통화 중간에 마음을 바꾸거나 다른 언어를 섞으면 시스템이 당신의 말을 잘못 듣거나 전환을 무시하게 됩니다.
물류적으로, 1단계는 외형적으로 어색함이 느껴집니다. 양식에는 추가적인 "선호 언어" 필드가 필요하고, 통화 흐름에는 메뉴가 필요하며, 키오스크는 시작하기 위해 UI 편의성을 요구합니다. 추가 단계가 많아질수록 마찰과 이탈이 증가합니다. 많은 소비자 앱은 onboarding 과정이 10-20초 이상 소요되면 사용자 이탈이 발생합니다.
2단계 다국어 상담원은 다르게 작동합니다. 그들은 먼저 듣고, 사전에 선언하지 않고 사용하고 있는 언어 또는 언어들 중 어떤 것을 사용할지 즉석에서 결정합니다. 대화는 영어로 시작했다가 질문을 위해 스페인어로 바뀌고, 그 후 폴란드어로 넘어갈 수 있으며, 상담원은 이러한 전환을 실시간으로 추적합니다.
그 변화는 다국어 기능을 단순한 체크박스 옵션에서 실제 대화 유창성으로 전환합니다. Tier 2 시스템은 사용자가 “Can you send the factura to my work email?” 또는 “Czy mówisz Spanish as well?”과 같이 하나의 문장에서 언어를 혼합할 수 있는 자연스러운 “코드 스위칭”을 지원합니다. 상담원은 각 언어 전환에서 타이핑하고, 사고하며, 적절하게 응답해야 합니다.
글로벌 제품의 경우, 2단계는 골드 스탠다드입니다. 하나의 에이전트가 별도의 전화번호, 별도의 봇, 또는 복잡한 언어 라우팅 규칙 없이 수십 개의 시장에서 사용자에게 서비스를 제공할 수 있습니다. 기업들은 영어, 프랑스어, 폴란드어에 대한 평행 흐름을 유지하는 대신, 사용자가 말하는 언어에 맞춰 조정되는 단일 논리 계층을 배포합니다.
Hugo Pod의 "LiveKit & Gladia로 다국어 음성 에이전트 구축하기"는 명확하게 이 Tier 2 모델을 목표로 하고 있습니다. 낮은 지연 시간의 코드 전환을 위해 Gladia를 사용하고, 실시간 오디오를 위해 LiveKit을 활용하여, 그의 스택은 더 높은 기준을 추구합니다: 양식처럼 행동하기보다는 사람처럼 행동하는 에이전트입니다.
'코드 스위칭'이 왜 성배인가?
코드 스위칭은 이중언어를 사용하는 사람들이 생각하지 않고 문장 중간에 언어를 전환하는 방식을 설명합니다: "Oye, 보고서 보냈어?" 또는 "Ça marche, 나중에 연락할게." 심리언어학자들은 이를 결점이 아닌 특징으로 봅니다. 연구에 따르면 이중언어 사용자는 주제, 감정, 대화 상대에 따라 언어를 전환하며, 종종 분당 여러 번 발생합니다.
AI 음성 에이전트에게 그 행동은 성배입니다. 스페인어를 사용하는 고객이 IVR 메뉴를 위해 영어로 시작하다가 요금 문제를 설명하기 위해 스페인어로 넘어갔다가 카드 번호를 위해 다시 영어로 돌아가는 경우가 있을 수 있습니다. 첫 언어에서 멈추는 시스템은 신뢰, 시간, 그리고 종종 사용자를 잃게 됩니다.
실제 상황에서는 위험이 큽니다. 멕시코 시티, 마닐라 또는 바르샤바의 글로벌 지원 센터는 영어와 2~4개의 지역 언어를 동시에 처리하며 일상적으로 작업을 수행합니다. 핀테크, 여행, 또는 SaaS 분야의 국제 영업 전화는 영어, 힌디어, 그리고 지역 방언 간에 오갑니다. 뉴욕이나 런던과 같은 도시의 공공 서비스는 의료, 주거, 교육 분야에서 혼합 언어 대화를 처리해야 합니다.
기술적으로 보자면, 원시 오디오는 언어적 맥락 없이는 모호하기 때문에 잔인합니다. 2초 길이의 클립은 영어, 폴란드어 또는 포르투갈어에서 그럴듯한 단어들과 연결될 수 있으며, 이들 모두는 다른 의미를 가집니다. 배경 소음, 억양 및 분야 전문 용어는 혼란을 증폭시키기 때문에 단순한 모델은 잘못된 언어에 “잠금”되어 회복하지 못합니다.
세 가지 기둥인 STT(음성 인식), LLM, TTS는 언어 선택에 있어 완벽하게 동기화되어야 합니다. LLM은 이미 다국어 프롬프트를 잘 처리하고 있으며, 11 Labs와 같은 현대적인 TTS 엔진은 깨끗한 텍스트를 받으면 설득력 있는 폴란드어 또는 스페인어로 말할 수 있습니다. 음성 인식이 진정한 보스 전투입니다.
다국어 음성 인식(STT)은 자연스러운 통화를 위해 약 300ms 이하의 지연 시간 내에 때때로 단어 하나에서 언어 경계를 실시간으로 감지해야 합니다. "그것은 영어로 'no'였는지, 포르투갈어로 'não'였는지?"를 즉석에서 결정하고 즉시 모델이나 어휘를 전환해야 합니다. Gladia의 코드 스위칭 모델 및 Voice AI 빠른 시작 | LiveKit 문서에 문서화된 프레임워크와 같은 도구들이 등장하고 있지만, 완벽한 코드 스위칭은 여전히 해결해야 할 문제로 남아 있습니다.
유동적인 대화를 위한 기술 스택
현대 코드 스위칭 음성 AI는 네 가지 기둥 위에 서 있습니다: 실시간 라우팅, 음성 인식, 언어 추론, 그리고 합성 음성. 이 중 하나를 더 약한 구성 요소로 교체하면 유창한 이중 언어 대화의 전체 환상이 즉시 깨집니다.
중앙에는 LiveKit이 자리하고 있습니다. 이는 에이전트의 신경 시스템처럼 작동하는 실시간 커뮤니케이션 프레임워크입니다. 저지연 오디오 스트림, 세션 상태 및 백프레셔를 관리하여 오디오 패킷, 전사 및 응답이 몇 초가 아닌 수백 밀리초 이내에 도달하도록 보장합니다.
LiveKit은 스택의 서로 다른 부분을 각각 소유하는 세 가지 전문 서비스를 연결합니다: - Gladia 음성 인식 - OpenAI GPT-4.1 언어 이해 - 11Labs 음성 합성
글라디아는 에이전트의 귀 역할을 하며, 사용자가 아직 말을 하고 있는 동안 원시 오디오를 지속적으로 텍스트로 변환합니다. SEA SALARIA 1 변종과 같은 다국어 모델은 수십 개의 언어 간 코드 스위칭을 지원하며, 세션을 리셋하지 않고 영어에서 스페인어, 스페인어에서 폴란드어로 문장이 전환될 때 이를 감지합니다.
그 코드 전환 능력이 중요한 이유는 음성 인식이 이 체인에서 가장 취약한 고리이기 때문입니다. 만약 Gladia가 스페인어를 억양이 있는 영어로 잘못 라벨링하면, GPT-4.1은 올바른 단어를 보지 못하고, 전체 “다국어” 경험은 무의미한 질문이나 어색한 명확화 질문으로 무너집니다.
글라디아가 텍스트를 발신하면 OpenAI GPT-4.1이 두뇌 역할을 합니다. 이 LLM은 대화 이력, 사용자의 의도, 언어의 변화를 추적한 후, 단순히 무엇을 말할지를 결정하는 것이 아니라 어떤 언어로 말할지도 결정합니다. 프롬프트는 GPT-4.1이 자동으로 사용자의 언어를 반영하도록 하거나 명시적으로 요청할 때 전환하도록 유도할 수 있습니다 (“¿Puedes hablar polaco?”).
11Labs는 음성으로서의 연결 고리를 완성합니다. 폴란드어, 프랑스어 또는 영어 토큰을 입력하면 같은 언어로 자연스럽게 들리는 오디오를 반환하며, 동일한 합성 음성을 사용하여 에이전트가 여러 시스템의 조합이 아닌 일관된 개체로 느껴지도록 합니다.
LiveKit, Gladia, GPT-4.1, 그리고 11Labs가 함께 실시간으로 긴밀하게 연결된 회로를 형성합니다. 오디오가 들어오고, 언어 인식 텍스트가 흐르며, 정확하게 로컬라이즈된 음성이 출력됩니다. 이 과정은 빠르게 이루어져 코드 스위칭이 마치 앱을 전환하는 것처럼 자연스럽게 느껴집니다.
STT 병목 현상: 왜 글라디아가 핵심인가
음성 인식은 다국어 음성 에이전트가 성공할지 실패할지를 조용히 결정합니다. 영어에서 스페인어, 다시 폴란드어로 이어지는 단일 문장에서 전화를 따르는 Tier 2 시스템에게 STT는 나머지 기술 스택 중에서 가장 어려운 부분입니다. LLM과 TTS는 이미 깨끗한 텍스트에서 수십 개의 언어를 처리할 수 있지만, STT는 시끄럽고 겹치며 강한 억양의 오디오를 실시간으로 처리해야 합니다.
Gladia의 sea-salaria-v1 모델은 그 접점을 가지고 있습니다. 이 모델은 기본적으로 40개 이상의 언어를 지원하며, 자연스러운 코드 스위칭 기능을 갖추고 있어 "Can you call mi mamá en Madrid?"와 같은 문장을 하나의 뒤섞인 언어로 혼란스럽게 만들지 않습니다. 대신, 실제 파형에 나타나는 대로 영어와 스페인어를 깔끔하게 구분하고 전사합니다.
지역 라우팅은 sea-salaria-v1이 데모에 국한되지 않고 실시간 제품에 대해 실행 가능해지는 곳입니다. Gladia는 EU 웨스트와 같은 특정 지역에 프로세싱을 고정할 수 있게 해주므로, 사용자가 런던이나 파리에 있을 경우 대서양을 넘는 지연 100-200 ms를 피할 수 있습니다. 음성 에이전트의 경우, 이 지연을 줄이는 것은 상호 응답을 ~300 ms 이하로 유지하여 "AI 정지"가 분명해지는 상황을 방지할 수 있습니다.
직접 오디오에서 언어 변화를 감지할 수 있는 STT 엔진 없이는, 파이프라인의 다른 어떤 것도 스마트할 기회가 없습니다. LLM은 자신이 받는 텍스트 전사만을 볼 수 있습니다. 만약 STT가 폴란드를 영어로 잘못 라벨링하고 무의미한 토큰을 출력하면, 어떤 우수한 모델도 자신 있게 잘못된 언어로 응답할 것입니다. 이후 TTS는 그 실수를 사용자에게 기쁘게 전달하여 실패를 고착화합니다.
STT 계층에서의 코드 스위칭 지원은 취약한 사전 라우팅 해킹을 방지합니다. 이제는 전화번호, 메뉴 선택 또는 첫 문장으로 발신자의 언어를 추측할 필요가 없습니다. Sea-salaria-v1은 시작부터 사용자의 언어 변경을 인식하고, 영어 지침에서 빠른 프랑스어로 전환한 것을 감지하여 즉석에서 문자 세트와 언어 모델을 조정할 수 있습니다.
Deepgram과 다른 STT 제공업체들은 다국어 및 코드 스위칭 기능을 광고하지만, 이는 많은 경우에 효과적입니다. 그러나 이 특정 Tier 2 에이전트의 경우, Gladia는 혼합 언어 오디오에서의 기본 전사 정확도에서 우위를 점했습니다. 특히 빠른 스위치와 영어-폴란드어와 같은 덜 일반적인 조합에서 더욱 그렇습니다. 전체 경험이 이러한 엣지 케이스를 정확하게 처리하는 데 달려 있다면, 그 정확도 차이는 결정적입니다.
라이브킷 에이전트 프레임워크를 통한 오케스트레이션
LiveKit는 더 이상 단순한 WebRTC 라우터로 작동하지 않습니다; 이제 전체 통화 루프를 소유하는 에이전트 런타임처럼 행동합니다. STT, LLM, TTS를 수동으로 연결하는 대신, 이벤트—오디오 프레임, 메시지, 타임아웃—에 반응하는 에이전트를 정의하면 LiveKit가 나머지를 실시간으로 조율합니다.
중심에는 LiveKit 에이전트 프레임워크가 있으며, 이는 미디어 파이프라인 가까이에서 Python(또는 Node) 로직을 실행합니다. 이 근접성은 중요합니다: 미디어, 추론, 비즈니스 로직 간의 홉이 줄어들면 엔드 투 엔드 지연 시간이 낮아져 코드 전환 음성 에이전트의 생명선이 됩니다.
LiveKit Inference는 관리되는 LLM 및 TTS 계층으로 이 루프에 직결됩니다. 에이전트를 OpenAI, 로컬 또는 공급업체 호스팅 모델에 지정하면 LiveKit이 토큰을 스트리밍하고 오디오를 반환하는 과정을 처리하므로 세 가지 다른 SDK를 별도로 다룰 필요가 없습니다.
LiveKit Inference를 사용하면 많은 운영상의 문제를 피할 수 있습니다. 각 공급업체의 LLM 및 TTS 호출에 대한 속도 제한을 피하고, 사용량을 하나의 청구서로 통합하며, LiveKit이 공용 API 게이트웨이가 아닌 엔터프라이즈 등급의 링크를 통해 공급업체와 통신하기 때문에 종종 더 낮은 지연 시간을 경험할 수 있습니다.
청구 통합은 단순한 편의성이 아닙니다; 이는 아키텍처 설계를 변화시킵니다. 각 공급업체에 대해 맞춤형 제한 및 대체 로직을 구축하는 대신, 추론을 예측 가능한 할당량과 모니터링이 있는 단일 리소스 풀로 취급합니다.
LiveKit의 구조는 구성 요소 교체를 거의 기계적으로 만듭니다. Hugo Pod의 agent.py에서는 Gladia가 간단한 구성 블록을 통해 STT 공급자로 연결됩니다: 모델 이름(시 아살라리아 1), 지역(EU West), 지원 언어 목록.
그 디자인은 여러분이 대담하게 실험할 수 있음을 의미합니다. 두 개의 TTS 목소리나 두 개의 LLM 프롬프트를 A/B 테스트하고 싶으신가요? 에이전트 정의의 몇 줄을 변경하면 됩니다; LiveKit은 여전히 세션 상태, 미디어 라우팅 및 재연결 로직을 처리합니다.
원시 WebRTC 또는 DIY gRPC 서비스를 사용하는 팀에게는 이는 다른 추상화 수준입니다. 소켓과 코덱에 대한 생각을 중단하고 “에이전트 세션”과 수평으로 확장할 수 있는 “작업”에 대해 생각하기 시작합니다.
LiveKit의 문서는 이 모델에 초점을 맞추고 있습니다. 음성 에이전트 구축 | LiveKit 문서는 백그라운드 작업, 다중 에이전트 라우팅, 그리고 다국어 프로젝트 전반에서 재사용할 수 있는 맞춤형 도구와 같은 패턴을 안내합니다.
뇌와 목소리: LLM 및 TTS를 위한 간편한 승리
현대 LLM은 언어를 주거니 받거니 하라고 요청해도 거의 힘들어하지 않습니다. GPT-4 클래스의 모델들은 다국어 웹, 책, 포럼, 코드 저장소에서 수조 개의 토큰을 수집하여 훈련하며, 영어와 스페인어부터 폴란드어 및 특수 방언까지 모든 것을 포괄합니다. “프랑스어로 대답하고, 그 후 영어로 요약해 줘”라고 요청하면, 토큰 단위로 그대로 수행합니다.
그 다국어 행동은 추가적인 기능이 아니라, 이러한 모델들이 학습하는 방식에서 비롯됩니다. 훈련 과정에서 이들은 서로 다른 언어로 표현된 병렬 개념을 보며 거대한 공유 임베딩 공간을 최적화합니다. 그래서 사용자가 “Can you book a flight?”에서 “para mañana a Madrid”로 문장 중간에 전환할 때, 모델은 단순히 가장 가능성이 높은 다음 토큰을 스페인어로 예측하기를 계속합니다.
프롬프트를 사용하면 정밀한 제어가 가능합니다. LLM에게 "항상 호출자의 언어로 응답하라" 또는 "영어로 말하되 인용된 외국어 구문을 반영하라"고 지시할 수 있습니다. 단일 시스템 메시지로 동일한 GPT-4 인스턴스가 독일어로 고객 지원을 처리하고, 포르투갈어로 기술 교육을 진행하며, 영어로 후속 질문에 응답할 수 있습니다. 모든 것이 하나의 연속 세션에서 가능하죠.
출력 측면에서 TTS 시스템인 11Labs는 훨씬 더 간단합니다. 이 시스템은 사용자가 어떤 언어를 의미했는지를 추론할 필요가 없으며, 이미 사용 중인 텍스트의 언어를 그대로 합성합니다. 폴란드어 텍스트를 입력하면 폴란드어 오디오가 생성되고, 프랑스어로 바꾸면 프랑스어 오디오가 생성되며, 종종 언어에 따라 일관된 목소리 톤을 유지합니다.
다국어 TTS는 주로 두 가지에 의존합니다: 언어 지원 범위와 음성 품질. 만약 제공자가 예를 들어 28개 언어와 다국어 음성을 지원한다면, 귀하의 앱은 영어에서 스페인어, 폴란드어로 실시간 전환하면서도 동일한 “에이전트 페르소나”를 유지할 수 있습니다. 재구성 필요 없이, 언어마다 별도의 음성이 필요하지 않습니다.
모든 우아함은 LLM에 들어가는 단어들이 잘못되면 무너집니다. 진정한 마법과 실질적인 위험은 STT의 상류에 있으며, Gladia와 같은 모델이 언어 변화를 감지하고, 이를 정확하게 분할하며, LLM에 깨끗하고 코드 스위치된 전사(copy)를 전달해야 합니다.
에이전트의 해부학: 코드 심층 분석
Agent.py는 이 다국어 설정의 배선도 역할을 하며, 거의 모든 마법은 맞춤 알고리즘이 아닌 구성에서 나옵니다. Hugo는 GladiaSpeechToText, LiveKit의 추론 서비스, 그리고 일부 대화 제어를 하나의 실시간 루프로 묶는 단일 `Agent`를 정의합니다.
음성 인식은 가장 세밀한 조정을 받습니다. `GladiaSpeechToText` 블록은 세 가지 중요한 매개변수를 지정합니다: `model="sea-salaria-1"`, `region="eu-west"`, 그리고 `languages` 배열입니다. `sea-salaria-1` 모델은 Gladia의 코드 전환 작업을 위한 중심 역할을 하며, 영어, 스페인어, 폴란드어 등 사이의 중간 문장 전환을 처리하도록 설계되었습니다.
지역 선택은 지연 시간에 중요합니다. 런던에서 `region="eu-west"`를 지정함으로써, 휴고는 기본 미국 엔드포인트를 통해 대서양을 가로질러 오디오가 전달되는 대신 왕복 시간을 낮게 유지합니다. 많은 STT 제공업체들이 지역 라우팅을 숨기지만, 글라디아는 이를 직접 드러내며, 이는 드물고 실시간 음성에 매우 유용합니다.
`languages` 매개변수는 여기에 1단계에서 2단계로 넘어가는 부분입니다. 모델에게 “이 통화는 프랑스어입니다”라고 말하는 대신, Hugo는 허용된 옵션 목록을 전달합니다. 예를 들면: - `"en"` - `"fr"` - `"es"` - `"pl"` 그런 다음 Gladia는 특정 순간에 어떤 언어가 사용되고 있는지를 자동으로 감지하고 실시간으로 전사 규칙을 전환합니다.
LiveKit의 측면은 비교할 때 거의 지루해 보이지만, 그것이 바로 요점입니다. LLM 추론을 위해 Hugo는 `"gpt-4o-realtime-preview"`와 같은 모델을 사용하는 `LiveKitInference` 클라이언트를 연결하고, 짧은 시스템 프롬프트인 “당신은 유용한 음성 비서입니다.”를 추가합니다. 추가적인 다국어 플래그나 라우팅 논리 없이, 이미 수십 개의 언어를 이해하는 하나의 모델만 있습니다.
텍스트 음성 변환은 동일한 패턴을 사용합니다: 선택한 음성 ID가 있는 `"eleven_multilingual_v2"`와 같은 모델을 가리키는 `LiveKitInference` TTS 클라이언트입니다. TTS 엔진이 목표 언어를 지원하는 한, 폴란드어 또는 스페인어 텍스트를 제공하는 것은 간단하게 작동하므로 코드는 거의 구성 전용으로 유지됩니다.
턴 테이킹은 작은 구성 변경이 사용자 경험에 극적으로 영향을 미치는 부분입니다. Hugo는 LiveKit의 `turn_detection` 모델을 `"english"`에서 `"multilingual"`로 변경하여 에이전트가 비영어 언어와 혼합 언어 문장에서 올바르게 정지 및 발화 종료를 감지할 수 있도록 합니다.
마지막으로, `preemptive_generation=False`는 에이전트가 사용자의 말을 가로채는 습관을 비활성화합니다. 많은 실시간 시스템은 사용자가 말을 끝낸 것처럼 인식하면 즉시 말을 시작합니다. 이는 사용자가 다른 언어로 조항을 추가할 때 코드 스위칭을 방해합니다. 에이전트가 명확한 발언 경계를 기다리도록 강제함으로써 대화를 자연스럽게 유지하고 중간에 말을 가로막는 것을 방지할 수 있습니다.
데모 분석하기: 영어에서 폴란드어로
데모에서 코드 스위칭 순간은 꽤 순수하게 시작된다. 사용자는 영어로 시작하여 에이전트와 Tier 1 시스템처럼 대화한다. 그러다 갑자기 대다수의 프로덕션 보이스봇을 무너뜨릴 만한 전환점이 등장한다: “폴란드어를 할 수 있는지 궁금합니다.”
대신 영어로 답변하거나 멈추는 대신, 에이전트는 즉시 전환합니다. 유창하고 자연스러운 폴란드어로 답변하며, TTS 스택에서 올바른 음성 진행과 억양으로 언어 전환이 리셋 없이 모든 설정에서 수용되었음을 알립니다. 수동 언어 전환, 재초기화, "언어 전환 중, 잠시 기다려 주세요" 지연이 없습니다.
중요한 것은 다음에 일어나는 일입니다. 사용자는 폴란드어로 계속해서 대화를 나누며 완전히 그 언어로 진행됩니다. 에이전트는 후속 폴란드어 문장을 이해하고 맥락을 유지하며 일관되고 주제에 맞는 폴란드어 답변을 제공합니다. 이는 다국어 제품들이 약속하지만 좀처럼 실현하지 못하는 Tier 2 행동입니다.
그 성능은 STT에 기반하고 있습니다. Gladia의 모델은 영어로 시작된 오디오를 받아서 대화 중간에 폴란드어로 전환되더라도 여전히 낮은 지연 시간으로 정확한 전사를 생성합니다. 이러한 전사 품질이 LLM이 "영어 모드"와 "폴란드어 모드" 스레드를 생성하는 대신 단일 대화 상태를 유지할 수 있게 해줍니다.
실행 로그에서 흥미로운 문제가 드러납니다: `턴 감지가 폴란드어를 지원하지 않습니다`. 턴 감지는 사용자가 말을 마쳤을 때를 결정하는 과정으로, 이 경고는 보조 구성 요소가 특정 언어만을 구분할 수 있음을 나타냅니다. 그럼에도 불구하고 시스템은 눈에 띄는 지연 없이 계속해서 폴란드어를 안정적으로 인식하고 기록합니다.
이것은 미묘하지만 중요한 건축적 요소입니다. 언어 제한이 있는 턴 감지기와 같은 비핵심 구성 요소가 경고를 발생시키면서 주요 **Gladia** 전사 엔진은 여러 언어에서 완벽하게 작동할 수 있습니다. 실제 배포에서 이러한 관심사 분리는 경험을 실제로 뒷받침하는 다국어 브레인에 위험을 초래하지 않고 부가 모듈에서 반복적으로 개선할 수 있다는 것을 의미합니다.
미래는 다국어를 구사하는 AI입니다.
다국어 에이전트는 LiveKit와 같은 고급 프레임워크를 특정 목적에 맞게 설계된 STT 엔진인 Gladia에 연결하면 더 이상 연구 장난감에 그치지 않습니다. LiveKit은 복잡한 실시간 연결—WebRTC, 세션, 에이전트 생명주기—을 처리하는 반면, Gladia의 저지연 코드 스위칭 모델(그의 sea-salaria-1 변형과 같은)은 일반 모델들이 여전히 미숙한 한 가지 작업, 즉 같은 발화 속에서 여러 언어를 탐지하고 전사하는 일을 수행합니다. 이러한 조합은 단순한 음성 봇을 인간 대화를 추적할 수 있는 2급 에이전트로 업그레이드하여 인간에게 시스템 설정을 따라가게 하는 것이 아니라 그 반대로 만들 수 있게 합니다.
함께 쌓인 이 요소들은 실제로 글로벌 규모에서 작동하는 제품을 열어줍니다. 단일 지원 라인은 멕시코시티, 바르샤바, 파리의 고객을 동일한 다국어 음성 에이전트로 안내할 수 있으며, 고객이 제품 이름은 영어로, 나머지는 모국어로 전환할 때 따라갑니다. IVR 트리도 없고, “스페인어를 원하시면 3번을 누르십시오”라는 안내도 없으며, 대신 실시간으로 적응하는 단일 엔드포인트만이 존재합니다.
회의도 변합니다. 참가자들이 영어, 독일어, 폴란드어를 번갈아 사용하는 10인 통화에서 듣는 Zoom 또는 Meet 동반자를 상상해 보세요. 이 동반자는 다음을 생성합니다: - 각 참가자의 선호 언어로 실시간 자막 - 화자와 언어에 태그가 달린 검색 가능한 전사 - 코드 스위칭이 언제, 왜 발생했는지를 보존하는 요약
소비자 보조 역할도 마찬가지로 혜택을 누립니다. 이중 언어를 사용하는 가족은 영어로 가정용 기기에 이야기하다가, 문장 중간에 할머니를 위해 프랑스어로 전환한 후, 다시 무선 단어 재설정이나 앱 설정 변경 없이 원래 언어로 돌아올 수 있습니다. 사용자가 "기본" 언어에 대한 숙련도가 낮을 때 더 이상 이해받기 위해 그것에 얽매이지 않아도 되므로 접근성이 향상됩니다.
한때 연구실을 필요로 했던 장벽들—빠른 ASR, 강력한 코드 전환, 저지연 스트리밍—이제는 주말 프로젝트에 들어맞습니다. LiveKit은 실시간 스택을 추상화하고, Gladia는 다국어 STT를 처리하며, 주류 LLM과 TTS는 이미 여러 언어를 기본적으로 지원합니다. 이제 어려운 부분은 "이것을 구축할 수 있는가?"에서 "이 에이전트는 실제로 무엇을 해야 하는가?"로 바뀌었습니다.
그것은 당신이 스스로 답할 수 있습니다. “How to Build a Multilingual Voice Agent with LiveKit & Gladia”에서 GitHub 레포를 확인하고, 자신의 프롬프트와 음성을 입력한 후, 사용자들이 서로 대화하는 방식으로 사용자에게 말하는 에이전트를 배포하기 시작하세요.
자주 묻는 질문
AI 코드 스위칭이란 무엇인가요?
코드 스위칭은 AI 음성 에이전트가 같은 대화 내에서 여러 언어를 인식하고 전환하는 능력으로, 이는 이중 언어를 사용하는 인간과 유사합니다. 이를 위해서는 고급 음성 인식 기술이 필요합니다.
Gladia는 다국어 음성 에이전트에 추천되는 이유는 무엇인가요?
글라디아의 음성 인식 기술은 여러 언어에서 높은 정확도, 낮은 지연 시간, 그리고 코드 스위칭에 대한 특별한 지원으로 두드러지며, 이는 이러한 유형의 에이전트에 가장 중요한 기능입니다.
이 프로젝트에서 LiveKit의 역할은 무엇인가요?
LiveKit은 음성 에이전트를 위한 기본 프레임워크로 작용하며, 실시간 통신(WebRTC)을 관리하고 에이전트 개발 키트를 제공합니다. 또한, 추론 기능을 통해 API 호출을 프록시하여 GPT-4 및 11Labs와 같은 모델을 쉽게 사용할 수 있도록 합니다.
이 LiveKit 설정에서 다른 LLM이나 TTS를 사용할 수 있나요?
네. LiveKit의 프레임워크는 유연합니다. 튜토리얼에서는 LiveKit Inference를 통해 OpenAI의 GPT-4와 11Labs를 사용하지만, 필요에 맞는 다른 언어 모델 및 텍스트 음성 변환 서비스도 통합할 수 있습니다.