В М2 большой объём письменной коммуникации с клиентами. Это и ответы на общие вопросы — о компании, процессах подбора и покупки недвижимости, — и обсуждение конкретных деталей запущенных сделок. К примеру, клиенты хотят знать, в каком отделении банка они будут подписывать документы, пришли ли деньги продавцу, прошёл ли объект недвижимости проверки перед продажей.

Работа с вопросами происходит в тикет-системе клиентской поддержки (UseDesk). Для каждого вопроса через любой канал коммуникации (e-mail, мессенджеры, чат на сайте) заводится обращение, и сотрудник экспертной поддержки отвечает на него с определённым SLA. 

Для оптимизации работы с обращениями процесс разделён на 3 линии поддержки. Первая линия отвечает только на вопросы без привязки к продукту и не знает о конкретных сделках. Она обрабатывает порядка 10 000 обращений в месяц. Вторая линия знает о продуктах и отвечает на вопросы по сделкам, таких обращений около 3 000 в месяц. Третья линия — это уже команды продуктов, до них доходят единичные вопросы.

Вопросы к первой линии поддержки и частично ко второй  — однотипные, их обработку можно автоматизировать и сократить тем самым затраты на поддержание бизнес-процесса. 

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

Кстати, интересно ваше мнение, как бы вы подошли к решению задачи по автоматизации такого бизнес-процесса? Напишите в комменты или личку. 

Предлагаемое решение

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

Оценка бизнес-эффекта была следующая: 60% вопросов экспертной поддержки — типовые, ответы на них хорошо описаны в базе знаний. Такие ответы можно автоматизировать. На обработку одного запроса эксперты первой линии тратят пять минут. 10 000 обращений * 0,6 * 5 минут = 500 часов в месяц. 

Это потенциальная экономия, которой можно достичь минимальными инвестициями. Гипотезу о минимальных затратах мы и взялись подтвердить (или опровергнуть).

Наша цель на два дня хакатона — создать чат-бот, который будет:

• отвечать на вопросы про М2;

• использовать информацию с сайта компании из раздела Q&A;

• обучаться на опыте.

Была идея использовать большую языковую модель (LLM, large language model), в частности ChatGPT. У ChatGPT есть простое API, куда можно присылать вопросы по HTTP. Это стоит денег, но тарифы недорогие и при использовании в небольших (для промышленного масштаба) объёмах в сотни вопросов в день сумма «набегает» небольшая. Публичный интерфейс ChatGPT принимает вопрос и даёт на него ответ. Ответ конкатенируется к вопросу. Тарификация — за число слов в сумме.

Ниже я излагаю своё понимание работы языковой модели, основанное на доступных мне (с точки зрения базового образования, опыта, интеллекта, а также времени, потраченного на поиск) источниках. Это объяснение субъективно и может оказаться неполным, я основываюсь на оригинальной статье «Attention is all you need». 

Возможно, где-то уже есть подробный разбор механики работы LLM на стадии inference с пруфами и/или в академическом формате. Добавьте, пожалуйста, ссылки в комментарии. И будет интересно послушать ваше мнение насчёт принципов работы LLM.

Общие принципы работы LLM

Этот параграф можно пропустить без потери верхнеуровневого контекста.

LLM работают в (n x k)-мерных пространствах, где n достигает десятков тысяч (context window) (GPT-4). Языковая модель применяется к набору из n токенов. Каждый токен представлен в модели вектором размерности k: во время тренировки он получает координаты в k-мерном пространстве hidden state. Результатом работы модели является распределение вероятностей дискретной случайной величины, которая принимает значения из множества всех токенов. Это множество называется словарём токенов (token vocabulary)  и имеет размерность до 50 000. 

Таким образом, модель можно считать функцией из векторного пространства в вероятностное пространство. Векторы — это наборы токенов из строки ввода. Конкретное распределение вероятностей принадлежит вероятностному пространству. Однако, некоторые источники упрощают и рассматривают эту функцию в векторном пространстве размерности n + 1 и опускают вероятностный характер вывода: LLMs are mathematical functions whose input and output are lists of numbers. Это справедливо, если включить в функцию закон по выбору (n + 1)-ого токена из распределения вероятностей. Например, выбирать всегда самый вероятный. 

