Una constante le gana a una base vectorial, hasta que ya no

Ocho mil palabras de playbook del dominio caben en un prompt. Entregamos una constante en lugar de un sistema de retrieval.

Uno de nuestros productos carga con un cuerpo serio de método: cómo opera un buen consejo de administración, cómo se ve una agenda de verdad, qué va en una minuta. El reflejo en 2026 es retrieval: partirlo en chunks, sacarle embeddings, levantar una base vectorial, buscar en runtime.

Nosotros lo pusimos en una constante de string. El playbook completo viaja en el system prompt, y el prompt caching deja el costo de las repeticiones casi en cero. Los turnos que siguen pagan una fracción del primero.

Por qué gana la versión tonta

El retrieval agrega maquinaria de verdad: una base de datos que operar, un pipeline de indexado que mantener, un problema de relevancia que debuggear cuando el modelo contesta desde el chunk equivocado. Una constante no tiene nada de eso. No puede regresar el pasaje equivocado, porque los regresa todos. A ocho mil palabras el corpus completo cabe con holgura; no hay nada que rankear.

La línea donde se voltea

El retrieval se gana su lugar cuando el corpus ya no cabe en el prompt, en algún punto pasadas las treinta mil palabras, o cuando cada cliente trae sus propios documentos y el conocimiento deja de ser un solo playbook compartido. Esos umbrales son reales, y cruzarlos es una decisión de producto, no un default.

Dejamos el cambio escrito en el diseño: la constante vive detrás de una sola función, así que el día que el retrieval se lo gane, es un query en lugar de un string. Hasta ese día, la versión aburrida es más rápida, más barata y da más confianza.