사용자가 다음과 같이 받아쓰기를 합니다: "Vytvoř tabulku clients with columns name, email and datum schůzky."

이 단 한 문장에는 체코어, 영어, 그리고 두 언어가 혼합된 형태가 포함되어 있습니다. 우리의 음성-텍스트 변환 (Speech-to-Text, STT) 모델은 이에 어떻게 대응해야 할지 알지 못했습니다.

우리는 목소리로 제어하는 AI 워크스페이스인 Voice Tables를 구축하고 있습니다. 사용자가 CRM, 프로젝트 트래커, 재고 관리 등 필요한 것을 설명하면, 시스템이 이를 위한 테이블, 문서 및 데이터를 구축해 줍니다. 파이프라인은 간단합니다: 마이크 > Whisper 전사 (Transcription) > LLM 함수 호출 (Function Calling) > 구조화된 출력 (Structured Output). 사용자가 한 가지 언어만 사용한다면 이 방식은 잘 작동합니다.

하지만 사용자들은 그렇지 않습니다.

문제점

Whisper는 language 파라미터를 허용합니다. 이를 cs로 설정하면 체코어를 정확하게 전사합니다. en으로 설정하면 영어가 아주 잘 작동합니다. 하지만 다국어 환경의 실제 사용자들은 문장의 경계에서 언어를 바꾸지 않습니다. 그들은 구절 중간에서 언어를 전환합니다.

체코어 사용자는 CRM 필드를 생각하는 방식 때문에 컬럼 이름을 영어로 말할 수 있습니다. 독일인 프리랜서는 "Erstelle eine Tabelle project deadlines mit priority und Fälligkeitsdatum."라고 말합니다. 기술 용어는 영어로 유지되지만, 연결어(Glue words)는 화자의 모국어를 따릅니다.

우리가 단일 language 파라미터를 강제했을 때, 세 가지 문제가 발생했습니다:

1. 환각 전사 (Hallucinated transcriptions). Whisper는 영어 단어를 체코어 음소로 매핑하려고 시도했고 쓰레기 같은 결과물을 만들어냈습니다. "Clients"는 "kliends" 또는 "klajnts"가 되었는데, 이는 LLM을 혼란스럽게 할 만큼 비슷하면서도 조회를 실패할 만큼 틀린 결과였습니다.

2. 컬럼 이름 유실. 다운스트림(Downstream)의 LLM은 엉망이 된 입력을 받았고, 컬럼 이름을 임의로 만들어내거나 조용히 누락시켰습니다. 사용자들은 요청한 필드가 빠진 테이블을 받게 되었습니다.

3. 신뢰도 저하. 이 문제를 한 번이라도 경험한 사용자는 음성 입력을 신뢰하지 않게 되었고 다시 타이핑 방식으로 돌아갔습니다. 이는 핵심 가치 제안 (Value Proposition)을 무너뜨리는 일입니다.

우리가 시도한 것

시도 1: 요청별 언어 자동 감지 (Auto-detect language per request). 오디오를 Whisper에 전달하기 전에 짧은 언어 분류기 (Language Classifier)를 실행했습니다. 문제점: 영어 단어 두 개가 포함된 3초 길이의 체코어 문장은 여전히 체코어로 분류됩니다. 결과적으로 영어 단어들은 여전히 엉망으로 변환됩니다.

시도 2: 언어 힌트 없는 Whisper 사용. Whisper는 자동 감지가 가능하지만, 오디오 세그먼트 전체에 대해 하나의 언어만을 선택합니다. 래퍼 (Wrapper)만 다를 뿐 동일한 문제가 발생했습니다.

시도 3: 세그먼트 수준 감지 (Segment-level detection). 오디오를 무음 경계에서 청크 (Chunk) 단위로 나누고, 각 청크를 분류한 뒤 일치하는 언어로 전사 (Transcription)했습니다. 이는 자연스러운 휴지기 (Pause)에서 언어가 전환되는 문장의 정확도를 개선했지만, 대부분의 명령어 중간 전환은 휴지기 없이 발생합니다. "Vytvoř tabulku clients"는 한 호흡에 이어지는 연속적인 문장입니다.

실제로 작동한 방식

우리는 오디오 레이어 (Audio Layer)에서 이 문제를 해결하려는 시도를 중단했습니다.

해결책은 Whisper가 최선의 추측으로 전사하게 둔 다음, LLM을 사용하여 실행하기 전에 출력값을 정제하는 것이었습니다. 우리는 전사 (Transcription)와 함수 호출 (Function Calling) 사이에 정규화 (Normalization) 단계를 추가했습니다:

1. 자동 감지로 전사. Whisper가 원하는 어떤 언어든 선택하게 둡니다. 전사 결과가 지저분할 수 있음을 인정합니다.

