Важные паттерны в создании продуктов на основе генеративного ИИ

По мере того как программные продукты, использующие технологии генеративного искусственного интеллекта, переходят из стадии прототипирования в продакшн, выявляется ряд повторяющихся паттернов. Большие языковые модели (LLM) требуют адаптации, чтобы предоставлять информацию, выходящую за пределы общего и статичного обучающего набора. В большинстве случаев эту проблему решает Retrieval‑Augmented Generation (RAG, «генерация с поисковым дополнением»), хотя базовый подход RAG имеет свои ограничения и требует дополнительных техник для их устранения. Если же RAG оказывается недостаточно эффективным, Fine‑Tuning становится обоснованным шагом.

Проблемы перехода генеративного ИИ из прототипа в продакшн

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

• галлюцинации (генерация убедительных, но ошибочных или полностью выдуманных ответов),

• отсутствие встроенных ограничений на данные (LLM не различает, какие данные могут или не могут быть использованы в конкретном контексте),

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

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

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

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

Прямое взаимодействие с LLM (Direct Prompting) 

Direct Prompting — передача пользовательских запросов напрямую в языковую модель

Базовый способ взаимодействия с LLM — это позволить пользователю напрямую вводить запросы (промпты) и получать ответы от модели без каких‑либо дополнительных слоёв обработки. Такой опыт взаимодействия могут предлагать сами поставщики LLM.

Когда использовать Direct Prompting

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

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

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

Direct Prompting — мощный инструмент, но им редко можно ограничиться. Наш опыт показывает, что для успешного применения LLM на практике требуется ряд дополнительных механизмов, компенсирующих ограничения и проблемы, присущие прямому взаимодействию с моделью.

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

Эмбеддинги (Embeddings)

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

Представьте, что вы создаёте приложение для организации питания. Пользователи могут делать снимки своих блюд и получать персонализированные рекомендации и альтернативные варианты на основе их предпочтений и образа жизни. Даже простой снимок яблока, сделанный на телефон, содержит огромный объём данных. Например, изображение с разрешением 1280 × 960 пикселей включает около 3,6 миллиона значений (1280 × 960 × 3 для RGB). Анализ таких данных в исходном виде затруднителен даже для самых мощных моделей.

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

Пример векторного представления изображения

Глубокие нейросети создают более качественные векторные представления изображений по сравнению с традиционными методами. Поэтому мы будем использовать модель CLIP, а именно clip‑ViT‑L-14, для их генерации.

# python
from sentence_transformers import SentenceTransformer, util
from PIL import Image
import numpy as np

model = SentenceTransformer('clip-ViT-L-14')
apple_embeddings = model.encode(Image.open('images/Apple/Apple_1.jpeg'))

print(len(apple_embeddings)) # Dimension of embeddings 768
print(np.round(apple_embeddings, decimals=2))

При запуске этой модели мы получим длину векторного представления, а затем сам вектор:

