No es un modelo, sino un sistema: cómo Svoi construyeron la arquitectura de un bot fintech de 7 capas

Cuando un asistente de voz le dice a un cliente de un banco que tiene un millón de rublos en su cuenta, cuando en realidad tiene cien, no es un problema de la red neuronal. Es una falla del sistema en su conjunto.

Arquitectura en lugar de magia

La arquitectura híbrida de un bot de voz en fintech no es «un buen LLM y listo». Son siete capas, cada una con su propia tarea: ASR (reconocimiento de voz) — qué dijo el usuario NLU (procesamiento del lenguaje natural) — qué quería hacer Routing (enrutamiento) — hacia dónde dirigirlo API (obtención de datos) — datos sobre el cliente y sus cuentas Knowledge (base de conocimiento) — información actualizada sobre los productos Compliance (verificación de reglas) — si está permitido hacerlo * Voice (síntesis de voz) — cómo responder elegantemente Más la orquestación en la parte superior: el LLM decide cómo conectar todas estas partes. Cuando el sistema funciona, nadie se da cuenta.

Cuando falla un eslabón, todo falla.

Por qué el eslabón débil es más fuerte que el modelo fuerte

La paradoja del fintech en una frase: si el conocimiento está desactualizado hace tres días, ningún GPT-5 lo salvará. Si el enrutamiento no puede pasar a un operador cuando no entiende, el mejor NLU es inútil. Si la API devuelve datos con una demora de tres horas, el asistente mentirá todos los días. Svoi.ru lo vio en condiciones reales. Un cliente puede quejarse durante mucho tiempo de la «estupidez del bot», pero el problema es que el historial de transacciones no se actualiza en tiempo real. Un LLM muy bueno responderá honestamente lo que se le alimentó.

Cómo se conecta todo

Imagina un escenario: un cliente llama al banco y pregunta sobre el cashback en rublos. El ASR escuchó correctamente. El NLU entendió que se necesitaba información del producto.

El Routing lo envió a la base de conocimientos. Pero el conocimiento se actualizó hace una semana, antes del último cambio de términos. Voice sintetiza la respuesta.

Y el LLM no tiene culpa: honestamente repitió lo que le dieron. Por eso en estos sistemas los desarrolladores gastan el 80% del tiempo no en mejorar el modelo, sino en: actualizar y mantener la consistencia de la base de conocimiento confiabilidad y velocidad de la API calidad y relevancia de la lógica de enrutamiento degradación elegante cuando un componente falla * prueba de cada capa por separado ## Qué significa esto La era en la que podías elegir el modelo más genial y esperar magia ha terminado. En bancos, seguros, casas de bolsa, en todos lados donde un error cuesta dinero, ganará no la empresa con el mejor LLM, sino la que tiene la mejor ingeniería.

Y eso es bueno: significa que la entrada para principiantes sigue abierta si entiendes cómo funcionan los sistemas en su conjunto.