2. 전사 후 정규화 (Post-transcription normalization). 원본 전사 내용을 시스템 프롬프트와 함께 LLM에 전달합니다: "이것은 다국어 사용자의 음성 명령입니다. 의도 (Intent), 엔티티 이름 (Entity Names), 필드 이름 (Field Names)을 추출하세요. 기술 용어(테이블 이름, 컬럼 이름)를 의도된 형태에 맞게 정규화하세요. 구조화된 JSON을 반환하세요."

3. 신뢰도 점수 산정 (Confidence scoring). LLM은 추출된 각 엔티티에 대해 신뢰도 점수를 반환합니다. 임계값 미만일 경우 사용자에게 확인을 요청합니다: "clients 또는 _klienti_라는 이름의 컬럼을 의미하셨나요?"

4. 피드백 루프 (Feedback loop). 사용자가 확인하거나 수정할 때, 우리는 해당 매핑을 기록합니다. 시간이 지나면서 사용자별 패턴이 나타납니다. 예를 들어, 이 사용자는 체코어로 말할 때도 항상 "clients"를 영어로 말합니다. 우리는 이러한 패턴을 컨텍스트 (Context)로 다시 피드백합니다.

핵심 통찰(Key insight): Whisper의 역할은 음소(Phonemes)를 포착하는 것입니다. LLM의 역할은 의도(Intent)를 이해하는 것입니다. Whisper에게 적절한 언어를 선택함으로써 의도까지 이해하도록 강제하는 것은, 잘못된 도구에게 잘못된 일을 시키는 것이었습니다.

결과 (Results)

정규화 레이어(Normalization layer)를 배포한 후, 우리는 세 가지 지표를 추적했습니다:

• 전사-실행 정확도 (Transcription-to-action accuracy): 다국어 사용자의 경우 약 72%에서 약 94%로 상승했습니다.
• 수정률 (Correction rate) (사용자가 음성 명령 결과를 수동으로 수정하는 비율): 약 60% 감소했습니다.
• 음성 입력 유지율 (Voice input retention) (음성을 시도한 후 7일 뒤에도 계속 사용하는 사용자): 모든 비영어권 지역에서 개선되었습니다.

지연 시간(Latency) 비용은 음성 명령당 한 번의 추가적인 LLM 호출이 발생하며, 약 200-400ms 정도입니다. 테이블 생성 자체에 걸리는 시간이 이보다 더 길기 때문에 사용자는 이를 인지하지 못합니다.

여전히 해결 중인 예외 사례 (Edge cases we still fight)

고유명사 (Proper nouns). 사용자가 체코어 문장 중간에 "Add a row for Müller GmbH"라고 말하는 경우입니다. 정규화 레이어가 때때로 고유명사를 사전적 단어로 과도하게 교정(Over-correct)하곤 합니다. 우리는 기존 테이블 데이터에서 추출한 엔티티 허용 목록(Entity allowlist)을 통해 이 문제를 부분적으로 해결하고 있습니다.

숫자와 날짜 (Numbers and dates). "Schůzka dvacátého June"은 체코어 서수와 영어 월(Month)이 섞여 있습니다. 날짜 파싱(Date parsing)에는 혼합 언어 시간 표현(Mixed-language temporal expressions)을 처리하는 별도의 서브 파이프라인(Sub-pipeline)이 필요합니다.

언어 간 동음이의어 (Homophones across languages). 체코어 단어 "most"는 "다리(bridge)"를 의미합니다. 영어 단어 "most"는 완전히 다른 의미를 가집니다. 문장 수준의 컨텍스트(Context)가 없다면, 정규화 도구는 잘못된 단어를 선택할 수 있습니다. 우리는 일반적인 단어에 대해서는 사용자의 기본 언어 쪽으로, 기술 용어에 대해서는 영어 쪽으로 편향(Bias)을 두어 처리합니다.

시사점 (Takeaway)

글로벌 사용자 기반을 위한 음성 파이프라인을 구축하고 있다면, 음성 인식(Speech-to-text) 레이어에서 다국어 입력을 해결하려고 하지 마세요. 지저분한 전사(Transcription) 결과는 그대로 받아들이고, 다운스트림(Downstream)에서 정규화하며, 피드백 루프(Feedback loop)를 구축하세요. LLM은 그 어떤 오디오 분류기(Audio classifier)보다 모호성을 해결하는 데 더 뛰어납니다.

우리는 Voice Tables에서 이 작업을 계속해서 반복(Iterating)하고 있습니다. 만약 유사한 작업을 하고 계신다면, 서로의 노하우를 비교해 보고 싶습니다.