En resumen: la mayoría de los productos de Legal AI son arquitectónicamente idénticos. Su pregunta se dirige a un modelo de propósito general con una plantilla de "prompt" a su alrededor, y no se puede saber desde la interfaz. La diferencia que importa ocurre antes de que se llame al modelo. Cuatro preguntas al final de esta publicación le dirán qué tipo de sistema le está vendiendo cualquier proveedor, en unos diez minutos de demostración.
Todo abogado que evalúa Legal AI eventualmente hace la misma pregunta, generalmente a los ocho minutos de una demostración: ¿en qué se diferencia esto de simplemente usar ChatGPT?
Es la pregunta correcta, y la mayoría de los proveedores la responden mal. Hablan de datos de entrenamiento, o de un corpus propietario, o de un ajuste fino. Esas respuestas son difíciles de verificar y, la mayoría de las veces, no es ahí donde reside realmente la diferencia.
La respuesta honesta es arquitectónica, y se reduce a una cosa: ¿dónde ocurre el pensamiento?
El problema del "wrapper" es real e invisible desde el exterior
Una gran parte de los productos de Legal AI funcionan así. Usted escribe una pregunta. El producto la envuelve en una plantilla de "prompt", algunas instrucciones sobre cómo ser un asistente legal útil, quizás algunos ejemplos, y reenvía todo a un modelo de propósito general. El modelo responde. El producto formatea la respuesta de forma agradable y se la muestra.
No hay nada deshonesto en esto. Puede ser genuinamente útil. Pero significa que la calidad del producto es casi en su totalidad la calidad del modelo, y el modelo es el mismo al que su abogado contrario puede acceder por veinte dólares al mes.
La parte incómoda para un comprador es que no se puede saber desde la interfaz. Un "wrapper" y un motor diseñado específicamente tienen un aspecto idéntico: un cuadro de texto, una respuesta en streaming, algunas citas debajo. La diferencia está "upstream", donde nadie puede verla, que es exactamente la razón por la que tan pocos proveedores son presionados al respecto.
Donde realmente reside el razonamiento
Cuando una pregunta llega a HAQQ, no va primero a un modelo general. Pasa por un paso que poseemos y controlamos, cuyo único trabajo es averiguar cuál es realmente la solicitud y configurar todo lo que sucede a continuación.
Ese paso resuelve las cosas que un asociado competente establecería antes de comenzar el trabajo, y las resuelve como datos estructurados en lugar de como prosa:
- Lo que realmente se pregunta. No las palabras escritas a las 11 p.m. entre dos llamadas, sino la pregunta subyacente, reformulada de manera precisa y completa. Esto se ejecuta de forma nativa en árabe y francés, así como en inglés, en lugar de como una traducción añadida posteriormente.
- Qué tipo de trabajo legal es este. Redacción, investigación, revisión, comparación, una pregunta de procedimiento. Cada uno requiere una forma diferente de respuesta, y decidir eso de antemano es muy distinto de esperar que un modelo general lo infiera.
- Qué jurisdicción está en juego, y por separado, en qué idioma está escrita la ley aplicable. Esos dos no suelen ser lo mismo, y tratarlos como uno solo es una fuente de error silenciosa y común.
- Los hechos, como objetos. Partes, fechas, obligaciones, montos, ley aplicable, tipo de documento, extraídos de la prosa y convertidos en datos estructurados antes de que algo costoso los lea.
- Lo que la pregunta necesita y lo que no. Qué capacidades especializadas se deben aplicar, cuánta profundidad de razonamiento justifica realmente la pregunta y si entra dentro del alcance en absoluto.
Solo entonces se ejecuta el modelo de propósito general. Y llega ya preparado: con las capacidades relevantes cargadas, los hechos extraídos, la jurisdicción identificada y el alcance decidido.
El modelo es el último paso de la cadena, no el primero.
Por qué esto produce una respuesta mejor, no solo más barata
Dos mecanismos, y el segundo nos sorprendió más que el primero.
La atención es un presupuesto
La ventana de contexto de un modelo es finita, y todo lo que se pone en ella compite por la atención del modelo. Cargar cada capacidad que un sistema tiene en cada solicitud consume una parte importante de esa ventana antes de que el documento real del abogado sea examinado. Traer solo las relevantes deja espacio para lo que importa: el contrato, el estatuto, los hechos.
El análisis no es razonamiento
Este es el efecto más grande. Cuando un modelo recibe un párrafo de prosa, una parte significativa de su trabajo consiste en descifrar lo que contiene el párrafo. Cuando recibe hechos estructurados, estas partes, esta ley aplicable, esta obligación, esta fecha, ese trabajo ya está hecho, y todo el presupuesto se destina a la cuestión legal.
La consecuencia práctica es que el mismo modelo de propósito general produce un trabajo legal notablemente mejor dentro de un sistema como este que dentro de un envoltorio. El modelo no cambió. Lo que le entregamos sí.
Las partes que nadie pone en una demo
Dos cosas que nunca llegan a una presentación de ventas, y ambas deciden si el producto funciona en un martes real.
Ingesta de documentos. Una gran parte del trabajo legal no llega como texto limpio. Llega como una fotografía de un documento sellado, un escaneo de un fax, un PDF que alguien imprimió y volvió a escanear torcido. Tratamos la lectura de esos documentos como un problema de ingeniería de primera clase en lugar de una ocurrencia tardía de preprocesamiento, porque si un número de cláusula se lee mal al principio, ninguna cantidad de razonamiento posterior lo recuperará. El sistema razonará impecablemente sobre el número equivocado.
La memoria como estructura, no como transcripción. El motor mantiene las relaciones entre sus asuntos a lo largo del tiempo y las utiliza cuando una pregunta lo requiere. Eso es diferente de pegar sus últimos veinte mensajes de vuelta en el prompt. Es lo que permite que el sistema sepa que la contraparte en el NDA que está revisando hoy es la misma que en una disputa de hace dos meses.
Lo que esta arquitectura no soluciona
Preferimos decir esto a que lo descubras tú.
No elimina el error. Cualquier sistema basado en un modelo de lenguaje puede producir una respuesta incorrecta, y un proveedor que te diga lo contrario o no está siendo cuidadoso con las palabras o espera que no lo compruebes. Lo que hace una buena arquitectura es hacer que los errores sean más raros y detectables: afirmaciones generadas contra fuentes recuperadas, citas que puedes abrir y banderas explícitas donde la ley es genuinamente ambigua en lugar de una resolución segura de algo no resuelto.
No reemplaza al abogado. Todo aquí está diseñado bajo la premisa de que un profesional revisa el resultado y lo firma. Eso no es una limitación por la que nos estemos disculpando. Es la restricción de diseño, y es la razón por la que la arquitectura se ve de la manera en que lo hace.
No hace que la cobertura sea universal. La calidad de Legal AI varía según la jurisdicción, según lo bien digitalizada esté la fuente legal y según la cantidad de información pública disponible. A cualquiera que te cite una única cifra de cobertura global se le debería preguntar qué cuenta. A nosotros nos lo preguntan con frecuencia, y preferimos responderlo sobre tu jurisdicción que agitar un número delante de ti.
Cómo probar a cualquier proveedor para esto en una demostración
No necesitas ver el diagrama de arquitectura de nadie. Cuatro preguntas, unos diez minutos, y funcionan para cualquier proveedor en la categoría, incluyéndonos a nosotros.
1. Pregúntale algo fuera del ámbito legal
Un modelo general envuelto en una instrucción legal generalmente responderá a una pregunta médica o financiera, porque en el fondo, es un modelo general. Un sistema que establece la intención antes de generar debería negarse y decir por qué.
2. Haz la misma pregunta en dos idiomas
No una versión traducida. La misma pregunta legal, una vez en inglés y otra en árabe o francés. Si la esencia de la respuesta cambia, el idioma se está manejando después del razonamiento en lugar de antes de él.
3. Haz un escaneo de mala calidad
Fotografía un documento en ángulo, con poca luz, y súbelo. Esta es la prueba más predictiva en toda la demostración, porque es la entrada real más común y la menos demostrada.
4. Pregunta lo que no sabe
Dirígete hacia un área del derecho ambigua, inestable o con fuentes escasas. Un sistema optimizado para producir siempre una respuesta la producirá. Un sistema creado para el trabajo profesional te dirá que el terreno es incierto y te mostrará por qué.
Si un proveedor se siente cómodo con los cuatro puntos, la arquitectura probablemente sea real. Si la demostración los evita, eso también es información.
Conclusiones clave
- La diferencia significativa entre los productos de Legal AI es arquitectónica e invisible desde la interfaz. Pregunta dónde ocurre el razonamiento.
- Realizar un trabajo estructurado antes de la llamada al modelo mejora la calidad de la salida, no solo el costo. Un modelo al que se le entregan hechos extraídos gasta su presupuesto en derecho en lugar de en análisis.
- Los componentes menos atractivos deciden el rendimiento en el mundo real. La calidad de la entrada del documento es más predictiva de si una herramienta funciona un martes que cualquier puntuación de referencia.
- Cuatro preguntas de demostración, fuera de tema, dos idiomas, un escaneo de mala calidad y un área de derecho inestable, te dirán qué tipo de sistema te están vendiendo.
- El motor Justinian y su razonamiento
- 45 señales de advertencia al evaluar un proveedor de Legal AI
- Legal AI con intervención humana
- Ingeniería de contexto para Legal AI
Prueba HAQQ AI gratis
Experimenta la redacción e investigación legal con IA
