Інтеграція генеративного ШІ у FinTech: труднощі, рішення та результати

Усі статті, обговорення, новини про AI — в одному місці. Підписуйтеся на DOU | AI!

Вітаю! Мене звати Юлія Смойловська, я Delivery Director в Luxoft. Наша команда Data Analytics працює над застосуванням RAG в одному з FinTech-напрямків — страхуванні. В цьому матеріалі я поділюсь історією цього процесу: розповім про наші цілі, складнощі, з якими зіткнулись, та результати, які отримали.

RAG (Retrieval Augmented Generation) — це метод роботи з великими мовними моделями (Large Language Model, LLM), коли користувач пише своє запитання, а ви програмно до цього запитання «підмішуєте» додаткову інформацію з якихось зовнішніх джерел чи баз даних, після чого подаєте все разом як відповідь на запит. Інакше кажучи, ви додаєте в контекст запиту до мовної моделі додаткову інформацію, на основі якої вона може дати користувачеві повнішу і точнішу відповідь.

Назва методу і розкриває суть його роботи:

  • Retrieval — пошук і витяг релевантної інформації. Частину системи, яка відповідає за пошук і витяг інформації називають ретривер (retriever).
  • Retrieval Augmented — доповнення запиту користувача знайденою релевантною інформацією.
  • Retrieval Augmented Generation — генерація відповіді користувачеві з урахуванням додатково знайденої релевантної інформації.

Схема RAG виглядає наступним чином:

Джерело зображення

Інтеграція методу в FinTech

RAG широко застосовується в багатьох сферах, але його інтеграція в FinTech дещо специфічна, як у будь-якому іншому регульованому секторі. Всього можна виділити чотири основні особливості:

  1. Перше, з чим ми найчастіше стикаємося при застосуванні інноваційних технологій, це правила й обмеження, встановлені регулятором сектору. Зазвичай все залежить від конкретного проєкту: в нашому випадку ми не зачіпали сфери, що регулюються, а це значно спростило роботу. Проте, як приклад вимог, з якими можна зіткнутись, спадає на думку GDPR (General Data Protection Regulation). Якщо LLM здійснює пошук з використанням якоїсь персональної інформації, то це одразу підпадає під GDPR, оскільки компанія не може розкривати всі особисті дані будь-якому користувачу моделі.
  2. Друге — виникають питання щодо чіткого налаштування прав доступу до інформації, яка використовується саме як результат роботи ШІ. Наявність великої кількості даних є перевагою для роботи ШІ, проте в FinTech користувачі не можуть мати доступу до всіх даних. Результати видачі ШІ мають бути дуже специфічними, відповідно до рівня доступу, що своєю чергою може обмежувати контекст, в якому працює модель.
  3. Третє — використання сторонньої LLM, яка не контролюється фінансовою установою. FinTech має дуже багато вимог стосовно того, де, як і хто зберігає дані, та як вони обробляються. У разі використання чогось «стороннього» завжди виникають питання з відповідністю вимогам.
  4. Остання особливість — фінансові рішення зазвичай мають значний вплив як на фінансову установу, так і на її клієнтів. Саме тому фінальну модерацію результатів має виконувати людина.

Чому ми обрали RAG

Нашим замовником є страхова компанія, що хоче оптимізувати свою роботу з документами. Страхування — це тип діяльності, який існує дуже давно. Якщо компанія стабільна та успішна, вона працює на ринку десятиліттями й звісно ж у неї будуть дані зафіксовані давно і в довільному вигляді.

У нашому випадку, компанія має дуже багато документів, а саме контрактів з клієнтами. Усі вони зберігаються в PDF-форматі, тобто раніше вони були надруковані й підписані, а вже потім проскановані. База цих документів не структурована: маємо декілька різних змішаних між собою форматів контрактів, які змінювались з часом та мають різне призначення (страхування авто, нерухомості, життя тощо).

Вся ця інформація щоденно використовується спеціалістами зі страхування, які в ручному режимі шукають потрібні файли, перечитують їх у пошуках необхідних даних, на основі яких приймають рішення щодо відшкодування клієнту.

Наше завдання полягало в автоматизації процесу пошуку інформації за заданими критеріями. Така автоматизація мала значно спростити процес обробки документів, зменшити кількість ручної праці та пов’язаних з цим помилок, а також оптимізувати операційні витрати.

Оскільки запити мали бути не з простими питаннями, а з комбінуванням кількох вимог одразу у довільній формі, ми вирішили використовувати RAG, який досить добре підходить під такого роду завдання. ШІ мав аналізувати всю інформацію в PDF-файлах і надавати результат згідно із запитом у формі таблиці.

