Почему воронка — это воронка
Всё просто — на каждом этапе воронки что-то отсекается: из-за особенностей ведения базы самой ФАС и моих представление о том, каким должен быть RAG для бота. На картинке анализ «потерь». Итоговая эффективность пайплайна, то есть процент ссылок, ставших знаниями в базе, 19.89%.
Технические особенности пайплайна
В пайплайне много технических фич, призванных делать его многоразовым и оптимизированным. Например, есть механизме «изоляции запусков» или сессий.
В коде есть переменная
CURRENT_SESSION, и при каждом запуске скрапера этой переменной присваивается уникальный ID, который дописывается в JSON, возвращаемый нейросетью после разметки. Таблица, которую я отсматриваю, собирается с учетом этих ID, чтобы в неё не попадало то, что я уже видела. Также есть логика кэширования, чтобы не тратить лишнее время на проходы скрапера и деньги на API-запросы. Кэширование реализовано в виде:
🤩логгера, записывающего все ссылки, по которым скрапер когда-либо ходил;
🤩 логики проверки наличия JSONа с нужным docID (если JSON есть, значит решение уже было размечено);
🤩специального кэша для корпуса эмбеддингов, чтобы перезаписывать корпус.
Всё это работает и на отказоустойчивость — если падает соединение с Интернетом или какие-то проблемы на стороне Gemini API. Также из кэширования вырастает логика прогона скрапера по тем ссылкам, на которых он был раньше, но не нашёл решения — вдруг решение появилось, и его можно скачать и далее отправить на разметку.
Да как вообще этот пайплайн выглядит, это какая-то программа?
Это ноутбук (файл в формате
.ipynb) в среде Jupyter Lab. Это не совсем IDE (Integrated Development Environment типа VS Code), в которой делаются приложения. У меня особый вайб-кодерский путь, и я использую именно ноутбуки. В ноутбуках код поделен на ячейки, и выполняя каждую ячейку, ты сразу видишь результат ее работы в виде отчётов о выполнении.
Ноутбук в варианте последнего прогона ячеек можно послать кому-то, кто откроет его в своём Юпитере и увидит все те же отчёты (или прямо в нейросети, почти все читают
.ipynb). Ноутбуки подходят для анализа данных, если вам не нужен непременно какой-то интерфейс. И, как мне кажется, формат хорошо подходит для пайплайна — это сильно проще, чем делать программный интерфейс. Можно быть достаточно гибкой в том, чтобы быстро добавить «аварийные» или аналитические ячейки. Но! Нюанс использования ноутбука в том, что надо хорошо понимать, какие ячейки с какими у тебя связаны — если не запустишь ячейку с импортами библиотек или активацией API-ключа, то другая нужная ячейка не заработает. А если Юпитер вылетел посреди скрапинга, то вылетает и вся история с сессиями, потому что переменная
CURRENT_SESSION живет только в памяти. Чем больше ячеек — тем более тормозной ноутбук. И всё в таком духе. Если есть идеи, как можно реализовать пайплайн в более удобном виде — просветите, пожалуйста.
Что еще можно было бы исправить и добавить?
За несколько месяцев работы по наполнению базы несколько раз менялись параметры разметки и скриптованных добавлений в JSONы, которые возвращает нейросеть. Пару раз менялся промпт для разметки. И, собирая датасет, я споткнулась на том, что JSONы получились неоднородные, и их нужно было дополнительно унифицировать.
То есть для текущей версии пайплайна напрашивается какой-то механизм версионирования промпта. И вообще, кажется, нужно ветвить пайплайн на работу ещё и с датасетом, ведь его тоже нужно будет пополнять и дальше.
На этом всё! Спасибо всем, кто читал об этой моей работе. Для меня она оказалась одной из самых интересных в рамках всего проекта. И пусть процесс и неидеален, опыт получился совершенно бесценный.