Un asistente RAG sobre Snowflake Cortex, de SharePoint a producción en semanas
El montaje combina un agente de Snowflake, Cortex Search y Openflow para sincronizar la documentación desde SharePoint, con un presupuesto de 30 segundos y 20.000 tokens por consulta.
Un asistente de soporte construido sobre Snowflake Cortex, con búsqueda vectorial propia y sincronización automática de la documentación desde SharePoint. Eso es lo que describe el desglose técnico de un RAG que llegó a producción en semanas, no en meses, y que nació con un objetivo concreto: bajar el volumen de tickets en un producto SaaS B2B con muchas reglas propias por cliente.
El montaje se apoya en piezas que ya existían dentro de la plataforma, lo que evita levantar infraestructura aparte para la parte de IA y reaprovecha el mismo entorno de seguridad y datos.
Qué hay debajo
La arquitectura tiene cuatro bloques. Un agente de Snowflake como controlador, que decide qué herramienta usar y con qué formato responder. Un servicio de Cortex Search como almacén de embeddings del conocimiento del producto. Tablas de Snowflake donde ese conocimiento vive en forma normalizada: DOC_PATH, DOC_TYPE, CHUNK_INDEX y CONTENT, con la columna de texto usada como origen de la búsqueda semántica. Y stages para los documentos crudos, que llegan desde Microsoft SharePoint a través de Openflow.
El servicio de búsqueda se declara sobre CONTENT, con DOC_PATH, DOC_TYPE y CHUNK_INDEX como atributos filtrables, un TARGET_LAG de una hora y el modelo de embeddings snowflake-arctic-embed-l-v2.0. Ese retardo es la parte que conviene tener presente al operarlo: las filas nuevas o modificadas se indexan de forma asíncrona, así que el contenido recién ingestado puede tardar hasta esa hora en estar disponible para el agente.
El agente se define con auto orchestration, un presupuesto de 30 segundos y 20.000 tokens, y una única herramienta: cortex_search, expuesta como HelpSearch con una descripción que cubre funcionalidades, ajustes y flujos documentados. Las instrucciones insisten en buscar siempre antes de declarar algo fuera de alcance. Para extraer texto de los documentos en stage se usa SNOWFLAKE.CORTEX.PARSE_DOCUMENT, y un stream con su task lanza el procedimiento de carga de forma automática.
Agentes frente a workflows
El texto anticipa la objeción de siempre: que un agente no determinista gasta tokens y toma decisiones equivocadas, y que para eso están los pipelines y las APIs. La respuesta es que el resultado depende de cómo se use. Instrucciones claras, presupuesto acotado, comportamiento de fallback definido y pocos puntos donde la aleatoriedad pueda hacer daño. Las reglas del agente se pueden modificar sin recrearlo, así que ajustar las instrucciones es barato.
Un detalle que se subraya y que suele pasarse por alto: si el asistente y la documentación no están en inglés, el modelo de embeddings tiene que soportar esos idiomas o la recuperación semántica se degrada. No es un ajuste cosmético.
Lo que queda por ver: el desglose no trae métricas de calidad de respuesta ni comparación con alternativas, y montar todo esto exige permisos para crear bases de datos, esquemas y servicios de búsqueda que un rol corriente no tiene. Esa parte hay que resolverla antes de tocar nada.