Робота над проєктом

Початково над розробкою POC (Proof-Of-Concept) працювала невелика команда: два аналітики (спеціалісти зі страхування) формували приклади запитів, описуючи, які функції їм потрібні в роботі, на базі чого наш Data Science-інженер створював продукт.

Потрібний результат ми отримали вже через місяць роботи — розробили конвеєри попередньої обробки даних, опрацювали запити до моделі та форматування відповідей, що дало можливість перейти до «промислової» розробки. Враховуючи те, що наші вхідні дані були не найкращої якості, їхня попередня обробка була особливо важливим етапом.

Вже з листопада минулого року йде вже повноцінна робота. Працюємо ми у двох основних напрямках:

  1. Масштабування нашого POC на ширшу базу даних.
  2. Підвищення точності результатів, що надає ШІ.

Варто приділити увагу і технічному забезпеченню. Для проєкту ми використовували Claude 2 LLM, розроблену Anthropic PBC. Саме цю мовну модель ми обрали виходячи з двох основних параметрів:

  1. Claude 2 має високий ELO-рейтинг (високу точність результатів моделі), на рівні з GPT-4 / Mistral / Bard (Gemini).
  2. Нам потрібна була модель із великою довжиною контексту, а у Claude 2 вона сягає 200 000 маркерів, що перевершило GPT-4 і Mistral. Gemini покращила цю довжину контексту, але це стосується лише GCP. Нам потрібна була модель, яка була б на AWS, оскільки ми з ними співпрацюємо. Це включає такі моделі, як Anthropic (Claude v*N*), Cohere (Command) і Mistral.

Оскільки материнська компанія Luxoft — DXC — є партнером всіх хмарних провайдерів, зазвичай вибір хостів зумовлений або ж технічними вимогами, або ж особистими уподобаннями девелоперів. Цього разу ми обрали AWS, оскільки більшість ШІ-проєктів ми робили на ньому.

Вибір векторної бази даних для POC зупинили на Weaviete, оскільки вона має відкритий код, що спрощувало і прискорювало створення proof-of-concept. Своєю чергою для «промислової» розробки ми змінили базу даних на Pinecone. У нас є пряме партнерство з Pinecone, що дає можливість консультуватись з розробниками бази даних у разі виникнення проблем напряму, що і стало причиною вибору.

До речі, в нашій роботі ми не використовуємо ніяких фреймворків, а працюємо напряму з LLM, для чого ми вручну інтегрували основні компоненти Claude 2 за допомогою C або C++. Ми кодували шари нейронної мережі, механізми уваги та інші компоненти з нуля на основі специфікацій архітектури.

Як результат ми отримали контроль над параметрами моделі, що дозволяє нам більш тонко контролювати її реакцію й те, як ми здійснюємо векторний пошук базою даних.

Складнощі, з якими стикалися

Складнощі під час роботи в нас поки що виникли лише на етапі POC і були повʼязані з трьома основними аспектами:

  • видачею результатів ШІ у структурованому форматі;
  • реалізацією прав доступу на основі ролей;
  • низькою якістю даних.

Однією з основних вимог спеціалістів зі страхування була необхідність надавати дані по запиту в табличній формі. Та, як правило, звичайній LLM важко генерувати бажані результати в табличному форматі, особливо, якщо ви ставите кілька запитань одночасно. Тож потрібно було розв’язувати проблему, що вдалося зробити використавши техніку function-calling. Вона дозволяє LLM видавати результат в XML чи JSON. Ви можете створити запит на генерацію певних параметрів для функції, які потім буде можливо перевести в табличний формат.

Проблема з реалізацією контролю доступу полягала у тому, що у випадку, коли у нас є величезна кількість документів, користувачі, з погляду роботи ШІ, повинні б були мати доступ до всіх файлів для всіх клієнтів для більш повного контексту. Але як, в такому разі, ми можемо гарантувати, що співробітники не отримають відповіді з набору даних, до яких вони не повинні мати доступу?

Тож для розвʼязання питання ми реалізували контроль доступу за допомогою фільтра метаданих, де ми приєднуємо метадані до векторів в індексі. Наявність метаданих у нашому векторі щодо того, хто повинен мати доступ, дозволяє відфільтрувати ці дані, до того ж цей метод не сповільнює пошук. Крім того, ми навчаємо модель видавати в XML результати тільки тоді, коли LLM знайшла інформацію в документах для того, щоб убезпечити її від «галюцинацій» (вигадування даних у разі відсутності, або обмеженого доступу до них).

