Кейс про reasoning, в котором автор признается в использовании векторов и в архитектурной ошибке
Задача кейса - ускорить работу c документами compliance офицеров, час работы которых стоит 160-400 EUR и выше.
Я про это уже писал тут:
- Эпизод I
- Эпизод II
- Эпизод III
- Reasoning кирпичик для Stargate
- Эпизод IV
Архитектура и подходы - не коммерческая тайна. Это просто повторение успешных паттернов, которые я уже видел в других проектах.
Система состоит из трех частей.
Первая часть - data parsing с VLM под капотом. Регуляторные документы обычно распространяются в хитровыверченных PDF разных форматов. Нам нужно не просто их распарсить в текст, но и сохранить семантическую структуру (граф).
Когда я показал один такой документ Илье, он сказал про “криптонит всех парсеров” и “коварно” 😁
На эту часть я потратил в сумме три месяца. Под капотом - PyMuPDF, Paddleocr/PaddleX, Gemini Pro 2.5/OpenAI и пара интерактивных интерфейсов для реализации REPL/Human In The Loop. Конечно же SO CoT.
Вторая часть - анализатор документов c LLM под капотом. Это workflow, который сопоставляет набор регуляторных документов и набор внутренних документов, выделяет список применимых требований и аргументированно выдает список проблем во внутренних документах, которые надо бы проверить.
На эту часть я потратил тоже месяца три в сумме.
(1) загружаем все релевантные графы документов
(2) проходимся по графам, анализируем узлы, проецируем все в мини-графы. Каждый мини-граф - это конкретная статья со всеми подпунктами и релевантным контекстом
(3) анализируем каждый мини-граф - содержит ли он в себе конкретные требования, которые нужно выполнять? А применимы ли эти требования к рассматриваемым документам?
(4) анализируем найденные требования - критичность? какая информация должна быть во внутренних документах, которые будут эти требования выполнять?
Везде тут используются SO CoT. В схемах прописаны checklists, которые содержат промежуточные пункты, чтобы направлять мышление системы, да и просто отлаживать весь процесс.
(5) ищем релевантные мини-графы во внутренней документации. В текущей версии использую embedding openai-text-large + LLM review, который делается просто и из коробки работает хорошо. Если соберется достаточно размеченных данных, которые показывают на ошибки, заменю на поиск по графу и онтологиям.
(6) собираем пакет документации (мини-графы требований и найденный evidence) и прогоняем еще через один SO CoT для финального анализа. Выписываем результаты в audit report, сортируем по срочности.
Третья часть - это интерфейс, который дает экспертам поработать с этим отчетом. Там есть дашборд с метриками и список найденных проблем. Эксперты могут загрузить в workbench каждую проблему, чтобы посмотреть результаты анализа, найденный evidence, пройтись по цепочке размышлений или просто по графу регуляторного документа. Есть возможность сделать review, пометить evidence, чтобы эти правки можно было отправить дальше в работу. Ну и заодно тут мы собираем feedback для калибрации системы в будущем.
Третья часть написана на next.js/React/Tailwind/TS + NixOS/Caddy deployment. Я на нее потратил в сумме часов 18 и пару недель. 100% кода написано AI+Coding.
Концепцию UX помог сформировать Gemini Pro 2.5 (пригодился его инженерный склад ума и активный контекст в 500k). Красивый интерфейс набросал Claude Opus 4
OpenAI Codex встроил этот интерфейс в чистый next.js шаблон и вел разработку дальше (вот тут и была моя архитектурная ошибка - next.js был очень неудачным выбором для AI+Coding - мало документации и слишком часто его меняют).
От меня агентам шел поток задач и отзывов. Они - ваяли. Использовали AICODE- память для посланий друг другу. В сложных случаях использовал implementation plan. Всегда запускал 2-4 версии задач, выбирал самый симпатичный вариант, остальные выкидывал. ~60% задач были отправлены с телефона)
В итоге получился очень интересный опыт. Надо теперь брать отпуск и систематизировать все возможности в голове)
Ваш, @llm_under_hood 🤗
>>Click here to continue<<