Cómo están montados hoy el RAG
y la lógica de negocio
Descripción del sistema tal como funciona en producción a día de hoy — no del roadmap ni de la propuesta comercial. Sirve como referencia técnica independiente de que se contrate o no el piloto.
1. Arquitectura de un turno de conversación
Pipeline "cascaded": transcripción → recuperación de conocimiento (RAG) → modelo de lenguaje en streaming → síntesis de voz en streaming, encadenados para que el audio empiece a sonar antes de que el modelo termine de generar el texto completo.
| STT (voz → texto) | gpt-realtime-whisper |
| LLM | gpt-4o-mini |
| TTS (texto → voz) | gpt-4o-mini-tts |
| Embeddings | text-embedding-3-small · 1536 dim |
Fencing por epoch
Cada turno lleva un número de epoch monotónico. Si el usuario interrumpe (barge-in), el epoch sube y cualquier evento tardío del turno cancelado se descarta comparando epochs — así una respuesta ya cortada no puede "colarse" después de la interrupción.
Máquina de estados
La sesión transita entre listening / thinking / tool_executing / synthesizing / assistant_speaking / interrupted. Gobierna qué eventos son válidos en cada momento y se emite al cliente para reflejar el estado en la interfaz.
Streaming encadenado
El texto del LLM se trocea por frases (SpeechChunker) y cada fragmento se envía a síntesis en cuanto está listo, con hasta 2 síntesis en vuelo a la vez — el audio de la primera frase puede sonar mientras el modelo aún genera la segunda.
Filler / backchannel
Existe un mecanismo para reproducir una coletilla pregrabada ("déjame ver…") si el audio real tarda más de 450 ms, pensado para enmascarar latencia. Implementado y probado, pero desactivado en la configuración actual.
2. Cómo se recupera el conocimiento (RAG)
Modelo de datos
Jerarquía en PostgreSQL (esquema knowledge, con pgvector): organización → marca → producto. El conocimiento en sí recorre otra cadena independiente: fuente (con nivel de confianza) → documento → versión de documento (con hash de contenido, para detectar cambios) → chunk.
| Campo del chunk | Valores |
|---|---|
| content_kind | FACT · MARKETING_CLAIM · COMMERCIAL_GUIDANCE · INFERENCE |
| confidence | HIGH · MEDIUM · LOW |
| visibility | PUBLIC · INTERNAL · RESTRICTED · ACCOUNT_SCOPED |
| valid_from / valid_until | ventana temporal de validez del dato (opcional) |
Publicación versionada
Los chunks no se sirven directamente: se agrupan en releases versionadas por marca (estados DRAFT → EVALUATING → APPROVED → PUBLISHED → ARCHIVED/REVOKED), y una restricción de base de datos garantiza que solo puede haber un release PUBLISHED activo por marca a la vez. El asistente conversa siempre contra un release publicado y fijado por configuración — como una release de software, no una edición libre en caliente sobre lo que se está sirviendo.
Búsqueda híbrida en cada turno
Por cada pregunta se lanzan dos búsquedas en paralelo sobre el release publicado y se fusionan sus resultados:
Léxica
Texto completo en español (tsvector, con más peso en título que en sección y contenido), con una consulta estricta y otra relajada término a término como red de seguridad ante errores de transcripción.
Semántica
Similitud de embeddings de la pregunta contra los del chunk (distancia coseno, índice HNSW) — encuentra lo relevante aunque no comparta las palabras exactas.
Ambas listas se combinan por Reciprocal Rank Fusion (no por la puntuación bruta de cada motor, sino por la posición de cada resultado en su propio ranking) y se seleccionan los 8 fragmentos mejor situados como contexto del turno.
Aislamiento multi-tenant
Cada consulta fija app.organization_id en la sesión de base de datos, y Row-Level Security de PostgreSQL fuerza esa condición en cada tabla del esquema — el aislamiento entre organizaciones está garantizado por la propia base de datos, no solo por la lógica de la aplicación.
Grounding: cómo se evita que invente
Los fragmentos recuperados se inyectan como bloques de evidencia marcados explícitamente como datos no confiables, nunca instrucciones. El prompt exige responder solo con lo respaldado por esa evidencia, prohíbe completar datos de producto con conocimiento general del modelo, y obliga a reconocer con naturalidad cuando falta un dato en vez de rellenarlo. Si la búsqueda falla técnicamente o no devuelve resultados, hay mensajes de repliegue específicos que impiden que el sistema alucine en su lugar.
3. Conocimiento cargado hoy: producto, argumentario y proceso de venta
El release publicado en producción contiene 24 fragmentos de conocimiento, repartidos en tres tipos (content_kind) que el sistema trata de forma distinta:
| Tipo | Qué contiene hoy |
|---|---|
| FACT | Lanzamiento de marca, formatos públicos, materias primas e ingredientes detallados, información nutricional, ficha técnica — dato verificable, sin margen de interpretación. |
| MARKETING_CLAIM | Posicionamiento oficial de marca, maridajes sugeridos, nota de cata — mensaje de marca, tratado como tal (no se mezcla con el dato técnico). |
| COMMERCIAL_GUIDANCE | El argumentario y el proceso de venta — ver abajo. |
Proceso de venta: seis etapas de visita
Cargado a partir de la presentación interna "Proceso de Ventas Propio 2024". Cada etapa es su propio fragmento — objetivo, contexto necesario, acciones, bloqueos o riesgos, y criterio de finalización — recuperable por el motor de RAG igual que cualquier ficha de producto, no como un flujo aparte:
| 1. Preparar la visita | Llegar con contexto del cliente, objetivo y materiales adecuados. |
| 2. Entrada en el cliente | Conseguir atención y construir confianza con preguntas abiertas. |
| 3. Gestiones básicas | Asegurar crédito, stock y referencias esenciales. |
| 4. Gestiones extra | Presentar una solución adicional y anticipar objeciones. |
| 5. Cierre y despedida | Confirmar acuerdo, pedido, entrega e importe sin cabos sueltos. |
| 6. Seguimiento postventa | Comprobar satisfacción y cumplir los compromisos adquiridos. |
Argumentario de objeciones
Cinco objeciones habituales de un punto de venta, cada una con su propia ficha de respaldo para que el agente ofrezca la réplica adecuada en vez de una genérica:
Precio
"Es más caro que lo que ya tengo."
Poca rotación
"No sé si se va a vender aquí."
Falta de espacio
"No tengo hueco en la barra/cámara."
Complicación operativa
"Es lío para el personal."
Ya trabajo con otra marca
La objeción de lealtad a un competidor ya establecido en el punto de venta.
A esto se suman fichas de preguntas de descubrimiento, checklist de cierre, una plantilla de resumen tipo CRM y una rúbrica para evaluar un discurso comercial (pensada para coaching, no para el cliente final) — todas recuperables por el mismo mecanismo de búsqueda híbrida descrito en la sección anterior.
4. La capa de negocio
Lo que diferencia al sistema de un chatbot genérico envuelto en voz: un prompt de sistema con un rol y reglas de negocio concretas, no un asistente de propósito general.
Rol definido
"Copiloto comercial conversacional para profesionales de hostelería" — no un asistente genérico. Español de España, tono de compañero comercial, respuestas breves para no alargar la latencia percibida.
Reglas para salida hablada
Prohibido markdown, comodines tipo "[tu nombre]" y plantillas a rellenar. Si se pide un guion o frase, se entrega ya utilizable con datos reales, nunca como hueco a completar.
Guion de objeciones
Ante una objeción del cliente final, prioriza dar al comercial una frase que decir y una única pregunta de descubrimiento — no una lista genérica de argumentos.
Resumen tipo CRM
Bajo demanda, devuelve cliente/contexto, interés, objeciones, acuerdos y próximo paso a partir del propio historial de la conversación — ya funciona hoy, sin integración externa todavía.
Regla de cierre y filtro determinista
El prompt prohíbe explícitamente coletillas de IA ("¿te puedo ayudar en algo más?", "aquí estoy"), pero un modelo de lenguaje puede emitirlas igualmente pese a la instrucción. Por eso hay, además, un filtro determinista por código: retiene la última frase de cada respuesta y la descarta si coincide con un patrón de coletilla conocido — nunca vacía la respuesta entera, y el mismo filtro se usa tanto en producción como en la evaluación automática de calidad, para medir lo que realmente se dice y no solo lo que el prompt pide.
Memoria de conversación
Ventana acotada a los últimos ~20 turnos o 8.000 caracteres (lo que se alcance antes). Se reconstruye en cada turno junto con el prompt de sistema y el contexto RAG recuperado — no hay resumen ni persistencia entre sesiones todavía.
5. Control de alucinación: verificación automática
Además de las reglas de grounding del prompt (sección 2), hay tres baterías de test automatizadas que se ejecutan contra el release publicado real — no contra una maqueta — antes de dar por buena una versión del sistema. Cada una comprueba algo distinto:
Batería general de preguntas
47 preguntas reales de referencia lanzadas contra el sistema completo (recuperación + respuesta). No tiene un veredicto automático de aprobado/suspenso: vuelca pregunta, evidencia recuperada y respuesta generada para revisión humana — sirve para detectar qué documentación falta antes de que lo note un comercial en campo.
Precisión del buscador sobre el proceso de venta
22 preguntas específicas del proceso de venta y el argumentario, cada una con el fragmento que "debería" salir. Mide en qué posición aparece ese fragmento en los resultados (rango medio recíproco) — controla la mitad del problema que no depende del modelo de lenguaje: si el buscador no encuentra el dato correcto, no hay prompt que lo arregle después.
Verificación de la respuesta final
19 casos que ejecutan el sistema entero de punta a punta — recuperación, generación con el modelo real y filtro de cierre — y comprueban tres cosas por caso: que se haya usado el fragmento de evidencia esperado, que la respuesta contenga el lenguaje que tiene que contener, y que no contenga lenguaje prohibido (ni el específico del caso — p. ej. una cifra o un término que no debería aparecer — ni las coletillas de IA de la lista global).
Es un gate real: si un solo caso falla, el proceso termina en error. No es una métrica de referencia que se pueda ignorar — bloquea.
Las tres baterías corren sobre datos y modelo reales de producción, no sobre ejemplos sintéticos ni una versión simplificada del sistema — el mismo camino que sigue una conversación real es el que se está verificando.
6. Observabilidad y coste
Cada turno se liquida individualmente en el momento: tokens de entrada/salida del LLM, milisegundos de audio de STT y TTS, coste en USD por proveedor, y latencias derivadas (tiempo al primer token, tiempo al primer audio, tiempo de boca a oído). Este es el registro de actividad real que ya alimenta hoy los números de coste de la propuesta — no una promesa de instrumentación futura.
7. Estado actual de la ingesta de conocimiento
El esquema de base de datos ya está preparado para múltiples marcas y para un flujo de aprobación completo por release (borrador → evaluación → aprobado → publicado → archivado/revocado). El sistema en marcha está fijado hoy a una única organización, marca y release publicados por configuración.
Añadir o corregir conocimiento no toca el código del agente ni requiere redesplegarlo — es justo lo que hace posible la lógica agéntica descrita en la propuesta: el comportamiento vive en datos, no en el binario. Hoy, quien da de alta ese conocimiento lo hace igual de forma agéntica — hablando directamente con un agente que ejecuta el cambio — solo que del lado del estudio, no todavía como autoservicio directo del cliente a través de un panel propio.