Как дообучить открытую модель под свой бизнес

Три разные вещи, которые постоянно путают

Когда говорят «обучите модель под нас», обычно имеют в виду одну из трёх совершенно разных работ. Разница в цене и сроках между ними кратная, поэтому её стоит проговорить до начала проекта.

Первое это промпт, системная инструкция. Вы объясняете модели, кто она, как отвечать, чего не делать и в каком формате выдавать результат. Меняется мгновенно, стоит дёшево, и удивительно большая часть задач закрывается именно здесь.

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

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

Почему в большинстве случаев сначала RAG

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

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

Третья причина это цена входа. Настроить поиск по документам обычно быстрее, чем собрать качественную обучающую выборку. А заодно этот этап показывает, каких материалов у компании нет и какие написаны так, что их не понимает даже человек.

Разумный порядок выглядит так: сначала инструкция, потом база знаний, и только потом дообучение, если осталось то, что первые два способа не закрыли. Обычно остаётся стиль, формат, узкая терминология и специфические правила поведения.

LoRA и QLoRA простыми словами

Полное дообучение означает изменение всех чисел внутри модели, а их миллиарды. Это долго и дорого. LoRA решает задачу иначе: сама модель остаётся нетронутой, а рядом обучается небольшая добавка, тонкий слой поправок, который подключается к модели при запуске.

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

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

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

Полное дообучение: когда оно оправдано

Полное дообучение имеет смысл, когда задача не сводится к стилю и формату, а требует по сути другой модели. Например, узкая предметная область с собственным языком, где обычная модель плохо понимает даже постановку вопроса. Или редкий язык и диалект, представленный в исходной модели слабо. Или переход в другую модальность, когда модель учат работать с непривычным для неё типом данных.

Второй случай это очень большой объём собственных данных. Когда речь идёт о миллионах качественных примеров, лёгкая добавка перестаёт вмещать в себя всё, что вы хотите передать модели.

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

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

Сколько нужно данных

Ожидание обычно такое: чтобы дообучить модель, нужны десятки тысяч примеров. На практике для типичных задач вроде стиля ответов, формата и соблюдения правил бывает достаточно нескольких сотен хорошо подобранных примеров.

Работает это так: модель уже умеет говорить, рассуждать и понимать вопросы. Вы не учите её языку, вы показываете, как именно надо отвечать в вашей ситуации. Для этого нужны не объёмы, а точность.

Отсюда главное правило: тысяча плохих примеров хуже, чем сто хороших. Плохой пример это ответ с ошибкой по сути, ответ не в том формате, ответ, который в вашей компании считается неправильным, или просто неудачная формулировка, попавшая в выборку из реальной переписки. Модель не отличает хорошее от плохого, она воспроизводит то, что видит, и уверенно повторяет ваши ошибки.

Поэтому сбор данных это работа не техническая, а содержательная. Примеры должен отбирать человек, который понимает, какой ответ правильный, и умеет объяснить почему. Обычно это руководитель отдела или самый сильный сотрудник, а не подрядчик.

Как выглядят данные на практике

Формат обучающей выборки проще, чем кажется. В основе лежат пары: вход и правильный ответ. Вход это вопрос клиента, задача, документ или их сочетание. Ответ это то, что вы считаете образцовым.

Источники, откуда такие пары обычно берут:

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

Отдельно стоит потратить время на разнообразие. Если девять примеров из десяти про одну и ту же тему, модель решит, что это и есть её работа, и начнёт тянуть все разговоры в эту сторону.

И ещё одно: данные надо чистить от персональной информации до того, как они попадут в обучение, а не после.

Железо и время

Для ориентира: лёгкое дообучение методом LoRA для модели размером примерно до восьми миллиардов параметров реально выполняется на одной видеокарте с достаточным объёмом памяти. Это укладывается в аренду на короткий срок или в собственную машину, если она уже есть.

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

Время самого обучения на небольшой выборке обычно измеряется часами, а не неделями. Основное время проекта уходит не на обучение, а на подготовку данных и на проверку результата. Это стоит закладывать в план, потому что ожидание «обучим за выходные» разбивается именно о сбор примеров.

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

Как понять, что стало лучше

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

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

Вторая это слепое сравнение. Ответы старой и новой версии показывают эксперту вперемешку, без пометок, какая версия где. Человек выбирает лучший ответ, и только потом раскрывается, какой модели он принадлежал. Этот приём убирает эффект ожидания и часто даёт неприятные, но полезные результаты.

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

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

Частые ошибки

Список того, что встречается в проектах чаще всего, независимо от отрасли.

• Дообучение вместо инструкции. Задачу, которая решается одним абзацем в системном промпте, пытаются решить обучающим циклом. Проверьте промпт до того, как собирать данные.
• Знания, вшитые в модель. Прайс и регламенты меняются, а модель продолжает уверенно называть прошлогодние условия. Меняющиеся факты место в базе знаний, а не в весах.
• Персональные данные в обучающей выборке. Из переписки в обучение уезжают телефоны, адреса и суммы. Убрать их потом из модели гораздо сложнее, чем вычистить заранее.
• Забывание общих навыков. Модель, обученную только на коротких шаблонных ответах, часто перестаёт справляться с обычными вопросами. Лечится разнообразием выборки и аккуратными настройками обучения.
• Отсутствие версионирования. Никто не помнит, какая версия сейчас работает, на каких данных обучалась и как откатиться. Каждая версия должна иметь номер, описание данных и возможность вернуться к предыдущей.
• Обучение без цели. Если заранее не сформулировано, что именно должно измениться, оценить результат невозможно, и проект заканчивается спором о вкусах.

Юридическая сторона в общих словах

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

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

Практический подход, который экономит время: до сбора данных описать, откуда берутся примеры, какие поля в них есть и что именно из них вычищается, и показать это описание юристу и ответственному за политику компании. Это короткий документ, но именно он потом отвечает на неудобные вопросы.

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

Чем это заканчивается на практике

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

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

К этому прилагается регламент: кто отвечает за содержание базы знаний, как часто проверяются ответы, что делать с ошибкой, кто утверждает обновление модели и как откатиться назад. Без этой части система деградирует незаметно: материалы устаревают, ответы съезжают, и однажды это замечает клиент.

Такой набор скучнее, чем идея «обучим нейросеть под нас», но он обновляется силами самой компании и переживает смену подрядчика, а это обычно и есть настоящая цель проекта.