전체 글

· Casimiro Ferreira· 4 분 읽기

우리가 데이터를 축적하는 이유: 스크래핑한 카탈로그에서 더 똑똑한 음성·언어 모델까지

  • Datasets
  • Data Collection
  • ASR
  • NLP
  • TTS
  • LLM
  • FOSS

우리는 데이터를 어떻게 추출하는지에 관해 많은 글을 씁니다 — 정찰 도구, 안티봇 전송 계층, 타입이 정의된 음악 메타데이터 클라이언트. 당연한 질문은 인가입니다. 우리는 음성 AI 회사인데, 음악 백과사전과 라디오 디렉터리를 위한 스크래퍼를 유지 관리하며 무엇을 하고 있는 걸까요?

답은 데이터가 우리가 출시하는 모든 것의 상류에 있다는 것입니다. 음성 어시스턴트는 자신이 들을 것으로 기대하는 단어, 인식할 수 있는 엔티티, 그리고 알고 있는 발음만큼만 우수합니다. 그중 어느 것도 아키텍처 다이어그램에서 나오지 않습니다. 데이터에서 나옵니다 — 그리고 흥미로운 데이터는 이미 만들어진 데이터셋에 얌전히 놓여 있는 경우가 드뭅니다. 그것은 공개 웹 전반에, 인간이 수십 년에 걸쳐 큐레이션한 카탈로그 속에 흩어져 있습니다.

우리가 그 데이터를 수집한 후에 어떤 일이 일어나는지 소개합니다.

엔티티: 음성 어시스턴트가 살아가는 어휘

어시스턴트에게 “Dire Straits의 Sultans of Swing을 틀어줘”라고 말해 보세요. 어떤 모델이든 그에 대해 행동하기 전에, 무언가는 Sultans of Swing이 트랙이고 Dire Straits가 아티스트라는 것을 알아야 합니다. 사용자가 언급할 수 있는 모든 아티스트, 앨범, 방송국, 팟캐스트, 장르를 곱하면, 미디어 어시스턴트의 진짜 어휘가 됩니다 — 수십만 개의 명명된 엔티티이며, 그중 어느 것도 표준 NLP 학습 코퍼스에는 나타나지 않습니다.

우리의 미디어 클라이언트는 바로 이것을 생성합니다: 표준 id를 가진 타입이 정의된 레코드로, mediavocab 스키마로 정규화됩니다. 그러한 엔티티 카탈로그는 다음에 직접 공급됩니다:

  • 키워드 기반 의도 매칭 — 엔티티 목록은 OpenVoiceOS에서 미디어 쿼리를 기반 짓는 개저티어(gazetteer)가 됩니다.
  • 의도 분류기 — 우리의 미디어 의도 데이터셋은 실제로 스크래핑한 엔티티를 템플릿 및 LLM 지원 문장 합성과 결합하여, 실제 사용자가 만드는 것과 같은 발화를 실제로 존재하는 엔티티로 채워 생성합니다. 그렇게 학습된 모델은 OpenVoiceOS 미디어 파이프라인에서 “이것이 재생 요청인가, 그리고 무엇에 대한 것인가?”라는 결정을 처리합니다.
  • 합성 NER 코퍼스 — 동일한 레시피가 일반화됩니다: 실제 엔티티의 카탈로그를 가져와 그 주변에 자연스러운 문장을 생성하면, 어떤 학술 코퍼스도 다루지 않는 도메인에 대한 레이블링된 명명 엔티티 데이터셋을 갖게 됩니다. 엔티티는 실제이므로 분포가 정직하고, 문장은 합성이므로 양은 필요한 만큼입니다.

중요한 단어 쪽으로 음성 인식을 바이어싱하기

범용 ASR은 일반적인 음성으로 학습되므로 Dire Straits를 “dire straights”로 전사하고 모든 포르투갈어 마을 이름을 망가뜨립니다. 해결책은 처음부터 다시 학습하는 것이 아니라 — 바이어싱입니다: 인식기에 당신 도메인의 어휘를 제공하는 것입니다.