Токен в разных моделях — какая-то часть слова, у OpenAI это в среднем 0,75 слова. Например, токеном может быть «благо» как часть слова «благородный». 

Токены не равны словам или морфемам («благо» не корень). Скорее, это наборы букв, которые встречаются чаще, чем другие наборы в корпусе. Корпус — это набор написанных человеком текстов, на нём производилась тренировка модели.

Дальше я буду в некоторых контекстах использовать «слово» как синоним «токена» для упрощения, без потери деталей в смыслах.

Полученную в результате тренировки функцию применяют к набору слов из вопроса, и она «составляет» (G из GPT — generative pre-trained transformer) самую высоковероятную последовательность токенов для ответа. Таких последовательностей может быть великое множество, и все они могут иметь равное произведение вероятностей вхождения каждого слова в последовательности (вероятность предложения). Тогда модель выбирает какую-то последовательность из равнозначных, но она может быть полной белибердой. 

Для нивелирования этого эффекта используют технологию RLHF — reinforcement learning with human feedback. Человек даёт модели обратную связь о том, какая последовательность (ответ) субъективно лучше. Таким образом перестраиваются координаты токенов из «выигравшего» ответа. В следующий раз, если среди кандидатов на ответ будет такая «прокачанная» последовательность, то она выиграет. Так происходит fine tuning — дотренировка модели.

В результате тренировки с RLHF получается «всезнающая» модель, натренированная на большом корпусе (иногда говорят «на интернете»). У такой модели есть проблема галлюцинаций. Она способна искусно «придумать» последовательность, правильную с точки зрения языковых структур, но не имеющую ничего общего с объективным миром. Глобальная причина этого явления — большие корпусы данных с противоречивой информацией.

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

Данные из предметной области — чего не хватает LLM в её «голом» виде — мы подаём в форме отрывка текста. На основании него модель будет отвечать на вопрос, поэтому можно воспринимать его как контекст. Эта хитрость полно описана в коде у OpenAI. Основная идея в том, чтобы приказать модели сформулировать ответ на основании текста, который намного меньше всего корпуса. Например, на основании тома Л. Н. Толстого или раздела в Confluence. Уловка состоит в том, что раздел в Confluence — это легитимные предложения с точки зрения языка, поэтому им можно присвоить координаты слов из корпуса.

Статистический аспект работы

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

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

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

Например, для текста «Мама мыла раму. Мыла больше — было б лучше» на вопросы «Мыла?» и «Что мыла?» возможны ответы «Мыла раму» и «Мыла больше» в первом случае и однозначно «Мыла раму» во втором. Первый вопрос не позволяет модели определить часть речи слова «мыла» — глагол женского рода в прошедшем времени или существительное в родительном падеже. Добавление контекста решает эту неоднозначность.

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

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

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

Вторая задача — это из полученного набора слов создать правильные языковые структуры. Модель видела во время тренировки большое число легитимных предложений с выбранными словами в составе. На основании этого знания она производит грамматически согласованные предложения.

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

Интерфейс

Взаимодействие с языковой моделью происходит через строку запроса — prompt. Создание подходящих формулировок (prompt engineering) в обращении к модели — важная часть работы с интерфейсом. Разработчики OpenIA предлагают ограничить модели контекст с помощью такой формулировки: «Answer a question based on the context. Question: {question}; Context: {context}». Где question и context — переменные, которые пользователь интерфейса определяет произвольно.

«...if the question can't be answered based on the context, say „I don't know…“» — это важная уловка в формулировке запроса. Так мы приказываем модели честно говорить: «Не знаю», если вероятность предложения-ответа ниже заданного порога. Эта функция даёт нам возможность переадресовывать такого рода вопросы оператору, а затем запоминать его ответ. Это обогащает контекст (мы добавляем текст ответа в конец статьи Confluence), и в следующий раз на похожий по смыслу вопрос модель уже сможет ответить с достаточной уверенностью (вероятность предложения будет достаточно высокой).

Алгоритм

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

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

