Кейс про крупные тендеры и генерацию лидов
Этот кейс - очередная вариация на тему быстрой генерации лидов для бизнеса.
Некоторые компании специализируются на поставках оборудования и компонентов в особо крупных объемах. Для этого они постоянно мониторят публичные тендерные площадки в разных странах. Только в рамках Европы таких площадок более ста.
Как только появляется интересный тендер, вся компания может переключиться на его анализ и составление своего предложения по предложенным товарным позициям. Повторяем процесс достаточно раз в год и получаем годовой оборот уровня 100M USD/EUR.
Но тут есть один маленький нюанс. Смотрите - площадок сто, языков много, штатов/стран - тоже немало. Чтобы найти тот самый интересный тендер нужно перелопатить 100-1000 документов. Проблема обычно не в том, чтобы выиграть тендер, а в том, чтобы найти его среди тысяч других документов.
Больше всего времени уходит на поиск, перелопачивание вариантов на разных языках, предварительный скрининг, перевод и выжимку на язык компании с последующим скринингом. Примерно с такой болью к нам в Trustbit и пришел клиент.
Но ведь, если посмотреть сбоку, то это обычная помесь ежа с ужом - тут достаточно взять существующий процесс компании по скринингу тендеров, формализовать его для LLM-ок и обойтись без галлюцинаций.
Идея такая - нам не нужно придумывать новый бизнес-процесс. Он уже есть и работает очень хорошо (а иначе бы проект и не попал в топ для реализации). Нужно посидеть с клиентом и найти способ его формализовать для LLM.
Например, я бы попробовал начать с формулирования такой таблички (чеклиста), данные для которой можно извлечь из каждого документа для тендера и использовать для принятия решения. Просто такой подход уже работал в сходных кейсах.
Табличка - это и будет наш выхлоп от Knowledge Mapping. Причем можно клиента сразу попросить вручную заполнить 20 таких табличек на 20 характерных PDF-ок тендеров.
Затем одна команда, которая собаку съела на извлечении данных из PDF в оптовых масштабах и без галлюцинаций, напишет каскад для заполнения этих табличек. Причем на данном этапе нам без разницы, какой был исходный язык документа.
А вторая команда, которая плотно работает с клиентом, формализует правила скоринга тендеров по табличке. Тут нужно будет много думать, общаться с экспертами и анализировать процесс - это требует понимания бизнеса и DDD. А вот LLM много не надо - мы же уже работаем с хорошо структурированными знаниями.
Что самое классное - это наш первый проект с LLM под капотом, где я с клиентом даже не общался. C ним общалась команда разработчиков с опытом внедрения проектов без LLM, а я просто выдал фреймворк приоритизации проектов, рассказал про портфель кейсов и основы внедрения проектов.
Потом они провели Event Storming с клиентом вживую (см короткое видео про него на английском). Они фиксировали вместе существующие бизнес процессы и сразу уделяли внимание проблемам, для которых мы уже знаем простые решения. Мне осталось только скорректировать PoC proposal чтобы они случайно не наступили на пару грабель.
Кейс пока на этапе одобрения. Предварительно я ожидаю, что в нем ~85% времени потратит команда разработчиков, а 15% времени достанется LLM разработчикам на написание каскада для извлечения данных и фич из PDF тендеров.
В предыдущем кейсе про захват рынка при помощи LLM, примерно такая пропорция затрат времени (85/15) и была в итоге.
Ваш, @llm_under_hood 🤗
Про другие кейсы можно почитать на канале по тэгу #aicase. Оглавление тут.
>>Click here to continue<<