На кінець, одним з ускладнень стала і лишається низька якість даних, оскільки в більшості файлів наявна зайва інформація, яка заплутує модель: колонтитули, нумерація сторінок, інколи навіть трапляються водяні знаки під текстом файлу. Все це звісно негативно впливає на якість відповідей які надає LLM. Коректність даних на вході в модель є дійсно важливою частиною правильного функціонування ШІ.

Проміжні результати роботи

Підсумовуючи результати реалізації вже зараз, поки ми знаходимось на етапі розробки повноцінної версії моделі, вона вже гарантовано дає відповіді у 50% випадків. Що це означає:

  1. Для спеціаліста зі страхування це зменшення трудових витрат вполовину.
  2. Це вища точність даних, що виключає додаткові ризики помилок через людський фактор.
  3. Для клієнта це вдвічі коротший термін очікування з моменту подачі заявки.
  4. Для компанії таке пришвидшення — це значна перевага на ринку, а також можливість на 50% скоротити витрати на штат співробітників, які раніше працювали над механічним пошуком цієї інформації.

Звичайно, для перевірки наданої ШІ інформації все ще потрібне уважне око людини, та порівняно з тим, що раніше мав зробити спеціаліст для отримання цих даних, ця частина роботи значно менша.

Зараз ми активно працюємо над тим, аби поступово збільшувати обсяг інформації, яку надає LLM, тим самим покращуючи результативність та змінюючи загальний підхід до роботи в компанії замовника.

Висновки

Хоча інтеграція RAG може значно покращити результативність роботи та оптимізувати процеси в компанії, слід обовʼязково звернути додаткову увагу на якість вхідних даних, які плануєте завантажувати у векторну базу даних: якщо система некоректно завантажить їх, то опісля не зможе правильно використати.

Аби запобігти іншим потенційним проблемам при інтеграції RAG в FinTech варто обдумати й реалізувати систему доступів (для запобігання витоку конфіденційних даних користувачів) та набратись терпіння, аби навчити LLM правильно розуміти контекст і не вигадувати зайвого.

Після завершення цього проєкту, з командою плануємо майбутні роботи над ще двома не менш цікавими задачами:

  1. Проєкт інтеграції RAG для обробки аудіофайлів. Ідея полягає у тому, щоб оптимізувати процес заповнення заявки менеджером після дзвінків клієнтів, у разі страхових випадків. Тобто завдання ШІ тут буде у тому, аби розшифрувати запис розмови та на його основі внести потрібні дані в форми.
  2. Проєкт чат-бота для роботи з технічною інформацією щодо FinTech-продуктів. Часто кластери програмного забезпечення в індустрії дуже сильно повʼязані й інтегровані між собою. Зміни в одному продукті вимагають змін в інших пов’язаних. Наприклад, в інвестиційному банкінгу наявна інтеграція з біржами: біржа може оновити свої API, і у випадку, якщо трейдингові платформи не оновлять інтеграцію вчасно — вони не зможуть торгувати на цій біржі, через що потенційно можуть втратити велику кількість фінансів. Тож завдання нашого чат-бота полягатиме у тому, щоб слідкувати за вчасним оновленням інформації, моніторити що відбувається з іншими продуктами тощо.

Попереду багато викликів і можливостей реалізувати новітні проєкти. На мою думку, потенціал використання RAG в FinTech майже не обмежений і може докорінно змінити сферу, за умов правильного застосування.

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
До речі, в нашій роботі ми не використовуємо ніяких фреймворків, а працюємо напряму з LLM, для чого ми вручну інтегрували основні компоненти Claude 2 за допомогою C або C++. Ми кодували шари нейронної мережі, механізми уваги та інші компоненти з нуля на основі специфікацій архітектури.

Що ви там кодували у closed-source LLM з доступом по API?

Питання. Якщо просто помістити всі документи в якусь key value db, щоб спеціаліст міг по ідентифікатору клієнта знайти документи і можливо підключити повнотекстовий пошук по змісту чи це не вирішило вищеозначену проблему?
Яка додана вартість ШІ в цьому випадку?

Оскільки запити мали бути не з простими питаннями, а з комбінуванням кількох вимог одразу у довільній формі, ми вирішили використовувати RAG, який досить добре підходить під такого роду завдання. ШІ мав аналізувати всю інформацію в PDF-файлах і надавати результат згідно із запитом у формі таблиці.

