Привет, Хабр! Меня зовут Лиза, я разработчик направления AI/ML/DS. Вместе с командой мы решаем задачи, связанные с обработкой текстовых данных. В работе с большими языковыми моделями и классическим NLP я постоянно ищу баланс между скоростью, качеством и достоверностью — и в этой статье поделюсь нашими кейсами и практическим опытом, который помогает создавать надёжные и эффективные решения в условиях быстро меняющегося мира нейросетей.

Обычный рабочий день: заварил кофе, созвонов нет, можно и поработать. Заходишь в Jira, а там новая таска. Срок исполнения — вчера. Данные в хаосе, от прямых ответов на вопросы про данные заказчик уклоняется.

И тут возникает соблазн — отдать всё LLM-ке. Пишем промпт, слёзно просим несколько производственных видеокарт и кидаем всё в LLM, она ж явно больше нас повидала. И простое программистское: докручиваем API-шку, пишем тесты, но счастье не случается. Где-то получаем значение, которого нет, где-то ответ с первого взгляда правильный, но если рассмотреть глубже - не подходит. 

Судорожно добавляем новые вводные в промпт, а результат в некоторых кейсах всё равно как в анекдоте:

— Муж, купи батон хлеба, если будут яйца — возьми десяток.

Муж возвращается из магазина с десятью батонами.

— Ты зачем столько хлеба купил?

— Так ведь яйца были...

Кажется, закончить рабочий день в обед не удастся. Давайте разбираться, как заставить решение работать и подтвердить это результатами теста заказчику.

Что имеется: данные сложные, структуры и досконального понимания бизнес-процессов нет, а задачу решать критически нужно для бизнеса. В предметной области и данных разобраться придётся в любом случае.

При хорошем понимании предметной области большую задачу по типу: "Хочу, чтоб оно работало так, на входе много различных форматов, на выходе вот такая структура" можно декомпозировать в понятные подзадачи, которые при должном кропотливом сборе данных решаются через дешёвые в инференсе и предсказуемые модели, например, на основе архитектуры BERT, а также эвристик. Если нет времени, но есть вычислительный ресурс — с декомпозированными задачами большие LLM справляются хорошо, и результат проще контролировать.

Приведу пример: из вопроса к системе «Какой номер телефона у Иванова» информацию можно получить несколькими способами:

• Попросить извлечь все сущности LLM, чтобы понять, как сформировать поисковой запрос. С этой задачей справится и несложный промпт.

• Извлечь сущности через модель NER, обученную, например, на основе архитектуры BERT. Но необходимо знать, с какими запросами может приходить пользователь, собрать данные, обучить модель.

Сейчас немножко занудства: какую бы ни выбрали модель, идеально работать она не будет (за исключением действительно простых задач). Чтобы повысить количество успешно отработанных запросов, в своей работе я применяю эвристики.

Эвристики

Как при работе с генеративными LLM, так и при использовании классических моделей машинного обучения бывают области, которые не имеют чёткой структуры или данные на входе имеют широкий диапазон возможных представлений. В таком случае применение вероятностных моделей может хорошо улучшить бизнес-метрики и повысить надёжность и гибкость системы.

Примеры разнообразны и зависят от конкретной задачи. Например, можно сразу понять, что с большой долей вероятности в документе не содержится нужной информации на основе ключевых слов, и не запускать дорогие в инференсе модели. Чем выше доверие к эвристикам, тем меньше будет тратиться вычислительных ресурсов на вызов «дорогих» моделей. И соответственно, чем меньше доверие, тем чаще будет происходить обращение к дорогостоящим моделям. Это регулируется при помощи threshold — порогового значения, обозначающего уверенность в решении.

Перейду непосредственно к обсуждению подходов.

LLM

LLM не является золотой пулей, но практически любую задачу, связанную с обработкой текстовых данных (или всего, что представляется в таком виде) можно решить с их использованием, но с учетом следующих факторов:

• Дорогой инференс  — при большом количестве пользователей и запросов стоимость вычислений может быть существенной. Например, для обработки 1000 одновременных запросов может потребоваться десяток мощных GPU.

• Галлюцинации — модель может генерировать правдоподобно звучащую, но фактически неверную информацию.

• Все равно нужно разобраться в предметной области — без понимания контекста невозможно настроить модель правильно.

• Если ваша задача очень сложная и специфичная может понадобиться обучение: адаптер дешевле, но сравнимо с тюнингом машины; полное обучение очень ресурсозатратно, стоимость обучения зачастую измеряется в миллионах.

