Filtrado de keyterms para STT: menos alucinaciones en voz con acentos no estándar
Un proyecto en beta aborda uno de los puntos ciegos del reconocimiento de voz: la tendencia de proveedores como Deepgram a 'alucinar' keyterms en idiomas distintos al inglés estándar.
El reconocimiento de voz lleva años mejorando su precisión general, pero hay un problema concreto que sigue sin resolverse bien: cuando introduces keyterms personalizados —nombres de marca, términos técnicos, jerga sectorial— para mejorar la transcripción, los modelos STT tienden a «verlos» aunque no estén en el audio. El efecto es especialmente marcado en idiomas distintos al inglés estándar o con acentos no normativos.
Eso es exactamente lo que intenta resolver Aditu, un proyecto que apareció esta semana en Hacker News bajo el hilo «Show HN: Keyterm Filtering for Voice AI». Su propuesta es directa: una capa de filtrado postproceso que analiza las transcripciones generadas con keyterm prompting y elimina aquellos términos que probablemente no estaban en el audio de origen.
El problema con el keyterm prompting
El keyterm prompting es una técnica estándar en pipelines de voz: se le indica al motor STT qué palabras debe priorizar o reconocer, lo que ayuda con nombres propios, marcas o vocabulario técnico poco común. Proveedores como Deepgram la implementan de forma nativa.
El inconveniente es que el modelo, al tener esas palabras «en mente», las inserta en la transcripción aunque el hablante no las haya pronunciado. Con inglés de acento neutro americano o británico el problema es manejable. Con hindi, inglés con acento indio, o cualquier variante fonéticamente alejada de los datos de entrenamiento dominantes, la tasa de alucinación de keyterms sube de forma notable.
Se trata de un fallo clásico de sesgo de distribución: los modelos STT se entrenan mayoritariamente con audio en inglés estándar, y cuando el input se aleja de esa distribución, el modelo «completa» con lo que espera escuchar en lugar de lo que realmente oyó.
Qué hace exactamente el filtro
Aditu no reemplaza al motor STT ni modifica el modelo base. Actúa como paso de postprocesamiento: recibe la transcripción con los keyterms potencialmente alucinados y aplica su lógica de filtrado para decidir cuáles mantener y cuáles eliminar.
Según el propio autor, en sus pruebas internas el sistema reduce las alucinaciones de keyterms en torno a un 60%. No es perfección, pero es una reducción significativa para casos de uso reales donde las transcripciones erróneas generan ruido en sistemas downstream —CRMs, sistemas de análisis de llamadas, pipelines de búsqueda semántica—.
Actualmente el servicio soporta hindi e inglés con acento indio. Está disponible de forma gratuita durante la fase beta, y el autor solicita explícitamente feedback sobre rendimiento con datos propios, así como interés en características como soporte para más idiomas, streaming y opción de self-hosting.
Para quién tiene sentido explorar esto
El caso de uso más claro es cualquier producto de voz desplegado en mercados de habla no inglesa o con bases de usuarios multilingües: contact centers en India o Latinoamérica, asistentes de voz para sectores con vocabulario especializado, o sistemas de transcripción automática para reuniones con participantes internacionales.
También es relevante para equipos que ya usan Claude Code con servidores MCP conectados a APIs de transcripción de voz: una capa de filtrado como esta podría integrarse como herramienta intermedia en el pipeline, reduciendo el ruido antes de que los keyterms alucinados contaminen el contexto que recibe el modelo de lenguaje.
El proyecto está en fase muy temprana —dos puntos en HN y sin comentarios en el momento de publicarse esta entrada— y los datos de evaluación son internos, lo que significa que habría que validarlo con datos propios antes de considerarlo para producción. Dicho esto, el problema que aborda es real y documentado, y la aproximación de filtrado postproceso tiene sentido como solución pragmática mientras los propios proveedores STT no mejoren su robustez con acentos no estándar.
Desde ElephantPink lo seguiremos de cerca: la combinación de voz multilingüe y pipelines de agentes es uno de los puntos de fricción más frecuentes en las integraciones que desarrollamos.
Fuentes
Seguir leyendo
Siftly quiere entrenar el criterio humano en revisión de código con IA
Siftly propone un enfoque distinto: en lugar de dejar que la IA revise tu código, úsala para afinar tu propio juicio como revisor. Una idea que merece discutirse.
Cyber.md: documentación de seguridad pensada para agentes de IA
Baz propone un estándar de archivo estructurado para que los agentes de IA puedan leer y actuar sobre la postura de seguridad de una organización sin intervención humana.
Agent Harness Engineering: estructurar agentes para que no se rompan
Addy Osmani pone nombre a una disciplina que muchos equipos ya practican sin saberlo: diseñar el andamiaje que mantiene a los agentes IA dentro de los raíles.