Спробую припустити, що це не звучить як задача для lexical search взагалі. Традиційний lexical analysis/indexing підходи не заточені під ефективний пошук довгих query terms де ще важливий контекст, можливо тут міг би допомогти semantic search(векторний пошук), але це той самий ml. Мовна модель по суті готове рішення з ocr, може не найшвидше але очевидно, що інструмент куди більше підходящий під цю задачу. Але це такий собі умовний ml — по сутіінтеграція зі сторони клієнту і промтинг(робится звичайними девелоперами, data scientists/engineers не потрібні) — це куди швидше ніж підключити ваш kv і налаштувати повнотекстовий пошук.

можливо підключити повнотекстовий пошук по змісту

Одна з проблем, з якими часто зтикався у ERP даних це — нечіткість самого змісту.
Наприклад назва контрагента:
«Сонечко» ТОВ
п-во «Сонечко»
Sonechko, LTD

Це один і той же контрагент, чи ні?

Тобто — питання в різниці синтаксису і семантиці даних.
Можливо й один, а можливо й ні.
Нам тоді треба передевитись операції з цими контрагентами, і на їх схожесті, типовості, визначитись.
Наприклад
Торгові і фінансові операції для «Сонечко» ТОВ, та Sonechko, LTD виявились однаковими (один і той же асортимент товару, приблизно одні й ті ж суми)
а от з п-во «Сонечко» зовсім інші.

Якщо у документах є чітко визначенні дані, то ок, проіндексували по них, та й буде добре.

А якщо нам треба індексувати — по змісту, сенсу документа?
Щоб систему можна було спитати:
Видай договори про кредитам за період (чіткі дані) у регіоні (чітки дані)
видані на основі законів(а ї декілька, від різних установ, але які є підставою) про підтримку(а підтримка може бути не прямою) малих підриємств у сфері виготовлення продуктів харчування(а за законами такими-то — виробники тари теж підпадають)

Ну або на прикладі форума ДОУ
Видай топ 100 коментаторів які пропагандують ухилянство :)

Тобто нам треба проіндесксувати те,
чого у прямому вигляді немає в тексті
а сам термін — не має чіткої ознаки

Звісно, тоді ми отримаємо нечітку відповідь: щось не попаде у виборку, а щось попаде нерелевантне.
Але, нам частенько і не треба точної відповіді, а треба — виявити якийсь тренд, якийсь пік гаусіани, преценденти, для приняття рішення

Сонечки добре рахуються по ,ЄДРПОУ, Інша справа адреси доставки — це повний треш та кошмар для експедиторів.

Я навів спрощений приклад.
А проблема з ідентифікацією так просто не вирішується
аналітичні алгорітми вважають їх різними контрагентами — по їх внутрішнім ID.
фінансови показники починають прикольно брехати, причому вибірково — в одному місці ок, в іншому — маячня якась.

Частіше звісно подібни проблеми з номенклатурою, або з деталями, вузлами на виробництві.

Якось зустрічав софт. кінця 90их, початку 2000их для виявлення таких косопльотів.
Вартість базової ліцензії вражала на той час, пара десятків тисяч доларів. Послуги їх консалтерів — окремий прайс :)

Сергій, ви даєте дуже гарні приклади. З фіз. особами — ще більше проблем, ніж з «Сонечками», бо вони можуть змінювати (часто) документи або використовувати різні документи в різний час, змінювати прізвища (жінки), транслітерацію і т.д. Документи банально можуть погано відскануватись. І звичайно, це спрощений приклад тільки на одному параметрі і ми докускаємо, що шукаємо по контрагенту (а можемо його не знати).
Якщо дивитись на це ще все з перспективи того, що документи накопичувались десятки років назад, то бачимо що змінювались навіть типи ідентифікації, назви/типи/категорії продуктів, формати документів, та інше.
В нашому випадку, ми досить довго працювали зі страховими консультантами, щоб описати їх типи запитів реальних, як вони шукають інформацію.

Якось про результати дуже коротко . Випадково це не про ’чергові велосипеди’? Бо часто — адміністративні проблеми не мають технічного рішення.

Проект знаходиться на етапі впровадження і, нажаль, через NDA ми не можемо розповідати багато деталей. Можливо в подальшому, якщо клієнт вийде з публічним анонсом, ми також зможемо описати результати більш детально

Може як така серйозна NDA то і статтю краще не писати?

У всіх «йде робота» але «проміжні результати» рівно такі щоб спонсор / інвестор не закричав «на що ви про..тратили мої гроші!?»

Підписатись на коментарі