Tu IA responde mal. Casi nunca es culpa del modelo.
Se inventa datos, contesta sobre la entidad equivocada, cuesta más de lo previsto, o el equipo simplemente dejó de confiar. Lo medimos, encontramos por qué falla y lo llevamos a calidad de producción.
En resumen
- Si una implementación de IA no está rindiendo, está en la mayoría: el 73% de los proyectos empresariales nunca llega a producción.
- El modelo de lenguaje casi nunca es el problema. Lo es cómo se preparó y se recupera la información, y esa parte se reconstruye sin botar el resto.
- Los cinco fallos que aparecen casi siempre: responde sobre la entidad equivocada, inventa cuando no sabe, nadie mide la calidad, el costo crece más rápido que el uso, y la información quedó vieja.
- El diagnóstico toma una semana y entrega un conjunto de referencia con preguntas reales, medición separada de recuperación y generación, y los fallos ordenados por impacto — todo en formato abierto y propiedad del cliente.
Antecedente de operación
Tres años de operación del sistema en producción, no una entrega y una salida.
El fallo más frecuente de las arquitecturas RAG, resuelto con metadata estructurada en la ingesta.
La propuesta llega en 48 horas con alcance, precio y fecha fijos. Si el alcance cambia, se cotiza aparte y se aprueba antes.
Estás en la mayoría, no en la excepción
Si contrataste una implementación de IA y no está rindiendo, acompañás al 73% del mercado. Las causas documentadas son casi siempre las mismas: implementación sin criterio técnico, expectativas mal fijadas desde la venta, y proveedores entregando demos disfrazadas de producto.
La buena noticia es que el modelo de lenguaje casi nunca es el problema. Lo es cómo se preparó y se recupera la información — y esa parte se puede reconstruir sin botar el resto.
Lo que encontramos casi siempre
- Responde bien, sobre la cosa equivocada. La respuesta suena correcta y nadie la audita. Pasa porque el sistema busca por parecido semántico entre entidades casi idénticas. Se arregla con metadata estructurada en ingesta y filtrado por entidad antes de rankear.
- Se inventa cosas cuando no sabe. Se corrige con restricciones de fundamento, citación obligatoria y negativa explícita cuando la búsqueda vuelve vacía.
- Nadie sabe si está respondiendo bien. Si tu proveedor no puede mostrar un número de calidad, no es que el número esté malo: nunca se midió.
- La factura crece más rápido que el uso. Se manda el modelo más caro con todo el contexto disponible a cada pregunta.
- La información está vieja y nadie lo notó. La carga fue manual, se hizo una vez, y nadie definió cómo se actualiza.
Una semana. Salís con números, no con opiniones.
- Construimos tu conjunto de referencia50 preguntas reales de tus usuarios con la respuesta correcta validada por tu equipo. Sin esto no hay medición posible, y es la parte que ningún proveedor hace porque da trabajo.
- Medimos recuperación y generación por separadoDistinguimos si el problema es que no encuentra la información o que la encuentra y la usa mal. Son dos enfermedades distintas con dos tratamientos distintos, y confundirlas es por qué muchos arreglos no arreglan nada.
- Revisamos el pipeline completoIngesta, fragmentación, embeddings, almacén vectorial, recuperación, prompt de sistema, enrutamiento de modelos y costo por consulta. Cada etapa con su hallazgo.
- Entregamos el informeLos fallos ordenados por impacto, el arreglo de cada uno con su esfuerzo estimado, y una recomendación clara: se rescata o se reconstruye, con los números que la sustentan.
El conjunto de referencia y el informe son tuyos, en formato abierto. Si decidís que lo arregle tu proveedor actual o tu equipo interno, tenés con qué exigirles y con qué verificar que lo hicieron.
Es la única forma de no volver a quedar en la misma posición dentro de seis meses.
Diagnóstico y remediación
| Alcance | Qué incluye | |
|---|---|---|
| Diagnóstico | Conjunto de referencia, medición completa e informe con fallos priorizados y su arreglo. | 1 semana |
| Remediación | Ejecución de los arreglos priorizados, con medición del antes y el después. | 3–5 semanas |
| Reconstrucción | Cuando rescatar cuesta más que rehacer. El diagnóstico se descuenta. | 4–8 semanas |
Servicios relacionados
Sistemas RAG
Segmentación, reordenamiento y búsqueda híbrida, evaluados con recall@k y NDCG.
Ver servicioConsultoría de IA
Arquitectura, criterios de evaluación y costo por consulta antes de escribir código.
Ver servicioModelos de lenguaje
Aplicaciones LLM con salida estructurada y llamada a herramientas.
Ver servicioChatbots y asistentes
Con el conjunto de evaluación ejecutado antes de la salida a producción.
Ver servicioPreguntas frecuentes
¿Vale la pena rescatarlo o es mejor empezar de cero?
En la mayoría de los casos se rescata, porque el modelo de lenguaje casi nunca es el problema: lo es cómo se preparó y se recupera la información, y esa parte se puede reconstruir sin botar el resto. El diagnóstico existe justamente para responder esa pregunta con datos en vez de intuición. Si la recomendación honesta es rehacerlo, te lo decimos y el diagnóstico se descuenta del proyecto nuevo.
¿Necesitan acceso a nuestros sistemas?
Para el diagnóstico necesitamos ver la información con la que se alimentó el sistema y una muestra de conversaciones o ejecuciones reales. Acceso a producción no hace falta. Se firma acuerdo de confidencialidad antes de que nos pases nada, y si tu información tiene datos personales trabajamos sobre una muestra anonimizada.
¿Funciona si lo construyó otro proveedor o una herramienta no-code?
Sí, y es el caso más frecuente. Hemos trabajado sobre implementaciones hechas en n8n, Make, plataformas de chatbot con suscripción y desarrollos a la medida. El diagnóstico es el mismo porque los fallos son los mismos: la tecnología cambia, los errores de diseño no.
¿Qué pasa si el problema es que nuestra información está desordenada?
Pasa seguido: cerca del 60% de las empresas que quieren implementar IA tiene procesos sin documentar e información dispersa. La IA no arregla el desorden, lo automatiza más rápido. Si ese es tu caso te lo decimos en el informe, con qué habría que ordenar primero y cuánto trabajo representa. Preferimos decirlo antes que cobrarte un rescate que iba a fallar.
¿Cuánto tarda en verse la mejora?
El diagnóstico toma una semana. La remediación, de tres a cinco semanas según alcance. Pero desde la primera semana de remediación ya hay medición corriendo, así que la mejora se ve como número y no como sensación. Ese es el punto de todo el proceso.
¿Pueden trabajar junto a nuestro proveedor actual?
Sí. En varios casos el rol es diagnosticar y entregar los hallazgos para que el equipo que lo construyó los ejecute, y después verificar que se implementaron correctamente. No hace falta cambiar de proveedor para arreglar el sistema.
¿Y si el problema es el costo, no la calidad?
Es un motivo de consulta cada vez más común. Se aborda con enrutamiento por tarea, recorte de contexto y caché de prompts, midiendo el costo por consulta antes y después. En sistemas que hemos optimizado, la reducción suele ser sustancial sin tocar la calidad percibida por el usuario.
¿Cómo empezamos?
Agendando una llamada de quince minutos donde nos describís los síntomas. Con eso solo ya te podemos decir si suena a alguno de los cinco fallos típicos y qué tan grave parece. No tiene costo y no hay insistencia después.
Agendá 15 minutos
Contanos qué estás construyendo o qué dejó de funcionar. Salís de la llamada con una respuesta concreta: se arregla, se construye, o no vale la pena.