Если не хочется заморачиваться, можно использовать внешние LLM, но наряду с ограничениями выше появляются следующие:

• Конфиденциальность данных не гарантирована — ваши запросы могут использоваться для дообучения модели.

• Мы не контролируем серверы, на которых происходит инференс — это риск для критичных бизнес-процессов.

• Часто есть ограничения по количеству запросов в единицу времени — rate limits могут замедлить работу системы. 

Учитывая эти особенности LLM, чтобы добиться действительно качественного и надёжного результата, рекомендую придерживаться следующего чек-листа, который поможет систематизировать работу с моделью и повысить шансы на успешное применение.

Чек-лист для качественного итогового решения:

1. Грамотно подобранная модель с учётом данных, на которых она училась, и мировой практики применения в различных типах задач. Не всегда учитываются только SOTA или самые высокие метрики на общедоступных датасетах. Обычно всё решают тесты: запускаем модель, смотрим бизнес-метрики, тайминги и т.д.

2. Чёткий промпт, учитывающий особенности предметной области, но без лишних деталей. Скорее всего, придётся перебрать десятки, а то и сотни промптов. Здесь всё то же — грамотно составленные тесты помогут понять, какой промпт подходит.

3. Если галлюцинации имеют критическое значение — необходимы дополнительные методы проверки ответов и совпадения их с исходным текстом. Например, если это система ответов на вопросы, проверить, что исходные числа взяты из текста и т.д.

Но классика жива. Если не боитесь сбора датасетов, ломания головы о том, как подать данные, какой препроцессинг, постпроцессинг и другие «цессинги» сделать — можно рассмотреть этот вариант.

Классический NLP

Классический NLP преобразует одни данные в другие предсказуемо, ничего кардинально нового не генерируется. Выход модели строго определён входом и весами модели, такие модели ошибаются предсказуемо, ошибки исправляются расширением обучающей выборки и подбором размера, архитектуры, гиперпараметров модели. Для LLM важны все те же факторы, но из-за того, что модель генеративная, предсказуемость и объяснимость намного сложнее, а взаимосвязи между входом и выходом зачастую необъяснимы.

Для обучения качественной модели:

• Требуется большой объём размеченных данных для обучения моделей. Спойлер: на первых итерациях можно грамотно создать синтетические данные с минимумом ручной разметки.

• Модели узкоспециализированы под конкретную задачу. Можно делать более общую модель для домена, а в дальнейшем различные постобработки.

• Модели плохо справляются с неоднозначностью и нюансами языка, если не заложить нюансы в обучающую выборку.

• Нужно хорошо понимать предметную область.

Чек-лист для качественного итогового решения:

• Достаточный набор разнообразных тестовых данных — чем больше edge cases покрыто, тем лучше.

• Качественная предобработка данных: очистка данных, подготовка нужного формата данных (схожего с тем, на чём учится модель).

• Регулярное обучение модели с учётом обратной связи от пользователей и проблемных кейсов.

• Метрики качества с учётом бизнес-задачи, её особенностей, критериев качества наряду с F1, Accuracy... по различным моделям.

• Грамотно подобранный пайплайн обработки данных с несколькими моделями, эвристиками и критериями на каждом из шагов.

Бизнес-кейсы

Теория хороша, но в проде всё решают кейсы — что реально сработало

Начну с животрепещущего - вроде, структурированных, а по факту - нет, данных.

Кейс 1: Извлечение данных из таблиц

Представьте, что на входе у нас большая  огромная таблица с иерархией заголовков, ещё и не лучшего качества с точки зрения чёткости границ таблицы. Мы пропускаем её через сервис OCR и получаем текстовое представление.

Да, можно пропустить как есть через LLM, но если сбилась структура или таблица действительно большая — на выходе можем получить смесь бульдога с носорогом. Посмотрели на выход, подшаманили промпт, прописали ограничения — выход может всё равно не радовать, но зато магия. Если эту магию обернуть в метрики и экспериментировать, можно добиться неплохого качества, а остаток отдать на откуп эвристикам, но точечно и с пониманием.

Другой вариант в данной задаче — обучить модель NER (извлечение именованных сущностей из текста), правильно сделать предобработку и постобработку данных с учётом особенностей предметной области и данных, и получить на выходе всю интересующую информацию.

Мы в своей работе чаще всего используем разные пути для разных частей задачи, руководствуясь здравым смыслом, временем на погружение, вычислительными ресурсами и т.д.

