Siempre que aparece una nueva tecnología, se la envuelve en hipérboles. Mi Twitter está lleno de "influencers" que afirman haber creado un sitio web completo con un solo mensaje, pero cualquiera que esté tratando de crear sitios web sabe que actualmente son lo suficientemente buenos como para implementar pequeñas funciones y lanzarse a cualquier tarea de largo alcance con un repositorio de código completo como contexto.
¿Recuerdan cuando nos prometieron que mañana habría coches autónomos hace unos diez años? La conducción autónoma es un problema resuelto, dijo Elon Musk, el máximo exponente de la publicidad, hace ocho años .
Mientras esperábamos que los Tesla comenzaran a hacer donuts por su cuenta, ya estaban en marcha iniciativas menos glamorosas. Mobileye construyó un sensor que emite un pitido cuando estás a punto de chocar contra algo. Salvaron innumerables vidas y redujeron las reclamaciones de seguros en un 90 %. Crearon una empresa de 17 mil millones de dólares.
Creo que la comprensión de documentos es la tecnología de Mobileye para los estudiantes de maestría en derecho. Comprender tablas financieras, tabular reclamaciones de seguros e inferir códigos médicos a partir de las notas de un médico parece algo modesto en comparación con los sueños más ambiciosos. Pero si hace doble clic en este problema, descubrirá que anteriormente no se había resuelto y que desbloquea mucho valor.
Hace una década trabajé para el ilustre equipo de estandarización de datos de LinkedIn. Tratábamos de resolver un problema engañosamente simple: ¿cómo interpretar un currículum, sin importar de dónde provenga, y relacionar sus títulos con un pequeño conjunto de títulos reconocidos?
Uno pensaría que esto sería fácil. Quiero decir, "ingeniero de software" es un título bastante sencillo, ¿verdad? Pero, ¿qué pasa si alguien escribe "asociado"? Podrían estar reponiendo estanterías o ganando un salario de seis cifras en un bufete de abogados. ¿Qué es un ayudante de estación (vaquero australiano), qué es un consultor (podría significar asesor/freelance, pero podría significar médico si eres británico y tienes la formación adecuada para ello)? Si estás tratando de encajar los títulos de trabajo en una lista de elementos reconocidos para poder indexarlos para búsquedas, ventas, etc., ¿cómo construirías un modelo que conozca los matices de todos los idiomas y culturas, y no confunda "asistente ejecutivo" con un ejecutivo, mientras que el asistente del gerente regional es en realidad un adjunto del gerente regional?
Vale, esto está bien, pero si trabajo para LinkedIn , necesitaré tipos de datos concretos. Quiero un JSON .
Se necesita más trabajo para mapear los títulos de trabajo en una taxonomía estándar, una lista finita de títulos de trabajo predefinidos aceptables. Pero se puede ver cómo algo que era muy difícil en el pasado se vuelve trivial.
Leer currículums es un buen ejemplo de uso, pero creo que no es revolucionario. LinkedIn es una empresa tecnológica y siempre ha aplicado algunas de las navajas más afiladas al problema. Puede mejorar un poco, pero solo estamos reemplazando un proceso de automatización de código por otro.
Las cosas se ponen mucho más interesantes cuando se reemplaza el tedioso trabajo manual. Una gran parte de la economía se basa en personas que realizan tareas especializadas que se reducen a “leer un documento, descifrar lo que dice y repetir ese proceso hasta la saciedad”.
Déjame darte algunos ejemplos:
Gestión de gastos: Tienes una factura y alguien tiene que convertirla en una lista de números: qué se pagó, a quién y en qué moneda. ¿Suena fácil? No cuando está sepultada en un lío de información adicional, tablas incompletas o archivos PDF que parecen haber sido pasados por una licuadora.
Procesamiento de reclamaciones de atención médica: esta es una pesadilla que resuelve un ejército de árbitros de reclamaciones de atención médica. Examinan montañas de facturas, notas de médicos y facturas que deben unirse en un lío con duplicados y deben compararlas con una póliza de seguro de salud existente y determinar si el cargo está cubierto, bajo qué categoría y por qué monto. Pero, en última instancia, se trata principalmente de leer, clasificar y etiquetar. Las decisiones no son difíciles; es la extracción de datos lo que constituye el desafío.
Evaluación de préstamos: revisión de los estados de cuenta bancarios de una persona y clasificación de su flujo de efectivo. Una vez más, se trata más de estructurar información no estructurada que de ciencia espacial.
¿Glamour? No. ¿Útil? Creo que sí.
A estas alturas, los LLM son conocidos por sus alucinaciones, es decir, por inventar cosas. Pero la realidad tiene más matices: las alucinaciones son esperables cuando se solicita conocimiento del mundo, pero básicamente se eliminan en una tarea con fundamento .
Los LLM no son particularmente buenos para evaluar lo que "saben"; es más bien una consecuencia afortunada que puedan hacer esto, ya que no fueron entrenados explícitamente para eso. Su entrenamiento principal es predecir y completar secuencias de texto. Sin embargo, cuando a un LLM se le asigna una tarea fundamentada (una en la que solo se requiere la entrada explícitamente dada para hacer una predicción), las tasas de alucinaciones pueden reducirse prácticamente a cero. Por ejemplo, si pegas esta publicación de blog en ChatGPT y preguntas si explica cómo cuidar a tu hurón mascota, el modelo dará la respuesta correcta el 100% de las veces. La tarea se vuelve predecible. Los LLM son expertos en procesar un fragmento de texto y predecir cómo un analista competente llenaría los espacios en blanco, uno de los cuales podría ser {“se discutió el cuidado del hurón”: falso}.
Como ex consultor de inteligencia artificial, trabajamos en proyectos centrados en la extracción de información de documentos, en particular en sectores como los seguros y las finanzas. El miedo común era que "los LLM alucinan", pero en la práctica, los mayores desafíos se debían a menudo a errores en la extracción de tablas u otras inconsistencias de entrada. Los LLM solo fallan cuando no logramos presentarles una entrada clara e inequívoca. Hay dos componentes clave para automatizar con éxito el procesamiento de documentos:
Extracción de texto perfecta : implica convertir el documento en texto limpio y legible por máquina, lo que incluye el manejo de tablas, notas escritas a mano o diseños variados. El LLM necesita un texto claro y comprensible con el que trabajar.
Esquemas robustos : estos esquemas deben definir qué resultados está buscando, cómo manejar los casos extremos y el formato de los datos, garantizando que el sistema sepa exactamente qué extraer de cada tipo de documento.
La brecha entre los riesgos potenciales de alucinación y los obstáculos técnicos reales puede ser enorme, pero con estos fundamentos en su lugar, puede aprovechar los LLM de manera efectiva en los flujos de trabajo de procesamiento de documentos.
Esto es lo que provoca que los LLM se bloqueen y se quemen, y obtengan resultados ridículamente malos:
Siempre es útil recordar el caos que se genera en los documentos del mundo real. A continuación, se muestra un formulario de impuestos al azar:
Por supuesto, los formularios de impuestos reales tienen todos estos campos completados, a menudo a mano.
O aquí está mi currículum
O un informe de laboratorio de ejemplo disponible públicamente (este es un resultado de primera página de Google)
Lo peor que se puede hacer, por cierto, es pedirle a las capacidades multimodales de GPT que transcriban una tabla. Pruébelo si se atreve: parece correcto a primera vista, inventa cosas absolutamente al azar para algunas celdas de la tabla, saca cosas completamente de contexto, etc.
Cuando nos pidieron que entendiéramos este tipo de documentos, mi cofundador Nitai Dean y yo nos quedamos perplejos al descubrir que no existían soluciones estándar para darle sentido a esos textos.
Algunas personas afirman que pueden resolverlo, como AWS Textract, pero cometen numerosos errores en todos los documentos complejos que hemos probado. Luego está la larga lista de pequeñas cosas necesarias, como reconocer marcas de verificación, botones de opción, texto tachado, garabatos escritos a mano en un formulario, etc.
Por eso, creamos Docupanda.io , que primero genera una representación de texto clara de cualquier página que le envíes. A la izquierda verás el documento original y, a la derecha, el texto de salida.
Las tablas se manejan de manera similar. En esencia, simplemente convertimos las tablas a un formato Markdown legible para humanos y LLM:
El último paso para dar sentido a los datos con LLM es generar y cumplir con formatos de salida rígidos. Es genial que podamos hacer que la IA moldee su salida en un JSON, pero para aplicar reglas, razonamientos, consultas, etc. a los datos, debemos hacer que se comporten de manera regular. Los datos deben ajustarse a un conjunto predefinido de espacios que rellenaremos con contenido. En el mundo de los datos, a eso lo llamamos Schema .
La razón por la que necesitamos un esquema es que los datos son inútiles sin regularidad. Si estamos procesando registros de pacientes y se asignan a “varón”, “varón”, “m” y “M”, estamos haciendo un trabajo terrible.
¿Cómo se crea un esquema? En un libro de texto, se puede crear un esquema sentándose largo y tendido, mirando fijamente a la pared, y definiendo lo que se quiere extraer. Se sienta allí, reflexiona sobre la operación de datos de atención médica y dice: "Quiero extraer el nombre del paciente, la fecha, el género y el nombre de su médico. Ah, y el género debe ser M/F/Otro".
En la vida real, para definir qué extraer de los documentos, te quedas mirando los documentos… mucho. Empiezas con algo como lo anterior, pero luego miras los documentos y ves que uno de ellos tiene una LISTA de médicos en lugar de uno. Y algunos de ellos también incluyen una dirección de los médicos. Algunas direcciones tienen un número de unidad y un número de edificio, por lo que tal vez necesites un espacio para eso. Y así sucesivamente.
Lo que nos dimos cuenta es que poder definir exactamente todas las cosas que queremos extraer es algo no trivial, difícil y muy solucionable con IA.
Ese es un elemento clave de DocuPanda. En lugar de simplemente pedirle a un LLM que improvise un resultado para cada documento, hemos creado el mecanismo que le permite:
Lo que obtienes es un poderoso esquema JSON: una plantilla que dice exactamente lo que quieres extraer de cada documento y se mapea sobre cientos de miles de ellos, extrayendo respuestas a todos ellos, mientras obedeces reglas como extraer siempre las fechas en el mismo formato, respetar un conjunto de categorías predefinidas, etc.
Como en cualquier madriguera de conejo, siempre hay más cosas de las que se ven a simple vista. Con el paso del tiempo, descubrimos que se necesitan más cosas:
A menudo, las organizaciones tienen que lidiar con un flujo entrante de documentos anónimos, por lo que los clasificamos automáticamente y decidimos qué esquema aplicarles.
Los documentos a veces son una concatenación de muchos documentos, y se necesita una solución inteligente para dividir un documento muy largo en sus componentes atómicos y separados.
Consultar los documentos correctos utilizando los resultados generados es muy útil
Si hay una conclusión que sacar de este artículo, es que deberías considerar la posibilidad de aprovechar los LLM para entender los documentos de forma habitual. Si hay dos conclusiones, es que también deberías probar Docupanda.io . La razón por la que lo estoy creando es porque creo en él. ¿Quizás esa sea una razón suficiente para intentarlo?