Generador de propuestas con IA: cómo construimos uno real sobre una base de conocimiento
Un generador de propuestas con IA es un sistema que produce propuestas comerciales completas (documento final, precios, alcance, formato de la empresa) a partir del conocimiento real del negocio: su inventario, sus tarifas, sus propuestas históricas y el criterio de su equipo. La diferencia entre un generador que sirve para trabajar y uno que produce texto genérico con membrete no está en el modelo de lenguaje: está en la base de conocimiento que tiene abajo.
En esta guía contamos cómo construimos uno de verdad: el generador de propuestas que desarrollamos para Envision, una agencia de medios que opera en Argentina y el resto de LATAM, montado sobre una base de conocimiento propia. No es un tutorial de "conectá ChatGPT a un template": es la arquitectura real, capa por capa. Con este sistema, una propuesta que antes tomaba horas de armado manual sale en minutos, con el formato de siempre y los datos reales de la agencia.
El problema: el conocimiento comercial no estaba en ningún sistema
Envision arma media plans: propuestas de inversión publicitaria que combinan medios (vía pública, radio, digital) por ciudad, con tarifas, specs y estrategia. Antes del build, ese proceso tenía la forma que tiene en la mayoría de las empresas de servicios:
El inventario y las tarifas vivían en planillas, con versiones que solo algunas personas sabían cuál era la vigente.
Las propuestas históricas eran archivos en carpetas, existían, pero nadie podía preguntarles nada (“¿qué le propusimos a este cliente el año pasado?” era una tarea de arqueología, no una consulta).
El criterio comercial estaba en cabezas, qué mix funciona para qué tipo de campaña, qué argumentos convencen, qué se corrigió la última vez.
Cada propuesta pasaba por diseño, el equipo comercial dependía de otra área para producir el documento final, con el cuello de botella que eso implica.
Este diagnóstico es el punto de partida de casi todo proyecto de base de conocimiento con IA: la información existe, pero está guardada, no disponible. El generador de propuestas fue la puerta de entrada elegida porque ataca el proceso más repetitivo y más caro en horas senior del área comercial.
Por qué un SaaS genérico no resuelve esto
La búsqueda "generador de propuestas con IA" devuelve casi exclusivamente herramientas SaaS: escribís un prompt o completás un formulario y la IA redacta una propuesta con buen aspecto. Para un freelancer que necesita un documento presentable, alcanzan. Para una empresa cuyo negocio es la propuesta (una agencia de medios, una consultora, una constructora), el problema es otro:
| Criterio | SaaS genérico de propuestas | Generador propio sobre base de conocimiento |
|---|---|---|
| Conocimiento del negocio | Ninguno: redacta desde el prompt | Inventario, tarifas y specs reales de la empresa |
| Datos y precios | Los tipeás vos en cada propuesta (o los inventa) | Salen de la fuente de verdad, siempre vigentes |
| Formato | Templates de la herramienta | El template exacto de la empresa (PDF y Excel) |
| Historial | Cada propuesta arranca de cero | Recupera propuestas aprobadas similares como referencia |
| Aprendizaje | No aprende de tus correcciones | Cada propuesta aprobada y cada feedback alimentan la base |
| Propiedad | Tus propuestas en la nube de un tercero | El cliente es dueño de la instancia y de sus datos |
La fila decisiva es la primera. Un modelo de lenguaje sin acceso al conocimiento de la empresa solo puede hacer una cosa: inventar con elegancia. En una propuesta comercial, un precio inventado no es un error estético, es un problema contractual. Por eso la pregunta correcta no es "¿qué IA redacta mejor?" sino "¿de dónde saca los datos?".
La arquitectura: tres capas, de abajo hacia arriba
El sistema que construimos para Envision tiene tres capas, y el orden importa: el generador es lo que se ve, pero la base de conocimiento es lo que lo vuelve confiable.
La base de conocimiento (el cerebro)
Una base de datos Postgres con pgvector donde vive el conocimiento comercial estructurado: inventario de medios, propuestas históricas con su feedback, guía de estilo y criterios. Es la implementación concreta de lo que llamamos el cerebro de la empresa.
La capa de consulta (retrieval)
Búsqueda híbrida (semántica + texto completo en español) que encuentra el conocimiento relevante para cada pedido, con citas a la fuente.
El generador (la aplicación)
Una app web Next.js donde el equipo comercial carga los parámetros de la campaña y obtiene la propuesta terminada en el formato real de la agencia, en PDF y Excel, sin pasar por diseño. La generación del PDF corre con Chromium en el propio servidor, así el documento final es idéntico al template que la agencia ya usaba.
El build del generador tomó entre 4 y 6 semanas. La base de conocimiento se montó como fundación del mismo proyecto: es el patrón que usamos en todos los casos de este tipo, donde el primer microservicio útil siembra el cerebro que después alimenta todo lo demás.
La base de conocimiento por dentro
Un modelo de datos híbrido: tablas tipadas + chunks genéricos
La decisión de modelado más importante fue no meter todo en un solo formato. El esquema tiene dos niveles:
Tablas de primera clase para lo que el negocio conoce con estructura: propuestas (cliente, campaña, año, ciudades, estrategia, estado de aprobación), eventos de feedback y el inventario de medios. Sobre estas tablas se consulta con SQL determinístico: "las últimas propuestas aprobadas de este cliente" no necesita IA, necesita un WHERE.
Documentos y chunks genéricos para el conocimiento no estructurado: cada pieza se parte en fragmentos de texto con su embedding (vector de 1.536 dimensiones), sus metadatos de filtro (tipo de fuente, cliente, fecha, estado) y su referencia a la fuente original para poder citar.
Esta separación tiene una consecuencia de confiabilidad clave: el armado de propuestas nunca depende de la búsqueda semántica. Si el subsistema de embeddings falla, la búsqueda semántica se degrada; el generador sigue generando igual, porque sus datos duros salen de las tablas tipadas.
Chunking distinto para cada tipo de fuente
Un error común en proyectos RAG es partir todo el corpus con la misma tijera. Cada tipo de fuente tiene una granularidad natural:
Propuestas históricas → una “ficha” en lenguaje natural por propuesta (cliente, campaña, mix, feedback recibido), porque el JSON crudo embebe mal y la ficha describe lo que un comercial preguntaría.
Ítems de inventario → un chunk por medio: ya son atómicos.
Transcripciones de reuniones → ventanas de 500 a 800 tokens por turnos de conversación, con solapamiento de ~100 tokens y timestamps en los metadatos.
Documentos largos (políticas, briefs, contratos) → fragmentos recursivos de ~800 tokens, con página y sección para citar.
Todo cae en la misma tabla de chunks, así el retrieval es una sola consulta sin importar de qué fuente vino el conocimiento.
El conocimiento tiene versiones
Una tarifa de 2024 no es información falsa: es información vencida. El esquema versiona cada documento con estado (vigente / superado / archivado) y fechas de validez: cuando entra una tarifa nueva, la anterior no se borra, se marca como superada. La búsqueda por defecto solo devuelve conocimiento vigente; las consultas históricas pueden pedir explícitamente el archivo. Sin esto, el sistema más elegante del mundo termina cotizando con precios viejos, que es la manera más rápida de perder la confianza del equipo comercial.
Ingesta: el generador se alimenta solo
El mayor riesgo de una base de conocimiento no es técnico, es de mantenimiento: si cargarla requiere disciplina manual, muere en meses. La solución de ingeniería fue convertir al propio generador en el principal alimentador de la base:
Cada propuesta aprobada se ingesta automáticamente. El evento de aprobación dispara la creación de la ficha, el cálculo de embeddings y la escritura en la base. El equipo no “carga conocimiento”: trabaja, y el conocimiento queda.
La ingesta es best-effort, nunca bloqueante. Si el cálculo del embedding falla, la aprobación de la propuesta no falla: el chunk queda marcado como pendiente y un proceso de backfill lo levanta después. Una base de conocimiento jamás debe poder romper el flujo de trabajo que la alimenta.
Las fuentes externas entran por scripts de carga, corribles a demanda o por cron, con el mismo pipeline de chunking y versionado.
La regla cultural que instalamos con el sistema es simple: si no quedó registrado, para el sistema no existe. El diseño técnico está al servicio de esa regla, no al revés. El proceso completo de este enfoque (discovery de fuentes, estructura, ingesta, consulta, adopción) está desarrollado en cómo crear una base de conocimiento con IA.
Retrieval híbrido: porque "vector search" solo no alcanza
Las consultas reales de un equipo comercial son mayormente léxicas: nombres de clientes, de medios, de ciudades, tarifas puntuales. Exactamente el terreno donde la búsqueda vectorial pura falla y la búsqueda de texto completo brilla. Por eso la capa de consulta combina las dos desde el día uno:
Búsqueda semántica con pgvector (índice HNSW, distancia coseno) para preguntas conceptuales (“¿qué mix propusimos para campañas de lanzamiento?”).
Búsqueda de texto completo en español (tsvector de Postgres) para lo exacto: nombres, códigos, tarifas.
Fusión por Reciprocal Rank Fusion, que combina ambos rankings sin pesos a calibrar por cliente: cada resultado aporta según su posición en cada lista, no según scores que no son comparables entre sí.
Filtros de metadatos en la propia consulta (tipo de fuente, cliente, solo vigente) y un tope de 6 a 8 fragmentos por consulta, con límite de chunks por documento para que un solo archivo no monopolice el contexto.
Elegimos HNSW y no ivfflat como índice vectorial por una razón práctica: HNSW construye bien aunque la tabla arranque casi vacía, que es la realidad de toda base de conocimiento nueva. Y dejamos fuera, deliberadamente, todo lo que a esta escala es sobre-ingeniería: sin reranker, sin descomposición de queries, sin vector database dedicada. Cada una de esas piezas tiene un disparador documentado ("agregar si pasa X"), no un lugar por default.
Guardrails: cómo evita inventar
Un sistema que redacta propuestas comerciales tiene una obligación por encima de todas: no inventar. Los guardrails concretos del build:
Guard “no sé” antes de llamar al modelo. Si la búsqueda no encuentra fragmentos con relevancia suficiente, el sistema responde “no encontré eso en la base” sin invocar al LLM. Es la mitigación de alucinación más barata que existe: la respuesta inventada que no se genera no hay que detectarla.
Citas por afirmación. Cada respuesta de la capa de consulta referencia los documentos de los que salió. Trazabilidad por encima de cobertura: preferimos un “no sé” honesto a una respuesta fluida sin fuente.
Log de cada consulta (pregunta, fragmentos recuperados, scores, respuesta): es el dataset con el que se ajusta el umbral del guard y se evalúa la calidad del retrieval con datos reales de uso, no con intuición.
Degradación controlada. Si la base de conocimiento entera se cae, el generador sigue funcionando con su camino determinístico. La IA mejora el sistema; nunca es su punto único de falla.
Los datos duros nunca salen del modelo. Precios, medios y specs se leen de las tablas; el modelo de lenguaje redacta y estructura, no cotiza de memoria.
Decisiones de ingeniería que no se ven en la demo
Tres decisiones de arquitectura que definen si esto es un producto o una prueba de concepto:
Single-shot antes que agéntico. El agente de consulta hace una recuperación y una llamada al modelo (Claude, vía API), instruido para citar y decir "no sé". Un loop agéntico multi-paso sobre un retrieval sin madurar es la receta clásica de la demo que impresiona y a los tres meses alucina. La función de búsqueda ya quedó con forma de tool: escalar a agéntico es configuración futura, no reescritura.
Sin infraestructura prematura. A decenas de eventos por mes, una cola de mensajes es peso muerto: los estados en la propia base más un backfill periódico cumplen la misma función con una pieza móvil menos.
El cliente es dueño desde el día uno. La instancia, la configuración y los datos son de Envision; las claves de API del modelo son del cliente (el consumo va directo a su cuenta, sin intermediación). Lo que queda como propiedad intelectual nuestra es el motor reutilizable: el patrón de esquema, ingesta y retrieval que ya estamos replicando en otros builds.
Qué se construye después: el cerebro ya está sembrado
El generador de propuestas es el primer microservicio sobre la base de conocimiento, no el último. Con el cerebro montado y alimentándose solo, cada módulo nuevo se apoya en la misma fundación: un chat de consulta para el equipo comercial ("¿qué le propusimos a este cliente y qué feedback nos dio?"), historial de cliente unificado, procesamiento de reuniones hacia la base. Cada pieza se decide y se construye por separado, en el orden que el negocio priorice.
Ese es el modelo que defendemos para cualquier empresa mediana: no comprar "una plataforma de IA transversal", sino elegir el proceso que más duele, construir la herramienta que lo resuelve y dejar la base de conocimiento montada abajo. Si querés evaluar si tu empresa tiene un caso así, el pillar de bases de conocimiento explica cómo reconocerlo; y si preferís discutirlo directo sobre tu caso, hablemos.
Preguntas Frecuentes
¿Qué es un generador de propuestas con IA?+
¿No alcanza con un SaaS genérico de propuestas?+
¿Cómo hace la IA para usar los datos reales de la empresa?+
¿Qué es la base de conocimiento y por qué va abajo del generador?+
¿Cómo evita el sistema inventar precios o datos en una propuesta?+
¿Cuánto tarda construir un generador de propuestas a medida?+
¿Tu equipo pierde horas armando propuestas?
Te construimos un generador sobre tu propia base de conocimiento
Con tus tarifas, tu historial y tu formato. Reunión inicial sin cargo para entender tu proceso, implementación cotizada por scope.
Artículos Relacionados
Cerebro de empresa con IA: qué es y cómo funciona
Centralizá el conocimiento de tu empresa en una base que responde con IA, conectada a tus sistemas.
RAG para empresas: cuándo conviene y cuándo no
Qué es RAG, cuándo conviene frente a otras opciones y cómo se implementa en una empresa.
Cómo crear una base de conocimiento con IA: proceso real
El proceso real para crear una base de conocimiento con IA, paso a paso.