La construcció d'un chatbot de veu en temps real per a llengües africanes com igbo, yoruba i hausa va molt més enllà de canviar codis d'idioma en una API al núvol. Aquestes llengües, parlades per milions de persones, estan severament infrarrepresentades en els models comercials: Whisper al·lucina sobre silencis, NLLB tradueix malament expressions comunes en yoruba i els sistemes de text a veu comercials mai han sentit igbo. En aquest article explorem com dissenyar i implementar una arquitectura de producció real que serveixi aquestes quatre llengües (anglès, hausa, yoruba, igbo) amb components ajustats i desplegats darrere d'una API compatible amb OpenAI.
L'arquitectura es compon de cinc microserveis independents, cadascun responsable d'una tasca específica, que exposen endpoints HTTP compatibles amb OpenAI. El chatbot els invoca amb el mateix client Python d'OpenAI que utilitzaria per a GPT-4, simplement canviant la base_url. Això permet escalar o substituir qualsevol component sense tocar el codi de l'aplicació. Des de aplicacions a mida fins a sistemes complexos d'IA, la modularitat és clau per a la flexibilitat en entorns de producció.
El primer esglad és el reconeixement de veu (STT). Partim de Whisper, un model multilingüe que, sense ajust fi, aconseguia una taxa d'error de paraula (WER) del 30-40 % en hausa. Després d'entrenar amb aproximadament 50 hores d'àudio nadiu per idioma, el WER baixa per sota del 12 %. El model es carrega com un pipeline de HuggingFace amb trossejament de 30 segons, gestionant àudios de qualsevol durada. No obstant això, el problema més crític és el silenci. En producció, entre el 15 i el 25 % de l'àudio entrant conté soroll de fons, activacions accidentals o silenci pur. Sense filtratge, Whisper al·lucina text plausible sobre tot això. La solució és incorporar Silero VAD (detecció d'activitat de veu) abans que el model processi res: si no es detecta veu, la sol·licitud retorna una transcripció buida a l'instant, eliminant la inferència i les al·lucinacions. Aquesta decisió elimina la classe més comuna d'errors visibles per a l'usuari.
Per a la identificació de l'idioma, forcem el token d'idioma correcte al descodificador de Whisper per a anglès, hausa i yoruba mitjançant forced_decoder_ids. Sense això, Whisper pot canviar silenciosament a un idioma que reconegui millor a mig camí. Igbo queda exclòs perquè no està al vocabulari de Whisper; forçar-lo llançaria un error, així que el model ajustat el maneja lliurement. La transcripció es transmet com a events enviats pel servidor (SSE), emetent cada fragment de 30 segons a mesura que es completa. El client comença a rebre text mentre el model encara processa la cua d'un clip llarg.
El segon component és la traducció. Utilitzem NLLB-200 de Meta en lloc d'un LLM. Els LLMs tradueixen bé per a llengües d'alts recursos, però són poc fiables i costosos per a parells com hausa ↔ anglès o igbo ↔ anglès a rendiment de producció. NLLB va ser dissenyat específicament per a aquests parells. El repte és la latència: el model PyTorch sense quantitzar corre a unes 6 tokens/segon en CPU, inacceptable. Aquí recorrem a CTranslate2, un motor d'inferència en C++ optimitzat per a models encoder-decoder. Convertir NLLB a format INT8 de CTranslate2 és un pas únic: el model convertit funciona a ~150 ms per frase en dos nuclis de CPU, viable sense GPU. A més, despleguem instàncies separades per idioma (hausa, igbo, yoruba) en contenidors Docker independents. Un requisit no obvi és que la direcció de traducció ha de ser explícita: l'API exigeix un camp obligatori com 'hausa_to_english' sense valor per defecte. L'emissor sempre sap en quina direcció vol traduir.
L'agent LLM constitueix el nucli de la lògica conversacional. Servim un model ajustat mitjançant vLLM, que ofereix dues característiques essencials: PagedAttention gestiona la memòria cau de claus i valors com a pàgines de memòria virtual, evitant esgotaments de memòria sota càrrega concurrent; i el batching continu permet que les sol·licituds que arriben durant una generació s'uneixin al lot actual, duplicant el rendiment efectiu respecte al batching estàtic. Davant de vLLM, col·loquem una memòria cau semàntica amb Redis. Abans de qualsevol inferència, la consulta entrant es compara amb embeddings de consultes emmagatzemades usant un llindar de similitud cosinus de 0,95. En producció, una gran fracció de les consultes són reformulacions semànticament idèntiques de la mateixa pregunta, i resolen amb la mateixa resposta emmagatzemada, reduint les crides al LLM en un 30-40 %. L'agent exposa dos endpoints: /api/agent/chat per a respostes completes JSON i /api/agent/stream per a streaming token a token mitjançant SSE. Després de completar el streaming, s'encuen tasques en segon pla per al registre de converses i l'avaluació de qualitat RAGAS, sense bloquejar la resposta. Un detall pràctic: cal afegir la capçalera X-Accel-Buffering: no quan el servei corre darrere de Nginx, per evitar que el proxy emmagatzemi en memòria intermèdia el flux SSE.
L'últim component és la síntesi de text a veu (TTS). Cap servei comercial maneja el yoruba o hausa tonals amb naturalitat acceptable. Vam construir un pipeline personalitzat sobre ChatterboxTTS, una arquitectura de clonació de veu amb un transformador acústic T3 i un vocoder neuronal S3Gen, ajustat amb gravacions de parlants nadius per als quatre idiomes. Disposem de catorze veus nominals, cadascuna clonada d'un parlant real. Una troballa tècnica important: el transformador T3 corre en bfloat16 sobre CUDA, duplicant el rendiment i reduint la memòria amb pèrdua de qualitat insignificant, perquè l'atenció és numèricament estable. No obstant això, el vocoder S3Gen ha de romandre en float32; els vocoders utilitzen capes convolucionals profundes amb residus acumulats, i en bfloat16 l'error numèric produeix artefactes audibles com brunzits o corrupció total. Cal provar cada submòdul de forma independent abans d'assumir que bfloat16 és segur en una arquitectura composta.
La identitat de veu a Chatterbox es determina mitjançant un embedding de parlant extret d'un clip d'àudio de referència. Aquesta extracció és costosa (200-400 ms per sol·licitud). Per evitar-ho, tots els condicionals de veu es calculen a l'arrencada i s'emmagatzemen en memòria cau; canviar d'altaveu és una simple cerca en un diccionari. Per a latència percebuda baixa, les respostes llargues es divideixen per límits d'oració i se sintetitzen fragment a fragment. L'àudio comença a transmetre's al client tan bon punt el primer fragment està llest. La resposta HTTP comença amb una capçalera WAV que anuncia mides RIFF i de dades obertes (0xFFFFFFFF), un truc estàndard per transmetre àudio PCM sense conèixer la longitud total. La diferència és notable: una resposta de 500 paraules sintetitzada en un sol bloc triga ~8 segons abans de sentir-se; fragmentada, l'usuari escolta la primera frase en ~1,2 segons.
Des d'una perspectiva de negoci, aquesta arquitectura demostra que és possible servir llengües infrarrepresentades amb qualitat de producció sense dependre de gegants tecnològics. A Q2BSTUDIO, com a empresa de desenvolupament de programari i tecnologia, apliquem aquests principis en múltiples àmbits: des de solucions d'IA a mida fins a sistemes de ciberseguretat que protegeixen les dades de veu, passant per infraestructures al núvol a AWS o Azure que escalen automàticament segons la demanda. L'optimització de costos és essencial: els serveis de NLLB en CPU amb quantització INT8 redueixen dràsticament la despesa en GPU, que es reserva per a STT i TTS on la latència és crítica. A més, la modularitat de microserveis permet integrar agents d'IA conversacionals amb sistemes de BI com Power BI per analitzar patrons d'ús i millorar l'experiència.
Un dels aprenentatges més valuosos és que cap d'aquests cinc serveis és exòtic per si sol: Whisper ajustat, CTranslate2, vLLM i un model de clonació de veu estan ben documentats. El que fa que aquesta pila sigui de grau de producció és l'acumulació de petites decisions guanyades amb esforç: filtrar el STT amb VAD, forçar explícitament la direcció de traducció, separar la precisió en els submòduls del TTS, i separar l'avaluació de l'emmagatzematge. Cadascuna d'aquestes va ser un incident real abans de convertir-se en regla de disseny. Per als equips que construeixen interfícies de veu per a idiomes subrepresentats, la lliçó va més enllà d'aquesta pila tecnològica: cal pressupostar temps per als problemes d'infraestructura avorrits, no només per als problemes de qualitat del model, perquè solen ser els que realment es trenquen en producció.
En resum, l'arquitectura presentada ofereix un full de ruta pràctic per portar el processament de veu a llengües que el mercat ha ignorat. Amb una combinació intel·ligent de models ajustats, infraestructura al núvol i bones pràctiques d'enginyeria, és possible construir sistemes robustos que funcionin al món real. Des del reconeixement de veu amb VAD fins a la síntesi fragmentada, cada component aporta valor tangible, i tots junts demostren que la tecnologia inclusiva no només és possible, sinó també escalable i rendible.