Выбор пути зависит от желаемых:

• точности

• стоимости инференса

• допустимости галлюцинаций

• контроля над результатом

Давайте разберем варианты решения на конкретном примере:

Таблица взята с чьего-то диплома. И поверьте, она еще очень прилично выглядит. В реальности бывают сканы, в которые заворачивали рыбу, писали ручкой поверх данных или почему-то потерялась шапка таблица, почему-то не прорисовались границы. Эту боль можно описывать бесконечно, вернемся к поиску решения.

Таблицу пропускаем через модули для LayoutDetector, распознаем моделькой OCR и на выходе получаем текст с координатами и какой-то структурой. Например

 {
                    "id": "/page/0/Table/1",
                    "block_type": "Table",
                    "bbox": [
                        80.17,
                        338.47,
                        558.55,
                        661.58
                    ],
                    "children": [
                        [
                            {
                                "cell_id": 0,
                                "bbox": [
                                    80.17100755667506,
                                    339.4190250462628,
                                    721.0589470098,
                                    375.95827065173154
                                ],
                                "row_id": 0,
                                "rowspan": 1,
                                "within_row_id": 0,
                                "col_id": 0,
                                "colspan": 2,
                                "text": "какой-то текст",
                                "len": 16
                            },

И таких children-ов по количеству ячеек в таблице.

Вариант 1 (LLM): Взять LLM с большим контекстом, кинуть контекст как есть и попросить решить задачу. Чтобы получить потенциально хорошие результаты, LLM-модель должна быть очень «жирная», кушать много ресурса и не давать гарантии, что разберётся с данными и их структурой правильно. Спойлер: в каких-то случаях результаты неплохого качества при таком подходе.

Вариант 2 (классический NLP): Для каждого значения таблицы строим путь к нему. Например, для таблицы выше один из примеров будет:

Текстурные характеристики | объем пор, см3/г | суммарный | 0,959

Если понимать содержимое каждой ячейки заголовка, то можно понять, что описывают данные в ячейке значения. Для этого можно разработать систему тэгов, обучить модель NER, и таким образом определять интересующие значения. Да, нужно разобраться, подготовить данные, но на выходе предсказуемость и дешевый инференс.

Кейс 2: Определение намерений пользователя

Представите, что есть сложная система, которая и по документам ищет и по их внутренности, встречи ставит, информацию о сотрудниках дает, в общем, Галя в мире бизнес-задач. 

На вход приходит запрос пользователя. Сначала нужно определить, а чего же хочет пользователь? Задача усложняется тем, что вопросы “Где работает Крылов из документов” и “Где документ о работе Крылова?” - это запросы с разным намерением, но по набору слов очень похожи. Задача, на самом деле, нетривиальная. И решать ее все так же можно обучив классификатор, подготовив выборку для обучения или написать подробный промпт с описанием максимального количества нюансов. 

Следующий этап - работа с каждым типом намерений, в зависимости от  которого будем задавать правила формирования запроса для поиска в нужный источник данных. Здесь также могут быть разные варианты, их комбинации.

Что выбрать?

Когда стоит использовать LLM:

• Быстрый MVP без доступа к обучающим данным

• Задачи с высокой вариативностью входных данных

• Когда важна гибкость, а вычислительные ресурсы не критичны

Когда стоит использовать внешние API (GPT-4, Claude и др.):

• Прототипирование и тестирование идей

• Небольшое количество запросов

• Нет требований к конфиденциальности данных

Когда стоит использовать классический NLP:

• Критична предсказуемость результата

• Важна низкая стоимость инференса при большом количестве запросов

• Есть время и ресурсы на сбор и разметку данных

• Узкая специфичная задача с понятной структурой

Какой из подходов всё же выбрать? Тесты, тесты и ещё раз тесты. В нашем опыте много случаев, когда понимание предметной области и качественный вывод от тестов (подсвечивание проблемных кейсов, вывод метрик, сохранение информации о каждом эксперименте, описание целей) позволяло снизить стоимость инференса, убрав часть задач с видеокарт на более дешёвый в инференсе процессор, не потеряв в качестве решения и сделав его более предсказуемым.

На самом деле, что в итоге вы будете использовать в итоговом решении может меняться в процессе разработки, уточнения требований и т.д. Важным остается - понимание данных и зачем каждая из моделей вообще нужна, какую задачу она решает, какую функцию выполняет. 

А как вы ищете баланс между качеством, скоростью и количеством моделей в своих проектах?