Ori de câte ori apare o tehnologie nouă, aceasta se îneacă în hiperbole. Twitter-ul meu este plin de „influenți” care pretind că au construit un site web complet cu o singură solicitare, dar oricine încearcă să creeze site-uri web știe că în prezent sunt destul de buni pentru a implementa funcții mici și a trece de la capătul profund pe orice. sarcină de lungă durată cu un întreg depozit de cod ca context.
Îți amintești când ni s-au promis mașini autonome mâine, acum vreo zece ani? Conducerea autonomă este o problemă rezolvată, a spus Elon Musk, cel mai bun hype meister, acum 8 ani .
În timp ce așteptam ca Teslas să înceapă să facă gogoși pe cont propriu, eforturile mai puțin pline de farmec erau în desfășurare. Mobileye a construit un senzor care emite un bip când sunteți pe cale să dați peste ceva. Au salvat nenumărate vieți și au redus cererile de asigurare cu aproximativ 90%. Au construit o companie de 17 miliarde de dolari.
Cred că înțelegerea documentelor este tehnologia Mobileye pentru LLM. Înțelegerea tabelelor financiare, tabelarea cererilor de asigurare și deducerea codurilor medicale din notele unui medic pare modestă în comparație cu visele înalte. Dar dacă faceți dublu clic pe această problemă, veți constata că a fost nerezolvată anterior și că deblochează multă valoare.
În urmă cu un deceniu, am lucrat pentru renumita echipă de standardizare a datelor a LinkedIn. Încercam să rezolvăm o problemă înșelător de simplă: cum dați sens unui CV, indiferent de unde provine, și să mapați titlurile acestuia la un set mic de titluri recunoscute?
Ai crede că asta ar fi ușor. Adică, „inginer software” este un titlu destul de simplu, nu? Dar dacă cineva scrie „asociat”? Ar putea să-și aprovizioneze rafturile sau să obțină un salariu de șase cifre la o firmă de avocatură. Ce este un Station Hand (Aussie Cowboy), ce este un consultant (ar putea însemna consilier/independent, dar ar putea însemna Doctor dacă ești britanic și ai pregătirea potrivită)? Dacă încercați să încadrați titlurile de post într-o listă de articole recunoscute, astfel încât să puteți indexa pentru căutare, vânzări etc. - cum ați construi un model care să cunoască nuanțele tuturor limbilor și culturilor și să nu greșiți „Asistent executiv” cu să fie director executiv, în timp ce directorul regional adjunct este într-adevăr un adjunct al managerului regional?
OK, deci este frumos, dar dacă lucrez pentru LinkedIn , voi avea nevoie de tipuri de date concrete. Vreau un JSON .
Este nevoie de mai multă muncă pentru a mapa titlurile posturilor într-o taxonomie standard - o listă finită de titluri de posturi acceptabile predefinite. Dar puteți vedea cum ceva care era foarte greu în trecut devine banal.
Citirea CV-urilor este un caz de utilizare plăcut, dar cred că nu revoluționează. LinkedIn este o companie de tehnologie și a aplicat întotdeauna unele dintre cele mai ascuțite aparate de ras problemei. Se poate îmbunătăți oarecum, dar înlocuim doar un proces de automatizare a codului cu altul.
Lucrurile devin mult mai interesante atunci când înlocuiți munca manuală obositoare. O parte uriașă a economiei se bazează pe oameni care efectuează sarcini de experți care se rezumă la „citirea unui document, aflarea ce spune acesta și repetarea acelui proces până la nebunie”.
Permiteți-mi să vă dau câteva exemple:
Gestionarea cheltuielilor: aveți o factură și cineva trebuie să o transforme într-o listă de numere - ce a fost plătit, cui și în ce monedă. Sună ușor? Nu atunci când este îngropat într-o mizerie de informații suplimentare, tabele incomplete sau PDF-uri care par că cineva le-a trecut printr-un blender.
Procesarea cererilor de asistență medicală: Acesta este un coșmar, care este rezolvat de o armată de adjudecatori a cererilor de asistență medicală. Ei cercetează munți de facturi, note clinicienilor și facturi care toate trebuie să se adună într-o mizerie încurcată cu duplicate și trebuie să le potrivească cu o poliță de asigurări de sănătate existentă și să descopere dacă taxa este acoperită, în ce categorie și la ce sumă. Dar când ajungeți la asta, în mare parte este vorba doar de citire, sortare și etichetare. Deciziile nu sunt grele; este extragerea datelor care este provocarea.
Subscriere de împrumut: examinarea extraselor bancare ale cuiva și clasificarea fluxului de numerar al cuiva. Din nou, este mai mult despre structurarea informațiilor nestructurate decât despre știința rachetelor.
Plin de farmec? Nu. Util? Așa cred.
Până acum, LLM-urile sunt renumite pentru halucinații, adică inventarea de rahat. Dar realitatea este mai nuanțată: halucinațiile sunt așteptate atunci când ceri cunoștințe despre lume, dar sunt practic eliminate într-o sarcină bazată pe teme .
LLM-urile nu sunt deosebit de buni în a evalua ceea ce „știu” – este mai mult un produs secundar norocos că pot face acest lucru, deoarece nu au fost instruiți în mod explicit pentru asta. Formarea lor principală este să prezică și să completeze secvențe de text. Cu toate acestea, atunci când unui LLM i se dă o sarcină bazată pe pământ - una în care doar intrarea care i-a fost dată în mod explicit este necesară pentru a face o predicție, ratele halucinațiilor pot fi reduse practic la zero. De exemplu, dacă lipiți această postare de blog în ChatGPT și întrebați dacă vă explică cum să aveți grijă de dihorul dvs. de companie, modelul va da răspunsul corect 100% din timp. Sarcina devine previzibilă. LLM-urile sunt adepți în procesarea unei părți de text și în prezicerea modului în care un analist competent ar completa spațiile libere, dintre care unul ar putea fi {„grijirea dihorului discutat”: fals}.
În calitate de fost consultant AI, am lucrat la proiecte axate pe extragerea de informații din documente, în special în industrii precum asigurările și finanțele. Frica comună era „LLM-urile halucinează”, dar, în practică, cele mai mari provocări s-au datorat adesea erorilor în extragerea tabelelor sau altor inconsecvențe de intrare. automatizarea cu succes a procesării documentelor:
Extragerea perfectă a textului - Aceasta implică conversia documentului în text curat, care poate fi citit de mașină, inclusiv gestionarea tabelelor, note scrise de mână sau machete variate. LLM are nevoie de un text clar și inteligibil pentru a lucra.
Scheme robuste – Aceste scheme ar trebui să definească ce rezultate căutați, cum să gestionați cazurile marginale și formatul datelor, asigurându-vă că sistemul știe exact ce să extragă din fiecare tip de document.
Diferența dintre potențialele riscuri de halucinație și obstacolele tehnice reale poate fi mare, dar cu aceste elemente fundamentale puse în aplicare, puteți folosi LLM-urile în mod eficient în fluxurile de lucru de procesare a documentelor.
Iată ce cauzează blocarea și arderea LLM-urilor și obține rezultate ridicol de proaste:
Întotdeauna ajută să vă amintiți ce mizerie nebună se întâmplă în documentele din lumea reală. Iată un formular fiscal aleatoriu:
Desigur, formularele fiscale reale au toate aceste câmpuri completate, adesea cu scris de mână
Sau iată CV-ul meu
Sau un exemplu de raport de laborator disponibil public (acesta este un rezultat de pe prima pagină de la Google)
Cel mai rău lucru pe care îl puteți face, apropo, este să cereți capabilităților multimodale ale GPT să transcrie un tabel. Încearcă-l dacă îndrăznești — arată corect la prima vedere, realizează absolut chestii aleatorii pentru unele celule din tabel, scoate lucrurile complet din context etc.
Când am fost însărcinați să înțeleagă acest tip de documente, cofondatorul meu Nitai Dean și cu mine am fost derutați că nu existau soluții disponibile pentru a înțelege aceste texte.
Unii oameni pretind că o rezolvă, cum ar fi AWS Text. Dar fac numeroase greșeli în orice document complex pe care l-am testat. Apoi ai coada lungă a lucrurilor mici necesare, cum ar fi recunoașterea semnelor de bifă, butonul radio, textul tăiat, mâzgălile scrise de mână pe un formular etc.
Deci, am construit Docupanda.io — care generează mai întâi o reprezentare text curată a oricărei pagini pe care o aruncați. În partea stângă veți vedea documentul original, iar în dreapta, puteți vedea rezultatul textului.
Mesele sunt tratate în mod similar. Sub capotă, pur și simplu convertim tabelele în format de reducere care poate fi citit de oameni și LLM:
Ultima piesă pentru a înțelege datele cu LLM-urile este generarea și aderarea la formate de ieșire rigide. Este grozav că putem face ca AI să-și modeleze rezultatul într-un JSON, dar pentru a aplica reguli, raționament, interogări etc. asupra datelor - trebuie să o facem să se comporte în mod regulat. Datele trebuie să se conformeze unui set predefinit de sloturi pe care le vom umple cu conținut. În lumea datelor, o numim Schema .
Motivul pentru care avem nevoie de o schemă este că datele sunt inutile fără regularitate. Dacă procesăm înregistrările pacienților, iar aceștia se mapează la „masculin”, „Bărbat”, „m” și „M” – facem o treabă groaznică.
Deci, cum construiești o schemă? Într-un manual, ați putea construi o schemă stând lung și greu și uitându-vă la perete și definind ceea ce doriți să extrageți. Stai acolo, te gândești la operațiunile tale de asistență medicală și spui „Vreau să extrag numele pacientului, data, sexul și numele medicului lor. Ah, și genul trebuie să fie M/F/Altul.”
În viața reală, pentru a defini ce să extragi din documente, te uiți nenorocit la documentele tale... foarte mult. Începi cu ceva ca cel de mai sus, dar apoi te uiți la documente și vezi că unul dintre ele are o LISTA de medici în loc de unul. Și unii dintre ei indică și o adresă pentru medici. Unele adrese au un număr de unitate și un număr de clădire, așa că poate aveți nevoie de un slot pentru asta. Merge și mai departe.
Ceea ce ne-am dat seama este că a putea defini exact care sunt toate lucrurile pe care doriți să le extrageți este atât netrivial, cât și dificil și foarte rezolvabil cu AI.
Aceasta este o piesă cheie a DocuPanda. În loc să cerem unui LLM să improvizeze o ieșire pentru fiecare document, am creat mecanismul care vă permite:
Ceea ce ajungeți este o schemă JSON puternică - un șablon care spune exact ceea ce doriți să extrageți din fiecare document și mapează peste sute de mii dintre ele, extragând răspunsuri la toate, respectând în același timp reguli precum extragerea întotdeauna a datelor în același format, respectând un set de categorii predefinite etc.
Ca în orice gaură de iepure, există întotdeauna mai multe lucruri decât vă vedem prima dată. Odată cu trecerea timpului, am descoperit că sunt necesare mai multe lucruri:
Adesea, organizațiile trebuie să se confrunte cu un flux de documente anonime primite, așa că le clasificăm automat și decidem ce schemă să le aplicăm.
Documentele sunt uneori o concatenare a mai multor documente și aveți nevoie de o soluție inteligentă pentru a despărți documentele foarte lungi în componentele sale atomice, separate.
Interogarea documentelor potrivite folosind rezultatele generate este super utilă
Dacă există o concluzie din această postare, este că ar trebui să vă uitați la valorificarea LLM-urilor pentru a înțelege documentele într-un mod regulat. Dacă există două lucruri la pachet, este că ar trebui să încerci și Docupanda.io . Motivul pentru care o construiesc este că cred în el. Poate că acesta este un motiv suficient de bun pentru a-i încerca?