Шаг три: найти «ближайшие»  к вопросу токены в корпоративном контексте. На текущем этапе готов «смысл» ответа, и он представлен не обязательно связным набором слов, возможно даже излишним или недостающим с точки зрения языка. Он передаётся в переменной context. Это семантический поиск. OpenAI рекомендует использовать векторные базы данных в качестве «движка» для поиска.

На последнем этапе идёт обличение смысла в правильные языковые конструкции, выбираются сочетающиеся друг с другом слова для формирования предложений, а также добавляются местоимения, союзы и знаки препинания. Это делает самая большая языковая модель. Предыдущие шаги выполняются с помощью меньших моделей, например, text-embedding-ada. Так получается ответ без галлюцинаций и на основании заданного контекста.

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

Сомнение

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

Галлюцинирует ли модель на заданном контексте, объём которого существенно меньше (в десять миллионов раз), чем объём данных для тренировки (полтриллиона токенов)?

Теоретическая интуиция на этот счёт может быть следующей. С позиции координат токенов в k-мерном пространстве для галлюцинации на малом объёме данных нужно, чтобы в контексте встречались последовательности слов следующего характера: «мама мыла раму, стоя на карнизе на руках» и «мама тёрла свёклу, стоя на карнизе на руках». 

Вероятности появления пар слов «мыла раму» и «тёрла свёклу» в этих двух (на деле одном) контекстах одинаковые. Поэтому на вопрос «Что делала мама, стоя на карнизе?» мы можем получить два разных ответа. Вдобавок, если в тексте встречается сочетание слов «мама мыла свёклу перед тем, как её тёрла», то может быть сгенерирован ответ: «мыла свёклу». Однако мама не мыла свёклу, стоя на карнизе. Или мы не знаем, было ли это на карнизе. 

Это утрированный пример, чтобы продемонстрировать идею. В реальности дела обстоят чуть сложнее, потому что эмбеддинги (в отличие от представления слов буквами) вычислительно позволяют «смотреть» на контекст вокруг слова существенно дальше, за рамками одного предложения. Тем не менее случиться такая оказия теоретически может.

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

Результат хакатона

Следует сказать, что результат работы предложенного решения на очень малом контексте (несколько тысяч слов) из раздела Q&A с нашего сайта был отличным — 95% правильных ответов, включая ответы «Не знаю». Мы показали на втором дне хакатона телеграм-бот, который отвечал на вопросы с сайта и переадресовывал их оператору, если не был уверен в ответе. 

Каждый вопрос нам стоил примерно 8 рублей на момент написания статьи (10 американских центов) с возможностью удешевления x10. Это плата за  4097 токенов. В эту сумму входит обработка вопроса, выдержки из корпоративного контекста для ответа на вопрос, и сам ответ. 

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

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

Проверка решения

Этап I

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

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

Большая часть информации была представлена в таблицах. И это сыграло злую шутку. Результаты первого раунда были плачевными. Всего 10% правильных ответов, включая ответы «Я не знаю». 

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

Вместо последовательности «мама мыла раму» может получиться «мама мыла раму</td>», а “слово” «раму</td>» не всегда может быть разделено моделью на токены «раму» и «</td>». И даже когда может быть (у разных моделей разные словари токенов), то «</td>» начинает участвовать в построении предложений. Он сбивает вероятность появления слова после «раму», потому что «</td>» присутствует ещё в большом количестве предложений. 

Когда таких тегов несколько подряд, вероятности появления нескольких разных слов после тегов выравниваются, и модель начинает галлюцинировать. Может получиться «мама мыла раму</td></tr>стоя на карнизе» или «мама мыла раму</td></tr>стоя на ходулях» (запятые опущены для упрощения). Наличие двух тегов «</td></tr>» снижает различие между двумя вариантами.

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

В статьях на Confluence для разных продуктов использовались очень похожие формулировки. Различие между двумя продуктами могло быть только в заголовках статей с несущественными с точки зрения языковых последовательностей деталями в тексте. В статье из тысячи слов различие в нескольких предложениях — довольно слабое. И здесь я говорю не о скопированном слово в слово тексте. С точки зрения проверок на плагиат два текста могли быть 100% оригинальными.

