Guía práctica: implementar RAG en una empresa mexicana sin contratar un equipo de ML
Casi todas las empresas mexicanas con las que conversamos en los últimos seis meses tienen el mismo problema: toneladas de documentación interna (manuales, políticas, contratos, tickets históricos, procedimientos) y nadie que las consulte realmente porque están dispersas en SharePoint, Google Drive, correos viejos y cabezas de empleados que ya se fueron. Cuando preguntan "¿cómo aplicamos IA aquí?", la respuesta casi siempre empieza con las mismas tres letras: RAG.
RAG (Retrieval-Augmented Generation) no es la frontera más sexy de la IA. Pero es, sin discusión, el primer caso de uso con retorno claro para casi cualquier empresa mediana. Y lo bueno: ya no necesitas un equipo de machine learning para implementarlo. Si tienes un buen developer y un mes, tienes un piloto funcional.
Qué es RAG y por qué importa
RAG resuelve un problema concreto del LLM puro: los modelos no conocen tus datos. ChatGPT no sabe cómo está estructurado tu manual de cumplimiento, ni qué dice tu contrato marco con un proveedor específico, ni cómo respondió tu equipo de soporte el ticket #4827 hace dos años.
La solución obvia (subir todo el documento al prompt) no escala: las ventanas de contexto siguen siendo caras y los modelos se pierden cuando les das demasiado de golpe. RAG hace algo más inteligente:
- Indexa tu documentación convirtiéndola en vectores (embeddings) que capturan su significado.
- Cuando llega una pregunta, busca los fragmentos más relevantes en ese índice.
- Inyecta solo esos fragmentos al prompt del LLM, junto con la pregunta original.
- El modelo responde basado en tu información específica, citando fuente.
El resultado: respuestas precisas, basadas en tus datos reales, con referencias a los documentos originales. Sin reentrenar nada.
Los cuatro componentes que necesitas
Cualquier sistema RAG, desde el más sencillo hasta el más sofisticado, tiene los mismos cuatro bloques:
1. Embeddings. Un modelo que convierte texto en vectores. Para empezar, recomendamos text-embedding-3-small de OpenAI (barato, multilingüe decente) o bge-m3 si quieres alternativa abierta. Costo típico: menos de $5 USD por millón de tokens indexados.
2. Vector store. Donde guardas y buscas esos vectores. Para arrancar: pgvector sobre Postgres (si ya tienes Postgres, no agregues piezas nuevas), Pinecone (managed, sencillo) o Weaviate. Para volúmenes pequeños (menos de un millón de chunks), pgvector es más que suficiente.
3. LLM. El modelo que genera la respuesta final. GPT-4o-mini, Claude 3.5 Haiku o un modelo abierto como Llama 3.3 70B vía Together AI. Para casos de soporte interno, los modelos "mini" o "haiku" suelen bastar y cuestan una fracción.
4. Orquestador. El pegamento entre todo: recibe la pregunta, ejecuta búsqueda, arma el prompt, llama al LLM, devuelve respuesta. LangChain y LlamaIndex son las dos opciones más comunes. Si tu equipo es pequeño y quieres algo directo, LlamaIndex tiene mejor curva inicial. Si vas a crecer y necesitas integrar muchas piezas, LangChain.
Stack recomendado para arrancar en menos de 30 días
Esta es la combinación que más recomendamos en ALCA para una primera implementación seria:
- Backend: Python con FastAPI.
- Orquestación: LlamaIndex.
- Vector store: pgvector en una instancia de Postgres existente o un Supabase nuevo.
- Embeddings:
text-embedding-3-small. - LLM: GPT-4o-mini para preguntas estándar; GPT-4o para casos complejos.
- Frontend: un chat sencillo en Next.js o, mejor aún, integración directa en la herramienta donde ya está la gente (Slack, Teams, intranet).
Costo total estimado para un piloto con 10,000 documentos y 500 consultas diarias: menos de $300 USD al mes entre embeddings, LLM e infraestructura. La inversión real es el tiempo del equipo, no la factura de la nube.
Errores comunes que te van a costar tiempo
Después de varios proyectos hemos visto los mismos tropiezos repetirse. Vale la pena listarlos:
Chunking malo
Cortar los documentos en pedazos del tamaño correcto es el detalle que más diferencia hace entre un RAG que funciona y uno que da respuestas decepcionantes. Chunks de 500-1,000 tokens con overlap del 10-15% es un buen punto de partida. Para documentos muy estructurados (contratos, manuales con secciones), conviene chunking semántico que respete los headers, no cortes arbitrarios cada N caracteres.
No medir hallucination
Si tu RAG inventa cosas y nadie se entera, perdiste credibilidad. Implementa desde el día uno una evaluación básica: 30-50 preguntas con respuesta esperada, corre tu sistema contra ellas, mide accuracy. Repite cada vez que cambies algo (modelo, chunking, prompt). Herramientas como Ragas o LangSmith ayudan, pero hasta una hoja de cálculo sirve.
Pensar que "más datos = mejor"
Indexar todo el SharePoint sin curaduría es la forma más rápida de tener un RAG mediocre. Documentos duplicados, versiones viejas, borradores y plantillas vacías contaminan la búsqueda. Empieza con un corpus pequeño y limpio (200-500 documentos bien escogidos) y crece desde ahí.
Ignorar la experiencia de usuario
El chat puro no es la mejor interfaz para todos los casos. A veces lo correcto es integrar el RAG dentro de la herramienta donde está el usuario (un botón en el CRM que sugiere respuesta con base en tickets pasados, un comando de Slack, una sugerencia automática en el editor). El mejor RAG es el que la gente usa sin pensar.
Caso de uso ideal para empezar: base de conocimiento de soporte
Si nos preguntas por dónde arrancar, casi siempre la respuesta es la misma: un asistente interno para el equipo de soporte o atención a clientes. Razones:
- Tienes datos abundantes (tickets históricos, manuales, FAQs).
- El usuario final es interno, así que tolera imperfecciones del piloto.
- El ROI es medible: tiempo promedio de resolución, escalamientos evitados, onboarding de nuevos agentes.
- Si funciona bien internamente, después puedes exponerlo a clientes con más confianza.
En proyectos típicos vemos reducción del 30-40% en tiempo de búsqueda del agente y un onboarding de nuevos integrantes que pasa de semanas a días. Números reales, no marketing.
La conclusión operativa
RAG no requiere doctorados, ni equipos de 10 personas, ni infraestructura exótica. Requiere disciplina sobre datos, una buena selección de stack y voluntad de iterar. En 30 días tienes piloto. En 90, algo en producción que tu equipo usa todos los días.
Lo que no recomendamos: contratar a una consultora que te venda un "proyecto RAG" de seis meses con entregables vagos. Esto se construye en sprints cortos, con alguien que ya lo haya hecho antes acompañando a tu equipo.
En ALCA acompañamos a empresas mexicanas a aterrizar RAG sobre su documentación real. ¿Quieres validar si RAG aplica a tu caso de uso? Agenda 30 minutos con nosotros sin costo.
