OpenAI function calling y GPT-3.5-turbo-16k: cómo se simplifica armar RAG en empresa

El 13 de junio OpenAI publicó dos novedades que se vieron como features menores en la prensa general pero que cambian de manera concreta cómo se construyen aplicaciones empresariales con sus modelos: function calling como capacidad nativa de los modelos GPT-4 y GPT-3.5, y GPT-3.5-turbo-16k, que cuadruplica la ventana de contexto de 4 mil a 16 mil tokens, todo con bajada significativa de precios.

Para equipos que han estado armando RAG (retrieval-augmented generation) y agentes en los últimos meses con bibliotecas como LangChain o LlamaIndex, los anuncios resuelven dos de los puntos más frágiles del stack actual. Para equipos que estaban por empezar, simplifican el camino de manera importante. Vale la pena entender qué cambia exactamente y qué patrones de diseño se vuelven la nueva norma.

Qué es function calling y por qué cambia las cosas

Hasta antes del 13 de junio, hacer que un modelo de OpenAI invocara una función externa o devolviera datos estructurados requería un truco común: pedirle en el prompt que respondiera en formato JSON con cierta estructura, parsear su respuesta con expresiones regulares o JSON parsers, y manejar los casos donde el modelo se desviaba (devolvía texto extra, malformaba el JSON, alucinaba campos). En proyectos serios, ese parsing era una fuente constante de bugs.

Con function calling, el desarrollador declara explícitamente al modelo qué funciones existen, con qué parámetros y de qué tipos, en un esquema JSON. El modelo decide cuándo invocar cada función, devuelve un objeto JSON bien formado con el nombre de la función y sus argumentos, y el desarrollador ejecuta la función y le devuelve el resultado al modelo para que continúe la conversación.

El cambio práctico es importante. La fragilidad del parsing manual desaparece. El modelo se vuelve mejor en seguir el esquema porque está entrenado específicamente para este flujo. Y se abre de manera natural el patrón de agentes con herramientas, que antes requería frameworks complejos para emularlo.

GPT-3.5-turbo-16k

El segundo anuncio fue GPT-3.5-turbo-16k, una variante del modelo más usado de OpenAI con ventana de contexto de 16 mil tokens, equivalente a unas 12 mil palabras o 30 páginas de texto. Antes era de 4 mil tokens, lo que limitaba seriamente cuánta información de contexto se podía pasar en una sola consulta.

El precio acompañó al cambio: GPT-3.5-turbo bajó a la mitad en input y se mantuvo competitivo en output, mientras que la versión 16k tiene precio modesto frente a la calidad que entrega para casos donde el contexto extenso resuelve el problema.

Para casos de RAG donde se recuperan documentos largos, o casos donde se necesita pasar conversación previa muy extensa, esto reduce la complejidad de tener que partir contenido en chunks pequeños y orquestar múltiples llamadas.

Cómo se arma RAG con estas nuevas capacidades

El patrón clásico de RAG hasta junio era más o menos así. Generar embeddings de los documentos. Almacenarlos en una vector DB. Cuando llega la consulta del usuario, generar embedding de la consulta, buscar los k documentos más similares, concatenarlos al prompt junto con la consulta, y mandar todo al modelo. El modelo responde con base en el contexto que se le pasó.

El nuevo patrón con function calling permite algo más rico. En lugar de buscar documentos siempre y meterlos al prompt, se declara una función buscar_documentos(query, filtros) y se deja que el modelo decida cuándo y cómo invocarla. El modelo puede hacer múltiples búsquedas con consultas distintas si la pregunta inicial es compleja, refinar la consulta con base en lo que encontró, o decidir no buscar en absoluto si la pregunta no requiere contexto externo.

Aplicado a un asistente interno de empresa, el patrón típico declara varias funciones.