768
[ 0.3   0.25  0.83  0.33 -0.05  0.39 -0.67  0.13  0.39  0.5  # and so on...

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

Для нашего приложения мы используем косинусное сходство, значение которого варьируется от -1 до 1:

Имея два эмбеддинга, можно вычислить степень их сходства с помощью косинусного сходства.

def cosine_similarity(embedding1, embedding2):
  embedding1 = embedding1 / np.linalg.norm(embedding1)
  embedding2 = embedding2 / np.linalg.norm(embedding2)
  cosine_sim = np.dot(embedding1, embedding2)
  return cosine_sim

Для проверки этой гипотезы возьмём четыре изображения:

Сравним яблоко 1 с остальными изображениями:

В реальных условиях могут быть разные вариации: что если яблоки будут разрезаны? Что если они будут лежать на тарелке? Что если это будут зелёные яблоки? Или снимок будет сделан сверху? В идеале эмбеддинг модель должна учитывать смысловые связи между объектами и эффективно их представлять, размещая схожие изображения ближе друг к другу.

Идеально было бы визуализировать эмбеддинги, чтобы проверить, как они группируются в кластеры. Поскольку модели машинного обучения работают с сотнями измерений, для визуализации нам нужно уменьшить размерность. Это можно сделать с помощью t‑SNE или UMAP, чтобы отобразить эмбеддинги в двумерном или трёхмерном пространстве.

Вот удобный метод T‑SNE для выполнения этой задачи.

from sklearn.manifold import TSNE
tsne = TSNE(random_state = 0, metric = 'cosine',perplexity=2,n_components = 3)
embeddings_3d = tsne.fit_transform(array_of_embeddings)

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

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

Но как этот подход применим к документам? По сути, разница минимальна. Фрагменты текста, страницы документов, изображения и таблицы — всё это просто данные. Модель эмбеддингов способна обработать несколько страниц текста и преобразовать их в векторное пространство для дальнейшего сравнения. Причём такой подход не просто учитывает отдельные слова, а анализирует их смысл в контексте. Например, фраза «Mary had a little lamb» для рассказчика детских стихов означает одно, а для ресторатора — совсем другое. Модели, такие как text‑embedding-3-large и all‑MiniLM‑L6-v2, способны улавливать сложные семантические связи между словами и выражениями.

Эмбеддинги в LLM

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

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

Вернёмся к примеру с приложением для питания. Когда пользователь делает снимок блюда и задаёт вопрос: «Полезна ли эта еда?»

Модель выполняет следующие логические шаги для генерации ответа:

1. На входном уровне токенизатор преобразует текст запроса и изображение в эмбеддинги.

2. Далее эмбеддинги передаются во внутренние слои LLM, также называемые слоями внимания (attention layers), которые выделяют ключевые особенности входных данных. Если модель обучена на данных о питании, разные слои внимания анализируют запрос с точки зрения пользы для здоровья и питательной ценности.

3. Выходной слой использует информацию из последнего слоя внимания для генерации ответа.

Когда использовать эмбеддинги

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

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

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

В начале этого обсуждения мы говорили об ограничениях Direct Prompting. Эмбеддинги помогают индексировать большие объёмы неструктурированных данных.

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

Один из способов адаптации модели к конкретной задаче или области — тонкая настройка (или Fine‑tuning). Проблема в том, что этот процесс очень дорогой и ресурсозатратный, а потому далеко не всегда является оптимальным решением.

В большинстве ситуаций наиболее эффективный подход — Retrieval‑Augmented Generation (RAG), который мы сейчас и рассмотрим.

Retrieval-Augmented Generation (RAG)

RAG — это извлечение релевантных фрагментов документов и включение их в запрос LLM.

Распространённая метафора для LLM — младший исследователь. Это человек, который хорошо образован, начитан, умеет красиво формулировать мысли, но не обладает глубокими знаниями в конкретной области. Подобно излишне самоуверенному и при этом некомпетентному человеку он, вместо того чтобы признать пробелы в своих знаниях, скорее придумает правдоподобный, но неточный ответ. При использовании RAG мы задаём такому «исследователю» вопрос, но дополнительно предоставляем ему набор релевантных документов, которые он должен изучить перед тем, как ответить.

RAG оказывается эффективным подходом при использовании LLM для работы с узкоспециализированными знаниями. Однако он сталкивается с классическими проблемами информационного поиска (IR) — как определить, какие документы передать в модель?

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

Процесс работы RAG можно разбить на несколько этапов:

1. Создание индекса. Документы разбиваются на небольшие фрагменты, для которых генерируются векторные представления (эмбеддинги). Эти эмбеддинги вместе с соответствующими текстами сохраняются в векторную базу данных.

2. Обработка пользовательского запроса. Запрос пользователя преобразуется в эмбеддинг, который затем используется для поиска ближайших фрагментов в векторном хранилище с помощью метода приближённого поиска ближайших соседей (ANN Search).

3. Формирование запроса к LLM. Найденные текстовые фрагменты вставляются в RAG‑шаблон вместе с оригинальным запросом пользователя, после чего полученный текст передаётся в LLM для генерации ответа.

Шаблон запроса для RAG

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

Шаблон промпта для RAG может выглядеть следующим образом:

User prompt: {{user_query}} 

Relevant context: {{retrieved_text}} 

Инструкция: 

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

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

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

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

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

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

Альтернативный способ расширения знаний LLM — Fine Tuning, который мы рассмотрим позже. Однако Fine Tuning требует значительных вычислительных ресурсов, поэтому в большинстве случаев RAG оказывается более эффективным решением.

RAG на практике

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

Один из примеров, который стоит отметить, — создание поисковой системы для крупной международной компании в сфере биологических наук. Исследователям этой компании регулярно требуется анализировать архивные отчёты по разным соединениям и видам организмов. Эти исследования проводились в течение двух десятилетий, в результате чего было накоплено 17 000 отчётов, каждый из которых содержит тысячи страниц с текстами и таблицами. Мы разработали чат‑бота, который позволил исследователям находить релевантную информацию в этом массиве неструктурированных данных.

До внедрения RAG ответ на сложные вопросы требовал ручного изучения множества PDF‑документов, что занимало от нескольких дней до нескольких недель. Теперь исследователи могут использовать многошаговые (multi‑hop) запросы через чат‑бота и находить нужную информацию всего за несколько минут. Кроме того, мы добавили визуализации, чтобы упростить анализ полученных данных.

Это был успешный кейс использования RAG, но для перехода от proof‑of‑concept к полноценному продакшен‑решению нам пришлось решить ряд серьёзных проблем, связанных с его применением.

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

Тонкая настройка (Fine-tuning)

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

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

В большинстве случаев проблему решает Retrieval‑Augmented Generation (RAG), предоставляя LLM доступ к актуальной информации. Однако бывают ситуации, когда контекст, предоставленный RAG, слишком узок, и требуется модель, обладающая глубоким пониманием всей предметной области, а не только конкретных документов.

Тонкая настройка (Fine‑tuning) позволяет дообучить предобученную LLM на специально отобранном датасете для конкретной задачи. В процессе обучения модель генерирует предсказанный результат, который затем сравнивается с известным правильным ответом для оценки её точности.

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

В процессе тонкой настройки важную роль играют гиперпараметры — скорость обучения (learning rate), размер батча (batch size), количество эпох (number of epochs), оптимизатор (optimizer) и коэффициент регуляризации (weight decay). Корректная настройка этих параметров помогает найти баланс между качеством генерации и устойчивостью модели.

Методы тонкой настройки

Существует несколько способов тонкой настройки LLM — от готовых API коммерческих LLM до самостоятельного обучения на своих серверах. Этот список не является исчерпывающим, но представляет основные подходы.

Практический пример

В рамках проекта Opennyai мы разработали модель Aalap, представляющую собой тонко настроенную Mistral 7B, предназначенную для решения юридических задач в судебной системе Индии.

Из‑за ограниченного бюджета и небольшого объёма обучающих данных мы выбрали LoRA Fine‑Tuning. Целью исследования было определить, насколько можно адаптировать базовую Mistral‑модель к специфике индийского права.

Наша доработанная модель показала лучшие результаты, чем GPT-3.5-turbo, в 31% тестов.

Подробнее о проекте Aalap можно прочитать в этой статье. Мы также опубликовали данные и модель на Hugging Face.

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

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

Когда использовать Fine‑tuning

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

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

Если корректировка промптов не даёт нужных результатов, следующим шагом будет Retrieval‑Augmented Generation (RAG), который позволяет расширить знания модели, предоставляя ей актуальные данные из внешних источников. В большинстве случаев, с которыми мы работали, правильно реализованный RAG давал удовлетворительные метрики.

Fine‑tuning рассматривается только в том случае, если даже после оптимизации RAG метрики качества остаются неудовлетворительными.

В случае модели Aalap Fine‑tuning был необходим, так как требовалась модель, способная работать в специфике индийской правовой системы. Этого нельзя было достичь просто с помощью промптов или загрузки документов в RAG — модель требовала глубокой адаптации к терминологии и логике правоприменения, что потребовало переобучения модели с учётом специализированных данных.

Другие паттерны (Evals, Guardrails, Hybrid Retriever, Reranker) рассмотрим во второй части.

Тех, кто хочет глубже понять, как правильно оценивать и улучшать модели генеративного ИИ на практике, приглашаем на открытый урок 3 марта «Основы A/B тестирования для выбора ML модели».

Также рекомедуем обратить внимание на уроки по темам:

• «Zero-Shot подходы в компьютерном зрении»
  Подробнее

• «Алгоритм DQN — учим нейросети принимать решения»
  Подробнее

Полный список всех бесплатных онлайн-уроков смотрите в календаре.