LLMs Creación RAG Académicos

Los Large Language Models (LLMs) — modelos de lenguaje de gran escala como Claude, GPT-4 o Gemini — son sistemas de inteligencia artificial entrenados sobre corpus masivos de texto que les permiten generar, analizar y sintetizar lenguaje con una coherencia y fluidez que, en contextos profesionales, puede resultar indistinguible del texto humano. Su funcionamiento, sin embargo, no es el de una base de conocimiento consultable: es el de un sistema de predicción probabilística que genera la secuencia de tokens estadísticamente más probable dado un contexto. Esa distinción no es técnica irrelevante para el abogado o el contador que los usa en su práctica — es la distinción que explica por qué un LLM puede producir una tesis jurisprudencial del TFJA que nunca existió, con número de expediente, sala y rubro perfectamente verosímiles, sin que el modelo "sepa" que está inventando. El conocimiento de los LLMs es estático, cerrado en el momento del entrenamiento y no actualizable en tiempo real. El derecho mexicano, la normativa fiscal y la jurisprudencia del TFJA y la SCJN no lo son. Esa brecha entre el entrenamiento del modelo y la realidad normativa vigente es el problema que los sistemas RAG resuelven.

La Retrieval Augmented Generation (RAG) — Generación Aumentada por Recuperación — es una arquitectura que combina un modelo de lenguaje con un sistema de recuperación de información sobre una base documental externa definida por el usuario. A diferencia de un LLM de propósito general, que responde desde su conocimiento de entrenamiento, un sistema RAG recupera primero los fragmentos más relevantes de la base documental propia y los proporciona al modelo como contexto antes de generar la respuesta. El resultado es cualitativamente distinto: el modelo no inventa — cita, sintetiza o analiza documentos reales que el usuario puede verificar. Para un despacho jurídico que trabaja con jurisprudencia del TFJA, tesis de la SCJN, resoluciones administrativas del SAT y normativa de seguridad social, un sistema RAG construido sobre esa base permite consultar el acervo documental propio con lenguaje natural y obtener respuestas fundamentadas en documentos verificables, no en la memoria estadística de un modelo entrenado hace meses. La diferencia entre ambos enfoques, en un contexto donde una referencia normativa incorrecta puede comprometer la posición de un cliente en un proceso contencioso, no es de grado — es de naturaleza.

La arquitectura técnica de un sistema RAG comprende cuatro componentes que operan en secuencia. El modelo de embedding convierte los documentos de la base — contratos, resoluciones, tesis jurisprudenciales, normativa — en representaciones vectoriales numéricas que capturan su significado semántico. La base de datos vectorial almacena esos vectores y permite búsquedas por similitud semántica — no por coincidencia exacta de palabras, sino por proximidad conceptual. El LLM recibe los fragmentos recuperados como contexto y genera la respuesta integrando ese contexto con su capacidad de síntesis y análisis. El orquestador — implementado típicamente con frameworks como LangChain o LlamaIndex — coordina el flujo entre estos componentes: recibe la consulta del usuario, ejecuta la búsqueda en la base vectorial, selecciona los fragmentos más relevantes y los proporciona al LLM con las instrucciones adecuadas. Cada componente tiene alternativas con perfiles de costo, velocidad y privacidad distintos — y la elección entre ellos no debe hacerse por popularidad sino por las restricciones concretas del entorno en que el sistema operará, particularmente las derivadas de la confidencialidad de los datos que procesará.

El diseño de un sistema RAG para el entorno jurídico y fiscal mexicano enfrenta restricciones que los tutoriales genéricos de implementación técnica no contemplan. La Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) impone condiciones específicas al tratamiento automatizado de información personal que los expedientes de clientes invariablemente contienen. Un sistema RAG que procesa contratos, declaraciones fiscales o expedientes laborales debe diseñarse con componentes que garanticen que los datos no se transmiten a servidores externos sin el consentimiento adecuado — lo que en la práctica significa evaluar si el embedding model y el LLM operan en infraestructura propia o en APIs externas, y qué acuerdos de confidencialidad cubren el tratamiento de datos en cada caso. El chunking — la segmentación de los documentos en fragmentos para su indexación — tiene una dimensión jurídica propia: un contrato segmentado incorrectamente puede generar recuperaciones parciales que omiten cláusulas determinantes para el análisis, produciendo respuestas que el sistema presenta como fundamentadas pero que son materialmente incompletas. La calidad del sistema RAG depende, más que de la sofisticación del LLM, de la calidad del proceso de indexación de la base documental — y ese proceso requiere criterio del dominio, no solo conocimiento técnico.

El problema de los LLMs de propósito general en el entorno jurídico

El problema es específico y documentable. Un modelo como GPT-4 o Claude fue entrenado sobre corpus de texto que incluye doctrina jurídica, legislación y jurisprudencia — pero ese entrenamiento tiene una fecha de corte, no discrimina entre el derecho mexicano y el de otras jurisdicciones con el nivel de precisión que el trabajo profesional requiere, y no tiene acceso a los documentos propios del despacho ni a la jurisprudencia más reciente del TFJA.

El resultado en la práctica es conocido por cualquier abogado o contador que haya usado un LLM para investigación jurídica con cierta profundidad: el modelo produce referencias plausibles que no siempre existen, cita artículos con numeración correcta pero contenido desactualizado, y responde con la misma seguridad cuando acierta que cuando inventa. Detectar la diferencia exige verificar cada referencia de forma independiente — lo que consume el tiempo que la herramienta supuestamente ahorró. La ingeniería de prompts aplicada puede reducir la tasa de error, pero no resuelve el problema estructural: el modelo no tiene acceso a los documentos que el despacho necesita consultar.