• buscar_documentos(query, departamento, fecha_desde) para retrieval con filtros.
• obtener_dato_estructurado(tipo, identificador) para consultar bases de datos internas.
• crear_ticket(sistema, prioridad, asunto, descripcion) para acciones que escriben en sistemas internos.
• escalar_a_humano(motivo, contexto) para casos donde el modelo decide que no puede o no debe responder solo.

El modelo razona sobre la consulta del usuario, decide qué funciones necesita y en qué orden, y va componiendo la respuesta con resultados reales en lugar de inventar.

Comparativa con LangChain y LlamaIndex

LangChain y LlamaIndex son frameworks que se popularizaron en los últimos meses precisamente para resolver el problema de orquestar prompts, herramientas y memoria. Con function calling nativo, ¿siguen siendo necesarios?

La respuesta corta. Para casos sencillos, function calling nativo de OpenAI cubre lo que antes requería LangChain. Para casos más complejos (memoria sofisticada, múltiples modelos, evaluación, herramientas estandarizadas, switching entre proveedores), los frameworks siguen aportando.

La recomendación pragmática que damos en pilotos. Empezar directo con la API de OpenAI y function calling. Si el caso crece y necesita capacidades adicionales, añadir LangChain o LlamaIndex como capa de orquestación. Empezar con el framework cuando el caso es simple suele añadir complejidad innecesaria que después cuesta quitar.

Los nuevos patrones que recomendamos

Tres patrones que en pilotos recientes están funcionando bien.

Asistente interno con catálogo de funciones acotado. Cinco a diez funciones bien definidas que tocan los sistemas internos relevantes (CRM, ERP, base de conocimiento, sistema de tickets). El modelo decide cuándo invocar qué. Cobertura amplia de casos sin construir un menú rígido de opciones.

Extracción estructurada de información. Una sola función que define el esquema JSON que se quiere extraer (datos de un correo, campos de una factura, atributos de un producto), y se le pasa al modelo el texto fuente. El modelo devuelve los datos estructurados directamente. Reemplaza pipelines complejos de NLP en muchos casos.

Pipeline de agentes con herramientas auditables. Un agente con función consultar_X, analizar_Y, proponer_Z y notificar_humano. Cada invocación queda registrada con sus argumentos y resultados. Si un humano necesita auditar por qué tomó cierta decisión, hay traza completa.

Lo que sigue siendo difícil

Function calling resuelve la fragilidad del parsing y abre patrones nuevos, pero no resuelve todo.

La calidad de la decisión sobre cuándo invocar qué función sigue dependiendo de la calidad del prompt y de la descripción de cada función. Funciones mal descritas siguen llevando al modelo a invocaciones equivocadas.

La gestión de contexto en conversaciones largas sigue requiriendo decisiones de diseño. La ventana de 16k de GPT-3.5 ayuda, pero conversaciones que duran días o que acumulan mucho contexto siguen necesitando estrategias de resumen y memoria selectiva.

Las acciones con efectos en sistemas externos siguen requiriendo confirmación humana o circuit breakers cuando el costo del error es alto. Function calling no es excusa para dejar al modelo decidir solo si aplica un descuento de 30 mil pesos.

Qué hacer en tu empresa esta semana

Si tu equipo ya está construyendo o pensando en construir aplicaciones con OpenAI, tres acciones concretas.

Primero, migrar los flujos donde estás haciendo parsing manual de respuestas a function calling. Reduce bugs y mejora la robustez del sistema sin trabajo grande.

Segundo, evaluar si GPT-3.5-turbo-16k cubre casos donde estás usando GPT-4 solo por la ventana de contexto. La diferencia de costo es importante.

Tercero, identificar uno o dos casos de uso de asistente interno donde un agente con tres a cinco funciones bien definidas resolvería problemas que hoy se resuelven con UI rígida o con procesos manuales.

---

¿Estás armando RAG? Hagamos una arquitectura juntos. En ALCA tenemos un proceso de tres semanas que entrega arquitectura de referencia, prototipo funcional y plan de despliegue para tu caso específico. Agenda una llamada y arrancamos.