스크래핑한 카탈로그가 바로 그 어휘입니다. 구체적으로:

  • 언어 모델 바이어싱 — 엔티티가 풍부한 텍스트로 학습된 n그램 또는 얕은 융합 (shallow-fusion) LM은 디코더를 도메인 내 단어 쪽으로 유도합니다. 미디어 어시스턴트의 LM은 트랙 제목과 아티스트 이름으로 학습되어야 하며, 우리의 LM은 그럴 수 있습니다. 우리가 그것들을 — 타입이 정의되고, 중복이 제거되고, 출처가 깨끗한 형태로 — 가지고 있기 때문입니다.
  • 프롬프트 조건 인식 — 최신 아키텍처는 추론 시점에 텍스트 프롬프트나 컨텍스트 목록을 받아들입니다. 사용자의 실제 라이브러리 — 우리 클라이언트가 추출한 엔티티 — 를 인식기의 컨텍스트에 공급하면 “인식할 수 없는 고유명사”가 “알려진 어휘 항목”으로 바뀝니다.
  • 파인튜닝 데이터 — 바이어싱만으로 충분하지 않은 경우, 엔티티 카탈로그와 우리의 TTS 음성이 배포 환경에서 절대 틀려서는 안 되는 정확한 문구에 대한 합성 음성을 생성합니다. 이것이 우리가 상업적으로 제공하는 데이터셋 구축 서비스이며, 동일한 개방형 파이프라인 위에 구축되어 있습니다.

발음: 크롤링한 사전에서 G2P와 TTS까지

우리의 가장 가치 있는 크롤링 중 일부는 엔티티 카탈로그가 아니라 사전(lexicon) 입니다. Infopédia 사전을 크롤링하여 infopedia-pt-ipa, 10만 개가 넘는 유럽 포르투갈어 단어→IPA 쌍을 만들었습니다. 그 데이터셋은:

  • 규칙 기반 포르투갈어 G2P 스택을 벤치마킹하고 튜닝하며,
  • TTS 음성의 발음을 기반 지어 화자가 실제로 말하는 방식대로 단어를 말하게 하고,
  • 우리의 포르투갈어 헤테로폰 작업처럼 의미가 레이블링된 리소스의 씨앗이 됩니다. 여기서는 동일한 철자가 의미에 따라 다른 소리로 대응됩니다.

철자-대-소리 데이터는 음성 기술에서 가장 화려하지 않은 구석이지만, 음성이 원어민처럼 들리는지를 가장 크게 좌우합니다. 아무도 이 데이터를 건네주지 않습니다. 당신이 그것을 크롤링하고, 정제하고, 게시합니다 — 다음 팀이 그럴 필요가 없도록.

LLM을 위한 정직한 연료

위의 모든 것은 대규모 언어 모델에도 적용되며, 한 가지 추가적인 반전이 있습니다: 이제 출처가 양보다 더 중요합니다. 개방형 웹은 점점 더 모델이 생성한 텍스트로 오염되고 있으며, 그 위에서 학습하거나 평가하면 조용히 어제의 모델 출력을 재활용하게 됩니다. 그것이 우리가 깨끗한 인간 출처를 가진 소스에 관심을 두는 이유입니다 — 수십 년의 Usenet 아카이브, 큐레이션된 백과사전, 공식 사전 — 그리고 우리가 게시하는 모든 데이터셋이 각 레코드가 어디서 왔는지 명시하는 이유입니다.

구조화된 카탈로그는 추론 시점에도 LLM에 공급됩니다: 타입이 정의되고 중복이 제거된 엔티티 저장소는 리트리벌 계층이나 에이전트의 도구 API가 답변을 기반 짓기 위해 원하는 바로 그것입니다. 지저분한 소스 위의 깨끗한 API는 단지 스크래핑의 편의성이 아닙니다 — 언어 모델을 사실에 붙들어 두는 방법입니다.

파이프라인, 처음부터 끝까지

그래서 전체 그림은 다음과 같습니다:

recon → resilient extraction → typed clients → normalised catalogues
      → gazetteers & intent data     (NLP)
      → biasing LMs & fine-tune sets (ASR)
      → lexicons & phoneme labels    (G2P / TTS)
      → provenance-clean corpora     (LLMs, retrieval)

각 단계는 오픈 소스이고, 각 데이터셋은 라이선스가 허용하는 곳에 게시되며, 우리 자신의 모델 요구를 충족하는 동일한 파이프라인을 당신을 위한 프로젝트로 이용할 수 있습니다. 스크래퍼는 부차적인 임무가 아닙니다. 그것은 전체 스택이 세워지는 채석장입니다.