El sistema RAG resuelve ese problema con una solución arquitectónica, no con una mejora del modelo. Si el sistema solo puede responder con base en los documentos que el usuario le proporcionó, la probabilidad de invención se reduce drásticamente — y las respuestas son verificables porque el sistema puede citar el fragmento exacto del documento que las fundamenta. Combinado con procesos de automatización de tareas profesionales, el sistema RAG forma parte de una infraestructura de trabajo que multiplica la capacidad operativa sin incrementar el volumen del equipo.

Marco técnico y normativo

Restricción de confidencialidad aplicable al diseño

Ley Federal de Protección de Datos Personales en Posesión de los Particulares · Artículo 8, párrafo primero

"Todo tratamiento de datos personales estará sujeto al consentimiento de su titular, salvo las excepciones previstas por la presente Ley."

Ley Federal de Protección de Datos Personales en Posesión de los Particulares · Artículo 36

"Las transferencias nacionales o internacionales de datos podrán llevarse a cabo sin el consentimiento del titular cuando la transferencia sea efectuada a sociedades controladoras, subsidiarias o afiliadas bajo el control común del responsable, o a una sociedad matriz o a cualquier sociedad del mismo grupo del responsable que opere bajo los mismos procesos y políticas internas."

Estos artículos determinan una restricción de diseño no negociable en cualquier sistema RAG que procese expedientes de clientes, contratos o documentación fiscal con datos personales. El tratamiento automatizado de esa información mediante APIs externas — embedding models o LLMs en la nube de terceros — requiere análisis previo del marco de consentimiento aplicable y de los acuerdos de confidencialidad disponibles con el proveedor tecnológico. La elección entre un sistema con componentes locales (on-premise) o con APIs externas no es solo técnica — es una decisión con consecuencias jurídicas bajo la LFPDPPP que debe tomarse con criterio de cumplimiento, no solo de conveniencia operativa. La IA aplicada en la contaduría y el derecho exige precisamente ese tipo de análisis integrado: técnico y jurídico de forma simultánea.

Arquitectura técnica base

La elección de componentes locales (Chroma + Llama-3 en servidor propio) garantiza que los datos no salen de la infraestructura del despacho — relevante cuando los documentos contienen información fiscal o laboral de clientes. Los componentes en la nube (Pinecone + Claude/GPT-4o vía API) ofrecen mayor capacidad de procesamiento con menor costo de infraestructura, pero requieren análisis previo de las condiciones de tratamiento de datos del proveedor. La fiscalización algorítmica del SAT procesa datos que los despachos manejan a diario — y ese contexto debe informar las decisiones de arquitectura del sistema RAG que esos mismos despachos diseñen.

En qué consiste el servicio

El servicio comprende el diseño, implementación y documentación de sistemas RAG orientados a bases documentales jurídicas, fiscales y de cumplimiento regulatorio. No se entrega una instalación genérica de software: se construye un sistema adaptado a la base documental específica del despacho o área profesional, con el proceso de indexación diseñado para el tipo de documento que se consultará y con los criterios de confidencialidad que el contenido de esa base impone.

Etapa 1 — Diagnóstico documental

Inventario de la base documental disponible: qué tipos de documentos existen (tesis jurisprudenciales, resoluciones, contratos, expedientes, normativa), en qué formato están, qué volumen representan y qué restricciones de confidencialidad aplican a su tratamiento automatizado.

Etapa 2 — Diseño de arquitectura

Selección de componentes según el perfil de confidencialidad, el volumen documental y el nivel técnico del equipo que operará el sistema. Definición de la estrategia de chunking adaptada al tipo de documento jurídico — un contrato segmenta distinto que una tesis, que segmenta distinto que una resolución administrativa.

Etapa 3 — Indexación y prueba

Conversión de la base documental a vectores semánticos, construcción de la base vectorial y pruebas de recuperación con consultas representativas del trabajo real del despacho. Ajuste de parámetros de recuperación (número de fragmentos, umbral de similitud) hasta obtener resultados con la precisión requerida.

Etapa 4 — Capacitación y transferencia

El equipo aprende a consultar el sistema, a interpretar las respuestas con criterio de validación — el sistema RAG reduce la probabilidad de alucinación pero no la elimina — y a mantener la base documental actualizada conforme se incorporan nuevos documentos. Un sistema RAG que no se actualiza sistemáticamente pierde relevancia en proporción directa a la velocidad con que evoluciona la normativa que indexa.

Por qué con Gabriel Aranda Zamacona

Construir un sistema RAG para un despacho jurídico o un área contable no es un proyecto de desarrollo de software. Es un proyecto que requiere criterio del dominio — saber cómo se estructura una tesis del TFJA, qué partes de un contrato REPSE son las más frecuentemente consultadas, cómo segmentar una resolución del SAT para que la recuperación semántica devuelva el fragmento correcto y no el contexto que lo rodea.

Un desarrollador sin conocimiento del derecho y la contaduría mexicanos puede implementar la arquitectura técnica correctamente y producir un sistema que recupera fragmentos irrelevantes porque el chunking no respeta la estructura lógica del documento jurídico. Gabriel Aranda Zamacona combina más de 25 años de práctica activa en litigio y consultoría con formación técnica en inteligencia artificial aplicada al derecho — lo que permite diseñar el proceso de indexación con el mismo criterio con que se lee el expediente: sabiendo qué parte del documento importa, cuándo el contexto es determinante y cuándo puede omitirse sin pérdida de precisión en la recuperación.

El trabajo no produce resultados garantizados. Lo que produce es un sistema adaptado a la realidad documental del despacho, construido con criterio del dominio jurídico y fiscal mexicano, con decisiones de arquitectura que respetan las restricciones reales de confidencialidad — no las que se asumen por conveniencia.