Ад наіўнага да прадакшн-RAG на справаздачах SEC 10-K: разбіўка і гібрыдны пошук
Чаму падручнікавы RAG не справіўся з 300-старонкавымі 10-K і што дапамагло: фрагменты з улікам раздзелаў, гібрыдны пошук, пераранжаванне крос-энкодэрам, валідацыя і цытаты з метаданых.
Крыніцы: **How I Built a RAG Pipeline on Legal & Financial Documents and What Actually Broke?**
Трубопрацэс, які выглядаў правільна, але вярнуў некарэктныя даны
Уявіце сабе трубопрацэс RAG для заполнення дакументаў SEC 10-K, створэння якога зайняло тры тыдзены: ён складаўся з компонентаў LangChain, базы дадзенаў ChromaDB як сховішча вектараў, простага скрыпта на Python для прыёму дадзенаў і графічнагінтэрфейса Streamlit. Першы просты тэст заключаўся у запітанні, якія крытычныя пункты аўдыту стосуюцца відбівання дохода. Сістэма, абсалютна впэўненае ў сабе, адпавядае пра компенсацію керуючых з абсалютна іншага раздзела дакумента. Слова «галюцынацыя» тут не цэлкам падходзіць — тэкст рэальны, але ён взяты з некорэктнага роздзела 300-сторонньага дакумента, пры чым сістэма нічога не запазнала.
Тое, калі сістэма выглядае як RAG, і тое, калі яна функцыонуе як такая, — гэта разныя рэчы. Ёсць рашынкі падзелкі на часткі, неудачы пад час выкарыстоўвання даных, эксперыменты з утворэннем эмбедынгаў, набор даных для ацэнкі, створаны з прычыны неабходнасці, а таксама версія, якая ў канцы канцоў зменіла час ручнай пераглядкі на 65%. Кожны, хто стварае функцыі на базе LLM для рэальных дакументаў, а не простых PDF-файлаў, можа заўсёды заўсці без тыдняў непродуктыўнага навучэння.
Чаму дакументы 10-K такія складныя для выкарыстоўвання
Разгляд дакумента 10-K як звычнага PDF-файла — гэта недаоцэнка яго. Дакумент большога чым сярэдніх розмераў публічнай кампаніі мае дыяпазон ад 150 да 400 сторанак, у якіх ёсць фінансавыя табліцы, прыметкі, якія цітуюць іншыя прыметкі, юрыдычныі тэксты, якія займаюць дзесяткі сторанак, а таксама опісы рызыкаў і коментары керування. Мэтай выкарыстоўвання даных былі крытычныя пытанні аўдыту (Critical Audit Matters, CAM), дзе аўдытары пояснююць найболей складныя чыста на аднойце з думкай аспекты свайго работы.
Тое, што чытач хочаць знайсці, такі як тэрміны, звязаныя з рызыкамі, і аўдытавыя выводы, распадзецца неравнамерна. Яны скупленыя ў певных частках дакумента, напісаных спецыялістычным слоўнікам, і асоўваныя з цыфрамі, якія не маюць значэння па самае сабе. Дакумент трэба спрыяглядаць як сумку з фрагментамі, і алгорытмы пошуку большасцю часу выбіраюць неправільныя фрагменты, што самэ гэта і адбылася ў першай версіі.
Два прадзея нявіддальна адна ад другой
Разлік межаў версіяў містыць усі урокі.
Версія 1 была стандартным падходам: запрацоўваць PDF, разбіць яго на фрагменты по 500 токенав з перакрыццем у 50 токенав, укладзіць іх за дапамогою мадэлі OpenAI’s text-embedding-ada-002, зберагчыць у ChromaDB, выбраць 5 найболей прыдатных фрагментаў для запіту, перадаць іх GPT-4 і стварыць статыс. Гэты падход працаваў для простых запытанняў да чыстых дакументаў, але не справіўся з 300-стороннім дакументам трыма конкрэтнымі спосабамі.
Версія 2 мае ўжо больш за лічбу этапаў: прыём PDF-файлаў, слой для выявлення раздэлаў, разбіўка на часткі з урахоўванням тыпу раздэла і зменнымі размерамі, атрыбуты метадаў для кожнай часткі, мадэль усадкі, якая врачоўвае домэн, храненне ў ChromaDB з дакладнымі метадаў, перапісва запытоў, гібрыдны спосаб выкарыстоўвання інформацыі (семантычны плюс ключавыя словы), пераранжаванне, перакананне ў правільнасці і, нарэшце, генераванне. Кожны з этапаў існуе з паводу, пра які будзе сказана далей.
Першая проблема: фіксаваныя часткі роздзеляюць кантэкст
Найбольш базовая адмова V1 была выправлена за дапамогою частак по 500 токенаў, якія роздзеляліся там, дзе трапляўся гэты лік. Документ 10-K мае прыродную структуру. Документ CAM складаецца з заголовка, апісання, адпаведзі цэрніка і часта з пасылання на фінансавую анотацію, пры чым гэты документ можа вырашаць 600 або 800 токенаў. Разбіўка на 500 токенаў часта роздзеляла документ CAM на две часткі: апісання залішалася ў адной часткі, а адпаведзь — у іншай, таму жадна з частак сама па сабе не мела значэння.
Рашэннем быў шар для выявлення секцый прытаму практыкі разбівання на часткі. pdfplumber аналізав структуру дакумента, каб знайсці межы секцый, заголовкі, падзаголовкі і края табліц, і тады разбіванне водзілася ў межах секцый, а не між ямі, з выкарыстоўваннем размероў, якія лягалі ў лад з прыроднымі перэрывамі. У разе ўжоўсткіх фінансавых табліц ствараліся маленькія часткі па 200–300 токенав, каб можна было шукаты дэталі на рэвэлі. Наратыўныя секцыі, такія як CAM-ы і анунцыяў пра рызыкі, атрымалі большыя часткі — аж 800–900 токенав, каб кожная логічная ейкапа застала цэлой. Надпакрыцце частак становіла 10% ад ўжоўвышэння часткі. Што самае важна, гэтае адно змены значна паспрабавалі павысіць рэлевантнасць выкарыстоўвання інфармацыі, прычым не змінюючы нічога іншага.
Няудача два: эмбеддынгі, якія не врачалі фінансавую мову
text-embedding-ada-002 — гэта моцны мадэль для шырокага выкарыстоўвання, хоць яна не была натрэнавана спецыяльна на фінансавым чы правовым тэкстах, і гэта паследзіць у ўжоўтканых дакументах аўдыту. Запыт пра сферы вынікнення рашэнняў па відналежнасці дохоў прынёс фрагменты пра доходы і пра рашэнні ў загальнам сэнсе. Частка з іх была взята з обсужэнняў керування, частка — з прымечанняў, а ўсьмохнае — з несувязаных адкрасаў пра рызыкі, прычым сама інформацыя па відналежнасці дохоў не была знайдзена надзеямо.
Быў перапробаваны два варыянты. Новейшы модуль OpenAI — text-embedding-3-large — значна паспрабаваў паўышыць якасць аднаходжэння інфармацыі. Гібрыдны падход, які спалохваў ўжоцьпланаваны пошук вектараў з рэдкім пошукам ключоўых слоў BM25 і з’едыніў рэзультаты, парадзіўся кожным з аддзельных методаў. Прычына простая: ужоцьпланаваны пошук аднаходзіць контэнт, концэптуальна супарадны, тады калі рэдкі пошук аднаходзіць точную тэрміналогію. У фінансовым тэксце точнае формулюванне мае вельмі важлівое значэнне. Фраза «Крытычны момент аўдыту» не ўзначае тое ж, што «Значны прынт аўдыту» у юрыдычным жаргоне, і наявнасць обох показывае значна вышэю тачнасць. Для рэдкага пошуку была выкарыстоўвана бібліятэка Python rank_bm25, а простая функцыя злучэння рангаў перамешвала два спіску рэзультатаў прычым пераранжавала іх занова.
Трэція прычына неудачы: абсэнцыя паўтарной перапрацоўкі, самавярэнныя неправільныя адпаведзі
Эта была найболей тыхая і найболей апасная проблема. У V1 некалькаторыя некарэктныя фрагменты, якія былі выкарыстоўваны, яшчэ змусвалі LLM даваць адпаведныя адпаведзі, а GPT-4 дужа добра ведае, як выглядаць впэўнена ў сабе нават праз скромны кантэкст. Яго адпаведзі не былі явна некорэктнымі. Гэта былі правдападобныя падсумкі тых фрагментаў, якія прыходзілі, нават калі тые фрагменты былі взяты з некалькаторыя часткі дакумента.
Лячынку проблемы можна было выявіць толькі за дапамой маленькага набора для ацэнкі: 30 пар пытання-адпаведзі, якія былі ручна перакананыя ў адпаведнасці з конкрэтнымі дакументамі, кожная з яых была пазначаная точнымі фрагментамі ісходнага тэксту, якія мялі б вернуцца. Па гэтым крытэрыю V1 выкарыстоўваў правыя фрагменты ісходнаг тэксту прыблізна у 55% случаў, а ў іншыя 45% ствараў плавны тэкст на аднойчыннай базе.
Два змяны выправілі проблему. Першая — гэта етап пераранжавання: крос-кодэр HuggingFace пад назвай ms-marco-MiniLM-L-6-v2 перэрахунав оцэнкі дзесяці знайдзеных фрагментаў, і толькі тры найлепшыя перайшлі да генератора. Крос-кодэры працуюць спамерна, чым бі-кодэры, але ранжуюць значна точней, таму што запіт і кандыдатскі фрагмент чытаюцца як адна вхідная інфармацыя, а не як две окольныя.
Другая змяна — гэта пераканальнік перад генераваннем. Ён пераканаліваўся, чы ранее знайдзеныя фрагменты маюць ідэнтыфікаторы раздэлаў, якія апэктываюцца з метададзей часу запрашэння. Напрыклад, калі запыт пра CAM-ы вярнуў фрагменты з табелей компенсацыі, пераканальнік не працаваў, і сістэма перапісвала запыт і прабавала знову да двух разоў, перш чым пазначыла адпаведзь як ненадзеючую. Гэта адзначае разлік між дэманстрацыйным варыянтом і працоўным сістэмам: дэманстрацыйны варыянт пакрывае успешны шлях, тады як працоўная сістэма справляецца з 45% случаў, калі гэты шлях не працуе.
Метаданыя кожнага фрагмента
Адзін з дыякрэтных рашэнняў у дыялогах па RAG рэдка практыкуецца: наяўнасць абшырных метаданых, прыўязаных да кожнага фрагмента. Кожны фрагмент у калекцыі ChromaDB мелі следуючыя поля:
section_type— частка дакумента 10-K, з якой ён быў взяты, напрыклад CAM, апавешчэнне пра рызыкі, фінансавыя выкладкі, прымечанні або аналіз кампаніяйsection_title— точны загалоўны тэкст над кантэнтамpage_range— номеры сторонак аднаго дакумента, якія павінны быць адрабоўваны фрагментамdocument_id— ідэнтыфікатор дакумента, у віглядзе тыкера компаніі плюс фінансавага годаhas_table— булевы значэнне, якое паказвае на наяўнасць таблічных дадзеныхfiscal_year— перыяд звярнення справаздачы
Метаданы выконвалі два заведаменні. Яны дазволілі фільтраванне рэзультатаў пошуку: для запытання, касаючагася аўдытных пытанняў, пошук могаў празвышна фільтраваць рэзультаты на тып раздзела critical_audit_matter пры выкарыстоўванні вектарнага пошуку, чым значна скармаліліся можлівасці пошуку. Яны таксама сталі аднойчынай для слоя цітатаў у інтэрфейсе, адколі кожны падсумак апісваў сторункі і раздзелы, з якіх ён быў складзены, і аўдытары маглі негайна пераканацца ў адпаведнасці да вачынных дакументаў.
У інструментах фінансовага аўдыту цітаты ўскладненыя. Аўдытар, які не можа парабіцца ў паходжэнні падсумку, не можа на яго паложыцца, а стварэнне цітатаў на аднойчыні з метаданамі ператворыла сістэму з простага інструменту для дапамогі ў доследжэннях у ўсёраспраўданы інструмент, якім можна было бы рэальна карыстацца.
Завершаная сістэма
Полны ланцоўка, якая скармаліла працу пад час аўдытнага аналізу на 65%, складаецца з трохоў слоёў.
- Працэваўванне дадзеных: pdfplumber, выявленне секцый, розбіўка на часткі, выкарыстоўванне метададзей, уключэнне за дапамогою text-embedding-3-large, пасля чаго зберагачча ChromaDB з усіма метададзеямі.
- Запыт: перапісва запыту (пераформулюванне за дапамогою LLM для большай спецыфічнасці), фільтраўанне рэзультатаў за дапамогою прадзіўфільтра метададзей па тыпу секцыі, калі гэта прыемліва, гібрыдны метод адшукання dense плюс BM25 для выявлення 10 найболей значных рэзультатаў, пераранжаванне за дапамогою cross-encoder да 3 найболей значных рэзультатаў, пераканальны чыннік, генераванне тэксту за дапамогою GPT-4, прыўязка цітатаў і адображэнне на інтэрфейсе.
- Ацэнка: набор дадзеных з 30 элементамі, назіранне за точнасцю адшукання і оцэнка якосці адпаведзей, выкарыстоўванне LLM як судды для ацэнкі рэлевантнасці, аддаклёванасці і полноты.
Фронтэнд Streamlit адкрываў аўдытарам возможнасць вводу запыту, генераванага апісу, цітатаў з адпаведных джэрэл, якія адкрываліся за пажаданнем, а таксама показчыка доверлівасці, які вылучаліся з крока пераканальнага чынніка.
Што трэба зрабіць інакшэ
- Спачатку створыце набор дадзеных для ацэнкі. Ён быў склеўваны з вынуждання пасля неудачы V1, і яго трэба было створыць з самага пачатку. Нічога не павышаецца без меры, а фраза «здаецца лепшым» не ўважаецца паметрыкам.
- З самага пачатку спроектуйце схему метададзеных. Ій знадобілася час, каб стаць правільной, пры тым кожная гадзіна давала кількакратную аддачу ў якасці выкарыстоўвання дадзеных і ў функцыях інтэрфейса, якія яна дазволяла рэалізаваць. Метададзеныя заслуговуюць на першасортны статус у архітэктурэ.
- Працаваць з гэтым, што парсер PDF можа чагось не знайсці. pdfplumber ўжо чырвоны, пры тым злучаныя клеткі, роўнаверхнія заголовкі аб пазначкі прымечакаў унутро клетак у фінансовых табліцах все ўсё можа ўскладніць йому працу. Запісвайце кожную анамалію падчас выкарыстоўвання і рэгулярна пераглядвайце гэты журнал, адтолькі тых, што праходзяць непазірна, найважча ўпарацаваць пазней.
- Сумневайцеся ў кожнай стандартной настройцы. Стандартны размер фрагмента, стандартная мадэль інкапсуляцыі і стандартны параметр top-k існуюць таму, што ў сярэдняму воні працуюць прыемна, але тып дакумента можа не быць сярэднім. Перапытайце кожную з іх на рэальных даных.
Рэзультат
Пасля запуску сістэма выкарыстоўвала даны для выдлічэння і структураванага падсумавання важлівых аспектаў аўдыту, заўсёды заўсім з меншым часам ручнай пераглядкі — на 65% менш, чым у практыцы, яку яна заменіла. Выпрацоўваючы функцію першага етапу перагляду, яна выявляла стосунныя часткі дакументаў і стварала структураваныя падсумкі, таму аўдытары моглі перайсці ад выдлічэння і сінтэзы да пераканання і ацэнкі.
Гэты последній момент ёсць найважлівейшым. Мета ніколі не была заменіць суджэнне аўдытара, а выдаліць механічныя, трыцяжлівыя крокі, каб экспертна думка могла прабіцца там, дзе яна неабходна. Якісная сістэма на адной нейронной сетцы не заменяе экспертызу — яна яе перакіруе.
Спаднія матэрыялы
- AegisOps: Аўтаномны агент SRE з чатырма слоямі памяці — Як агент LangGraph ReAct рашае інцыдэнты ў Kubernetes, з епізодычной памяцюю pgvector, рэжымамі аўтаномнай дзеяльнасі, кантролюемымі правіламі, шаснаццаццю інструментамі і повным следам аўдыту.
- Порэванае 16 архітэктураў RAG: Калькі патэрн падходзіць да калькі проблемы — Аналіз шысцюнадцяці патэрнаў RAG у чатырох катэгорыях, ад стандартнага і гібрыднага спосабу пошуку да агентных, графічных і федэраваных дызайнаў, з парадам паэтапнага стварэння за месцамі.