Servicios de integración de IA generativa para equipos de software

La selección de proveedor es un problema de evaluación, no de marketing. Construimos un conjunto de evaluación específico de la tarea de 150 a 400 entradas representativas con salidas de referencia calificadas y puntuamos los modelos candidatos en calidad (LLM-as-judge más comprobación humana por muestreo sobre un subconjunto de 50 elementos), latencia en los p50/p95/p99 que realmente necesitamos y coste por 1k peticiones con nuestro mix de tokens. Alineación típica: GPT-4o o Claude 3.7 Sonnet para razonamiento, GPT-4o-mini o Claude 3.5 Haiku para clasificación, gpt-4o-realtime para voz y un modelo de pesos abiertos en vLLM para batch sensible al coste. Repetimos la evaluación cada trimestre porque la frontera se mueve.

RAG es lo correcto cuando las respuestas viven en un corpus que se actualiza más rápido de lo que se puede ajustar un modelo (políticas, documentación de producto, tickets, contratos). Es la respuesta equivocada cuando el modelo ya conoce el dominio (código general, conocimiento general), cuando la latencia está por debajo de 500ms p95 o cuando se necesitan salidas deterministas que el ajuste fino produce con más fiabilidad. A menudo combinamos: RAG para anclar en datos del cliente, un modelo pequeño ajustado para la estructura de la salida o el vocabulario del dominio y prompt engineering para la orquestación. El RAG puro es raro en producción. El ajuste fino puro es más raro aún.

Tres capas. En la entrada, un detector de PII (Microsoft Presidio o un clasificador ajustado) elimina o tokeniza correos, nombres, teléfonos e ID de cuenta antes de que el prompt salga de nuestra infraestructura. En el proveedor, contratamos retención cero de datos con OpenAI, Anthropic y Bedrock (con BAA firmados cuando proceda) y preferimos endpoints alojados en la UE para datos de la UE. En la salida, se analiza la respuesta para detectar PII alucinada antes de mostrarla al usuario. Los DPA se firman antes del inicio y mantenemos una lista de subencargados alineada con los contratos de cara al cliente.

Los prompts son código. Viven en el control de versiones, se revisan en pull requests y se etiquetan con versiones semánticas que se registran en cada inferencia. Cada cambio de prompt se ejecuta contra un conjunto de evaluación de regresión en CI (Ragas para la calidad de RAG, DeepEval o una rúbrica a medida para métricas específicas de la tarea) y no fusionamos si alguna métrica de nivel 1 empeora más de un 2 %. En producción registramos la versión del prompt, el modelo, la latencia y el coste en tokens por petición con LangSmith, Helicone o Langfuse para que pueda hacer pruebas A/B de prompts igual que de funcionalidades.

Sí. La mayoría de los proyectos se integran en un backend existente (Node, Python, Go, Java) y en una infraestructura existente (AWS, GCP, Azure) en lugar de ejecutarse en una plataforma aparte. No le empujamos a un orquestador específico de un proveedor si no lo necesita. Trabajamos en pareja con sus ingenieros, hacemos revisiones de código juntos y escribimos ADR para las decisiones de arquitectura, de modo que las elecciones sobrevivan a nuestro proyecto. La transferencia de conocimiento es contractual: al final del piloto, su equipo es dueño de la base de código, de las evaluaciones y del runbook.

Los proyectos son de alcance cerrado y ajustados, todo incluido y presupuestados en USD. Una prueba de concepto cuesta desde $2,900 (4–6 semanas); RAG sobre su base de conocimiento, desde $8,100; un agente de IA autónomo, desde $10,400; un modelo de ML en producción, desde $13,800. La cifra exacta depende de cuántos casos de uso entregue, la profundidad del corpus y el tamaño del conjunto de evaluación, los objetivos de latencia y el alcance de cumplimiento. Usted ve el presupuesto desglosado al final del descubrimiento y lo aprueba antes de que se escriba una sola línea de código. No hay recargo por intermediación ni sobrecostes por herramientas, y el gasto en nube y en tokens corre por sus propias cuentas, de modo que usted conserva el control del coste.

Tres categorías malgastan presupuesto de forma constante. Primero, las consultas deterministas: si la respuesta correcta es siempre una consulta a una base de datos o la salida de un motor de reglas, añadir un LLM aporta latencia y riesgo de alucinación sin ventaja. Segundo, las decisiones de bajo volumen y alto riesgo sin bucle de retroalimentación: un modelo que escribe una decisión de suscripción de seguros por semana y nunca se corrige no puede mejorar, y el coste del error es demasiado alto para aceptarlo. Tercero, los chatbots de vanidad: un wrapper de GPT-4 delante de una página de preguntas frecuentes que nadie lee sigue siendo una página de preguntas frecuentes que nadie lee. Incluimos una lista de «no construir esto» con su razonamiento en cada resultado de descubrimiento y le diremos cuándo un caso de uso pertenece a ella.

Una prueba de concepto lleva 4–6 semanas: descubrimiento, banco de evaluación, prototipo funcional y memorando go/no-go. Un sistema de RAG sobre su base de conocimiento, desde el inicio hasta un despliegue customer-zero tras un feature flag, suele llevar 10–14 semanas, incluidas la ingesta del corpus, el ajuste de la recuperación, el tratamiento de PII y la observabilidad. Un agente de IA autónomo suma 2–4 semanas más para el diseño de la orquestación, los puntos de supervisión humana y el runbook. Un modelo de ML en producción a partir de una línea base en notebook son 14–20 semanas según la preparación de los datos. La mayor variable son siempre sus datos: datos limpios, etiquetados y accesibles recortan semanas en cada fase.

Sí, y a menudo los mezclamos. Los modelos de pesos abiertos en vLLM (Mistral, Llama, Qwen) tienen sentido económico para clasificación batch de alto volumen y sensible a la latencia, donde un modelo de frontera alojado costaría 10 veces más con la misma calidad. Evaluamos el código abierto sobre el mismo conjunto de evaluación específico de la tarea que GPT-4o y Claude — si la diferencia de calidad es aceptable con el rendimiento y la latencia que necesita, entregamos la opción más barata. El autoalojamiento en su propio clúster de GPU o en un endpoint de inferencia gestionado (AWS SageMaker, GCP Model Garden, Azure AI) es algo que podemos diseñar y traspasar. No fingimos que el código abierto sea siempre la respuesta: en tareas de razonamiento complejo la diferencia de calidad es real y la evaluación la mostrará.

Tratamos la alucinación como un problema de ingeniería con cuatro palancas. Anclaje (grounding): RAG sustituye la memoria paramétrica por recuperación de un corpus verificado, de modo que el modelo cita una fuente en lugar de inventarla. Evaluaciones: un banco de regresión en CI detecta las regresiones de calidad antes de que lleguen a los usuarios — cazamos la alucinación en las pruebas, no en producción. Filtrado de salida: los esquemas de salida estructurada (Pydantic, instructor) restringen el formato de la respuesta; para campos de alto riesgo, un clasificador secundario o un motor de reglas valida la salida antes de mostrarla. Supervisión humana: en decisiones por encima de un umbral de confianza o en categorías de alto riesgo, derivamos a una persona en lugar de autocompletar. La combinación hace que la tasa de alucinación en producción sea un SLO medible y no una situación de «esperamos que funcione».