Рішення · Фінансові послуги
У фінансовій організації корисний агент не дає порад і нічого не схвалює: читає документи та транзакції, відносить їх до категорії з фіксованого набору, каже, наскільки впевнений, і має право відповісти «не знаю». Решта — рішення, схвалення, політика — лишається за людьми.
Пропозиція, з умовамиМи не пишемо «поставлено», бо не маємо агента такого типу, розгорнутого в продакшені у клієнта з фінансового сектору. Те, що маємо і показуємо саме так, — це власний конвеєр інжестії, що працює на наших даних: п’ять модулів Python, 1.526 рядків, які читають банківські сповіщення з e-mail та виписки в PDF, класифікують кожну транзакцію через інструменти й записують її в PostgreSQL із дедублікацією, плюс чотири потоки автоматизації для webhookів від трьох платіжних процесорів. Реальний стан, сказаний в тому самому реченні: репозиторій не під git, каталоги `tests/` і `webhook-server/` порожні, а приблизне зіставлення назв контрагентів використовує евристику n-грам, позначену в коді як «замінити на сервіс ембеддингів перед продакшеном». Частина фінансової платформи в продакшені — потік заявки, контракт, графік платежів, аудит — це окрема робота, зі своїми доказами, і там ми пишемо «поставлено».
Запити на AI-агентів у фінансових послугах майже завжди надходять у формі «щоб відповідали клієнтам на запитання про наші продукти». Це законний запит, але час не там виграється. Час губиться в іншому: хтось щодня відкриває десятки банківських повідомлень і виписок, дивиться на опис типу рядка великих літер із кодом і вирішує, чи це надходження від клієнта, зарплата, податок, платіж кредитору чи операційна витрата. Ця робота повторювана, нудна і, саме тому, сповнена помилок.
Мовна модель добре для цього підходить, за однієї умови: від неї не слід вимагати писати відповідь вільним текстом. Якщо ви попросите речення, ви самі його розберете, а розбір помилите. У нашій проводці модель не пише: вона отримує сім інструментів і має викликати рівно один — надходження від клієнта, зарплата, податок, платіж кредитору, операційна витрата, банківська комісія або невідомо. Кожен інструмент, окрім назви контрагента або категорії, вимагає показник упевненості між 0 і 1. «Невідомо» вимагає письмову причину. Вихід — це структура, а не думка.
Друге правило — ніщо не потрапляє двічі. Кожна транзакція, витягнута з повідомлення або з виписки, отримує зовнішній ідентифікатор, обчислений як префікс із 16 символів відбитка SHA-256 по її полях, колонка є унікальною в таблиці, а вставка виконується з `ON CONFLICT (external_id) DO NOTHING`. Практичний наслідок: поштову скриньку можна перечитувати скільки завгодно разів, а баланс не подвоюється. Без цього правила будь-яка фінансова ingest-проводка вже на третьому тижні починає породжувати дублікати, які хтось чистить вручну.
Чого такий агент не робить і чому важливо це писати на сторінці: він не схвалює платіж, не ухвалює кредитне рішення, не дає інвестиційних рекомендацій і не відповідає клієнту від імені установи. Показник упевненості, який він повертає, — це оцінка моделі про саму себе, а не вимірювання точності, зроблене нами — ця відмінність є різницею між інструментом і ілюзією контролю.
Що входить
Повідомлення читаються з поштової скриньки через IMAP, виписки — з PDF. Кожна транзакція отримує зовнішній ідентифікатор із відбитка SHA-256 по її полях, колонка `external_id` є `NOT NULL UNIQUE` у таблиці, а вставка виконується з `ON CONFLICT (external_id) DO NOTHING`, з окремим журналом для вставленого рядка і для того, що був пропущений як дублікат. Перечитування тієї самої скриньки не створює жодного дубліката.
Сім інструментів, не вільний текст: надходження від клієнта, зарплата, податок, платіж кредитору, операційна витрата, банківська комісія, невідомо. Модель має викликати лише один. Перші шість обов’язково вимагають, окрім назви або категорії, показник упевненості між 0,0 і 1,0, заявлений у схемі інструмента; сьомий вимагає причину. Модель, що використовується, оголошена в коді, а не схована в конфігурації.
Класифікатор, якому не можна сказати «не знаю», помилково віднесе, з великою впевненістю, саме нестандартні транзакції — тобто ті, що мають значення. Тому інструмент невідомого доступний так само, як і інші, і вимагає письмову причину, яка потрапляє в рядок. Рядки невідомого — це робочий список людини, а не збій системи.
Те саме підприємство з’являється у виписках у трьох написаннях. Понад класифікацією є зіставлення за косинусною схожістю між векторами. Ми сьогодні точно кажемо, що це за вектори: евристика n-грам символів, написана в коді з коментарем, що для продукції її треба замінити на реальний виклик до сервісу вбудовування. Вона працює для варіацій написання; це не семантичне зіставлення.
Чотири потоки автоматизації, по одному для трьох процесорів платежів і один для щоденної звірки, з 7 до 10 вузлів кожен. Ідея архітектури в тому, що різні джерела — e-mail, PDF, webhook — не створюють три таблиці, які потім треба узгоджувати, а ряди в одній таблиці, з тим самим правилом дедубляції.
Виклики проходять через власний шлюз на `api.megapromoting.com/v1`, із 44 налаштованими моделями, кожна з вартістю за токен і лімітом контексту. Проєктний ключ має білий список моделей, бюджет і період, його можна ротувати, зберігаючи історію, а споживання щоденно консолідується за користувач × ключ × модель. Деталь, що дивує всіх: моделі міркування утворюють внутрішні кроки, які система відстеження не бачить, але постачальник їх тарифікує — отже, брутто-бюджет на ключ встановлюється нижче бажаної межі.
Для кроків, які не потребують великої моделі — витягування полів із відомого формату, зіставлення назв, перевірки узгодженості — не потрібен жоден зовнішній постачальник; це звичайний код. Модель викликається лише для кроку класифікації. Коли ваша політика забороняє вихід даних, питання в тому, що саме надсилається моделі, а не в тому, чи використовується AI: можна надіслати опис транзакції без ідентифікаторів рахунку.
Не схвалює платіж і не виконує переказ. Не ухвалює кредитне рішення — правила, пороги та схвалення є політикою установи. Не дає інвестиційних рекомендацій і не відповідає клієнтові від вашого імені без окремого маршруту схвалення. І не гарантує вам точність: скор упевненості — це вихід моделі про саму себе, а не незалежне вимірювання.
Traseul
Перша поставка — це не агент, а список: категорії, до яких йому дозволено відносити, які обов’язкові поля вимагає кожна, і що означає «невідомо» у вас. Якщо список не можна записати на одній сторінці, завдання не підходить для агента — і краще дізнатися це зараз.
Читання з e-mail, PDF або webhook, витягування полів, обчислення зовнішнього ідентифікатора та запис у базу виконуються і перевіряються без жодного виклику моделі. Ми постачаємо конвеєр, який коректно інжестить і не дублює. Якщо цей крок не надійний, модель зверху лише породжує переконливіші помилки.
Поверх працюючого конвеєра ми ставимо інструменти класифікації й запускаємо на наборі ваших реальних транзакцій, із правильним результатом, визначеним людиною, яка сьогодні виконує цю роботу. Ми постачаємо таблицю зі збігами та розбіжностями, а не твердження про точність. Поріг, від якого рядок іде до людини, обирається з цієї таблиці.
Проєктний ключ із білим списком моделей і бюджетом, щоденна консолідація споживання, журнал із викликаним інструментом і балом, та ворота, які скеровують до людини все, що нижче порога або невідоме. Ми постачаємо доступи, документ введення в експлуатацію та письмовий список того, що агент робить сам і чого не робить.
Дані
Правила відрізняються від однієї галузі до іншої. Це ті, що застосовуються у фінансових послугах.
Випадок
Ситуація
Банківські сповіщення та щомісячні виписки надходили до поштової скриньки й читалися людиною, яка розподіляла їх за категоріями. Перша очевидна версія — скрипт, який читає скриньку і записує в базу, — має проблему, що стає помітною лише на третій тиждень: під час будь-якого перезапуску або повторного читання ті самі транзакції потрапляють знову.
Що ми збудували
Ми написали п’ять модулів, 1.526 рядків Python: два аналізатори сповіщень через IMAP, екстрактор PDF-виписок, класифікатор через інструменти та запис у PostgreSQL. Центральне правило — зовнішній ідентифікатор — 16-символьний префікс із SHA-256-відбитка над полями транзакції — з унікальним стовпцем у таблиці та вставкою `ON CONFLICT DO NOTHING`. Класифікація не повертає текст: модель викликає одну із семи інструментів, з обов’язковим балом упевненості, а «невідомо» потребує причини.
Що вийшло
Поштову скриньку можна перечитати будь-коли, а рядки, які вже оброблені, пропускаються й позначаються як дублікати в журналі. Транзакції, які модель не може класифікувати, з’являються як список роботи, з причиною поруч, замість того щоб їх проштовхували в категорію, аби здавалося, що все спрацювало.
Чого цей випадок не каже
Це внутрішній конвеєр, а не система, передана фінансовому клієнту: він не під git, каталоги тестів порожні, а приблизне зіставлення назв використовує евристику n-грам, яку код явно позначає як тимчасову. Я описав це тут, тому що це показує метод, а не тому, що це продукт.
Питання
Ні, і це не технічне обмеження, яке ми подолаємо в наступній версії. Схвалення — це рішення з юридичними наслідками, яке належить уповноваженій особі в установі. Агент готує: класифікує, заповнює, сигналізує, що не збігається. Система, яка схвалює сама, мала б мати змогу відповідати перед контролером, а бал упевненості — не відповідь.
Не з балу упевненості — це оцінка моделі самої себе, а не вимірювання. Це видно з порівняння з рішеннями людини, яка виконує цю роботу сьогодні, на наборі реальних транзакцій, зробленому до запуску чогось у автоматичному режимі. Результат цього порівняння — таблиця, яку ми передаємо, включно з рядками, де агент помилився.
Викликайте інструмент «невідомо» і вкажіть причину. Рядок потрапляє до списку роботи людини, а не в категорію, обрану навмання, щоб здавалося, що система спрацювала. Класифікатор без виходу «не знаю» помиляється саме там, де помилка коштує: на незвичних транзакціях.
Ні. Кожна транзакція має зовнішній ідентифікатор, обчислений як відбиток за її полями, колонка є унікальною, а вставка використовує `ON CONFLICT (external_id) DO NOTHING`. Пропущений рядок позначається в журналі як дубль, тож видно, що його було перечитано.
Для кроку класифікації — так: опис транзакції та сума йдуть до обраної моделі через наш gateway, з ключем проєкту, білим списком моделей і бюджетом. Решта кроків — читання, витяг, дедублікація, зіставлення імен — це звичайний код і нікуди не виходять. Що саме має право виходити, визначається письмово до початку, а не з’ясовується з журналів потім.
Так, це один із модулів конвеєра. Що треба знати — PDF-виписка це крихкий формат: вона читається за структурою, яку формує відповідний банк, а коли банк змінює шаблон, модуль треба коригувати. Тому він пишеться з перевірками, які падають гучно, а не які здогадуються.
Тому що наше правило вимагає щонайменше двох власних впроваджень, щоб писати «доставлено», а описаний тут конвеєр працює на наших даних, а не в продакшені у клієнта з фінансового сектору. Є й недоліки, які ми називаємо: це не під git, немає тестів, а зіставлення імен використовує евристику, позначену в коді як тимчасову. Коли ми зможемо посилатися на дві впровадження у клієнтів, змінемо слово.
Три речі: закритий список категорій, до яких він має право відносити, набір реальних транзакцій із правильною відповіддю, наданою людиною, яка сьогодні виконує цю роботу, і письмове рішення про те, які поля мають право виходити з вашої мережі. Без третього пункту ми не починаємо, бо це єдине, що не можна виправити згодом.
Розкажіть про свій процес. Разом визначимо, що варто збудувати, що можна підключити і як перевіримо результат.