Языковые модели «умеют» выделять синонимические группы. Эта способность достаётся нам, пользователям, «бесплатно». Так как модель оперирует статистическими вероятностями, в предложениях «мама мыла раму» и «мать мыла раму» слова «мама» и «мать» имеют одинаковую вероятность появления. Это с точки зрения структуры данных в модели позволяет мыслить о «матери» и «маме» как о синонимах.

Так, с учётом способности «отождествлять» синонимы, можно прийти к выводу, что модель понимает смысл. Абстрактные понятия в этом ключе — то, над чем модель выстраивает языковые конструкции. И с этой точки зрения различие текстов обеспечивается разностью смыслов, которые эти тексты передают. Для различия текстов недостаточно просто различных слов.

Когда в двух текстах встречаются похожие понятия в похожих ограниченных контекстах, то смыслы оказываются едва различимыми. Например, «мама мыла раму» и «мать чистила окно» по смыслу очень близки, несмотря на 100%-е различие в использованных словах. В наших текстах в Confluence описаны довольно похожие абстрактные понятия (в масштабах общего человеческого знания), и для их явного различия нужен контекст больший, чем был на момент первого раунда тестирования.

Этап II

Гипотезу о схожести контекстов для двух продуктов мы проверили быстро. Запустили программу на контексте, описывающем один продукт. Объём текста снизился всего в два раза, а неоднозначность в понятиях почти ушла. Результат в 95% правильных ответов, включая ответы «Я не знаю», подтвердил выбор направления дальнейших работ.

Этап III

Следующий этап мы посвятили описанию продуктов без противоречий внутри и перекрёстных смыслов между ними. Это довольно глубокая и вдумчивая работа, требующая времени. Поэтому мы и здесь пошли по пути быстрой проверки гипотезы. Достаточно было лишь разделить тексты на абзацы чуть более скрупулёзно, чем в начальной версии. Как оказалось, это эффективный способ для контекста среднего и чуть ниже среднего объёма (10 000 слов). 

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

Другими словами, абзац в описании одного продукта стал непохож по смыслу на абзац из другого продукта. Достигли этого за счёт смыслов, которые попали в абзац «а» продукта «А», но не попали в абзац «б» продукта «Б». До разделения прародители абзацев «а» и «б» имели больше одинаковых внешних связей и воспринимались по смыслу похожими. Можно сказать, что выделение абзацев позволяет сократить внешний (похожий) контекст, за счёт чего разница между двумя блоками текста становится более явной.

Результат — 95% правильных ответов.

Все этапы проверки подхода выше являются подмножеством рекомендованных OpenAI инструкций.

Два веронских рода — Сафети и Сесурити (Safety & Security)

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

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

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

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

В ответ на второй риск в качестве компромисса была идея использовать Faker или аналогичное решение для анонимизации персональных данных. Этот подход требует доработок и всё ещё оставляет возможность ошибиться. Поэтому первое, что мы взяли в проработку, — ультимативное решение по отказу от похода во внешнее API.

Этап IV

В последнее время в открытом доступе появилось несколько LLM, способных (по заявлениям разработчиков, ещё не способных в общем) составить конкуренцию ChatGPT в работе с ограниченным контекстом. Среди них LLaMa и Alpaca. Эти модели по лицензии имеют ограничение на коммерческое использование: the Software solely for your non-commercial research purposes, We emphasize that Alpaca is intended only for academic research and any commercial use is prohibited. Однако для исследовательских целей они доступны, и мы провели эксперимент и сравнили качество ответов ChatGPT и этих аналогов.

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

В частности, происходит умножение embeddings вопроса на веса модели. Это вычислительно и по памяти сложная операция в векторном пространстве размерности n, то есть в пространстве тензоров. Такие операции на современных GPU выполняются на специальных ядрах (tensor cores). Производители CPU тоже добавляют драйверы и инструкции для ускорения счёта.

С развитием CPU и подхода quantization (ускорения вычислений за счёт потери точности), а также с появлением портов на CPU инструкции LLM стало возможным запускать на относительно недорогом «железе».

Мы решили убедиться в этой возможности на собственном опыте и разделили испытания на этапы:

