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

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до 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 майже не обмежений і може докорінно змінити сферу, за умов правильного застосування.