1. Проверка стоимости аренды оборудования в облаке для inference.

2. Оценка стоимости тренировки собственной LLM на основании предтренированной модели, на которую не наложены лицензионные ограничения.

Мы протестировали LLaMa 65B в режиме 4-bit integer quantization с установленным OpenBLAS на Ubuntu 20.04.6 LTS на процессоре Intel Ice Lake 8 vCPU, 128 GB RAM, 1 TB SSD. Цена аренды «железа» доступна по ссылке.

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

Компромиссный вариант LLaMa 13B работает быстрее (3 токена в секунду), но качество ответов требует дополнительных испытаний. Эта модель без дополнительной настройки отвечает хуже. Есть галлюцинации, но контекст специально под неё мы не готовили.

Вариант инфраструктуры с минимальным GPU сопоставим по стоимости, но достаточен по памяти для запуска только меньших моделей. Достаточная опция для запуска большой модели с 65B параметров стоит в разы дороже и измеряется тысячами долларов в месяц. Такая цена не вписывалась в нашу бизнес-модель.

Будущее развитие идеи

Для того чтобы обойтись меньшим «железом» и сэкономить на эксплуатации, можно создать свою модель меньшего размера на корпусе с включением корпоративного контекста. В смысле знания языка и способностей к логике, арифметике, подбору синонимов и перефразированию самые большие модели являются избыточными для нашей задачи. Единственной важной способностью остаются ответы на вопросы. Возможно, размера 7B или меньше будет достаточно, так как формулировка в ответах требует больше фактов, чем reasoning (умения обосновывать мнение).

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

Это вполне пригодный вариант из-за уникального сочетания цена/качество/лицензия. Цена тренировки такой модели открывает возможности использовать LLM в коммерческих целях с низкими затратами на эксплуатацию, не выходя за собственный сетевой контур.

Геополитические ограничения

OpenAI ограничивает список стран, в которых официально доступно использование API (You may use Services only in geographies currently supported by OpenAI. Россия, где юридически зарегистрирован «Метр квадратный», не входит в этот список. Поэтому мы не вправе использовать ChatGPT для нужд компании.

Все описанные эксперименты я проводил от собственного имени с персонального аккаунта в свободное от работы время в исследовательских целях, находясь в открытой OpenAI локации.

Импортозамещение

На фоне развития облачных провайдеров инфраструктуры вполне ожидаемым выглядит вывод «Яндексом» модели YandexGPT для использования в «Облаке». Если такое произойдёт, то с точки зрения безопасности это будет лучше, чем поход во внешнее API. Взаимодействие внутри виртуальной сети, как сейчас «Облако» предоставляет большинство своих сервисов, существенно усложняет злоумышленнику перехват и расшифровку сообщений. Вдобавок «Я.Облако» хранит все данные на территории РФ, что обеспечивает соблюдение закона о персональных данных.

Если «Яндекс» сделает тарификацию за токены, то это позволит гибко управлять бюджетом и не тратить деньги на тренировку модели, а также на «железо» для эксплуатации. На текущем этапе неясно, будут ли дорогие видеокарты в выделенном режиме утилизированы на 100%. 

Плавный ввод в промышленную эксплуатацию небольших фич, задействующих NLP на базе LLM, с полностью закрытыми рисками информационной безопасности и по гибкой цене позволит бизнесу “распробовать” подход. Следующим естественным шагом будет масштабирование и более широкое использование технологии, и переход на большие инфраструктурные мощности.

Выводы

Мы протестировали продуктовую и техническую составляющие гипотезы по автоматизации экспертной поддержки в компании. Экономический эффект выглядит оправданным с учётом расходов при тарификации по словам или при тренировке собственной LLM размером порядка нескольких миллиардов параметров (7B). Технические вызовы при реализации выглядят разрешимыми с учётом как уже существующих технологий (алгоритмы тренировки с открытым кодом), так и ожидаемых к выходу (YaGPT).

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

Если не страдать паранойей и не отрезать возможности похода во внешнее API — уже сейчас в бета-режиме на рынке есть готовые сервисы, не ограниченные условиями использования на территории РФ. Например, Sber GigaChat