Задача поиска ответов по внутренней документации
Одна из актуальных задач для компаний в сфере ИИ - это поиск и генерация ответов по внутренней документации. На первый взгляд кажется, что решение простое: 'скормить' документы большой языковой модели (LLM) и получать ответы. На практике же технические решения оказываются далеко не такими эффективными и качественными, как хотелось бы. Сейчас для работы с локальными документами доступны два основных подхода - RAG (Retrieval-Augmented Generation) и дообучение модели (fine-tuning). Оба подхода имеют свои преимущества и ограничения. В статье рассмотрим их как с теоретической, так и с практической точки зрения.
Задача с документацией в общем контексте задач ИИ
Чтобы понять, как задача поиска ответов во внутренней документации вписывается в общий контекст ИИ, стоит отметить, что это частный случай задачи Question Answering - одного из направлений обработки естественного языка (Natural Language Processing). NLP, в свою очередь, является одной из многих областей искусственного интеллекта. Обзор задач для ИИ и архитектур нейросетей я делал в статье на Хабре.
Для стандартных Question Answering задач часто достаточно хорошо составленных запросов к общей языковой модели (prompt engineering). Однако, когда речь заходит о внутренних корпоративных данных, этого уже недостаточно - ни одна готовая модель не содержит эту информацию.
Как отмечает компания OpenAI в своей статье, переход от prompt engineering к более сложным методам RAG и fine-tuning - это не линейный процесс, а многоэтапная оптимизация, которая в итоге приводит к комбинации разных подходов. На схеме представлена возможная траектория по решению и оптимизации задачи с документацией:
В данной статье мы рассматриваем RAG и fine-tuning, но prompt engineering не отбрасываем, а будем его использовать как базовый уровень для оценки качества решения.
Как выбрать LLM модель?
Прежде чем переходить к алгоритмам, давайте разберёмся где взять и как выбрать open-source модель для тестирования и разработки.
HuggingFace
Лучшая платформа для выбора моделей - это Hugging Face. Её можно назвать “GitHub-ом для ИИ-моделей” - здесь собрано более 1,5 млн готовых моделей для самых разных задач. Для выбора модели переходим в раздел Модели и фильтруем по типу задачи. Для создания системы RAG нам понадобятся модели из двух категорий:
Text Similarity - для генерации текстовых эмбеддингов (embeddings);
Text Generation - генерация ответов на запросы.
Также можно искать модели для всех остальных задач ИИ:
Чат-боты
Модели для выполнения инструкций (Instruct-модели)
Генерация кода на разных языках программирования и т.д.
Для начала экспериментов можно смело выбирать базовую модель, проверенную миллионам пользователей, а дальше уже экспериментировать с настройками и другими моделями. Для помощи в выборе подходящей модели также существуют рейтинги моделей (liderboards), например:
Open LLM Leaderboard (лидерборд от Hugging Face)
LMArena (лучшие чат-модели)
Embedding Leaderboard (лучшие эмбеддинг модели)
На какие параметры стоит обращать внимание при выборе модели?
Базовая или специализированная модель
Существуют базовые (foundation) модели (GPT, Gemini, LLaMA, Gemma и др.), которые служат основой для создания специализированных решений. Базовые модели обучены на объемных публичных данных и обладают широкими общими знаниями. Специализированные модели создаются для решения конкретных задач. Например, повышение точности ответов в узких доменах (медицина, юриспруденция) или соответствие корпоративному стилю коммуникации.
Качество ответов и объем модели
Самый важный параметр в модели, от которого зависит качество ответов и ее объем в памяти - это число параметров (весов).
Самые продвинутые open source модели на 32 миллиарда параметров требуют 64 Gb памяти на GPU, что для личных экспериментов, конечно, недостижимо;
Небольшие модели на 1.5 миллиарда поместятся в 4Gb, но качество их ответов не достаточно для применения в рабочих задачах;
Для моделей с 7 миллиардами параметров необходимо 16Gb.
Для личных экспериментов надо учитывать, что Google Colab бесплатно выделяет только 15Gb памяти на GPU. Расчеты показывают, что в него не загрузить напрямую ни одну модель на 7B. Но если использовать квантованные модели 4 bit, то они занимают около 10 Gb и помещаются в выделенный объем.
Оптимизация объема и производительности модели
Для оптимизации объема и скорости ответа (inference) необходимо выбирать модели, обработанные специальными алгоритмами:
Дистилляция (distillation) - перенос знаний в компактную модель, например, TinyLLaMA;
Прунинг (pruning) - удаление из модели избыточных параметров;
Квантование (quantization) - замена 32 или 16-битных чисел на 8 или 4-битные;
Использование специализированных форматов, например, GGUF (GPT-Generated Unified Format) для квантованных моделей.
Скорость ответов увеличивает применение моделей, состоящих из нескольких моделей Mixture of Experts;
Также важно учитывать размер контекстного окна (context length), которое может обработать модель за один запрос. Чем оно больше, тем с одной стороны лучше, т.к. в промпте можно передать больше данных, но с другой стороны скорость инференса будет меньше. Обычный размер контекста 4K-8K токенов, продвинутые модели используют 32K и более, есть новость даже о 10М контекстном окне в Llama 4.
Чтобы эффективно использовать контекстное окно модели, важно понимать, какой объём данных можно в него передать. Расчет такой: 1 токен - это примерно 0.75 английского слова, для русского слова требуется примерно 2 токена. Таким образом, в контекстное окно 4K поместится:
3K слов (6–8 страниц) английского текста
1.5K слов (3–4 страницы) русского текста
Лицензии
Модели распространяются под разными лицензиями (Apache 2.0, MIT, проприетарные). Поэтому лицензионные ограничения нужно учитывать при выборе модели (например, региональные ограничения Llama моделей от компании Meta).
Мультиязычность
Если нужна поддержка нескольких языков, то ставим соответствующий фильтр и выбираем модели, например, с русским языком: GigaChat, Llama 3, DeepSeek-V3.
После выбора модели LLM переходим к построению системы RAG.
RAG (Retrieval-Augmented Generation)
Метод RAG был представлен Facebook AI Research (FAIR) в публикации 2020 года и основан на отправке в LLM фрагментов документов в составе промпта для формирования ответа. Для того чтобы подход работал эффективно необходимо реализовать механизм поиска этих фрагментов в документах. Если поиск фрагментов не будет давать качественных результатов, то и от нейросети не стоит ждать чуда. Задача поиска информации решается алгоритмами классического анализа данных. Поэтому для построения системы RAG необходимо уметь использовать не только нейросети, но и классические ML (Machine Learning) алгоритмы.
Алгоритм создания RAG системы
1). Подготовка данных (Document Loading)
Корпоративные данные редко представляют собой упорядоченный текст. Это могут быть технические спецификации, юридические документы, регламенты и просто разрозненные файлы в разных форматах. На первом этапе документы экспортируются из внутреннего хранилища или из набора файлов. Из документов формируется текст, который очищается от лишней информации, например от схем и картинок. Конечно, схемы, графики и картинки могут нести полезную информацию и тоже анализироваться. Это называется мультимодальная обработка документов, но в данной статье мы ее не будем рассматривать.
2). Документы целиком не могут поместиться в контекст промпта, поэтому их надо разбить на смысловые фрагменты (chunks), чтобы уже их передавать в промпте. Существует много стратегий разбивки текста, но основные принципы следующие:
Чанки должны быть такого объема, чтобы несколько или несколько десятков фрагментов поместились в контекст промпта;
Чанки должны быть завершенными по смыслу фрагментами, например, предложеними или абзацами.
3). С помощью специальных алгоритмов из чанков формируются цифровые вектора (embeddings), в которых содержится смысл фрагментов.
4). Для удобства дальнейшего поиска вектора помещаются в векторную базу данных.
5). Реализуется Retrieval - компонент, который будет искать в базе похожие по смыслу вектора и возвращать набор текстовых чанков, которые соответствуют этим векторам.
На этом создание системы RAG закончено. Давайте посмотрим как она работает.
Алгоритм работы RAG системы
1). Пользователь задаёт вопрос, его текст преобразуется в векторное представление (embedding).
2). Созданный ранее Retrieval осуществляет поиск в базе данных и выбирает наиболее похожие по смыслу текстовые фрагменты.
3). Из найденных текстовых фрагментов формируется контекст промпта. Также в промпте обычно уточняется как именно использовать данные из контекста. Например, использовать для ответа только данные из контекста или разрешить языковой модели использовать свои общие знания.
4). Промпт передается в языковую модель.
5). LLM использует контекст и формирует ответ, который может иметь сложную структуру и служебную информацию. Также в ответе может содержаться несколько вариантов и оценки уверенности модели в их релевантности.
6). Поэтому необходим этап очистки ответа (postprocessing), во время которого происходит очистка от технических данных, выбор лучшего варианта, приведение к читаемому виду.
7). После этого пользователю возвращается финальный ответ.
Какие преимущества и ограничения есть у систем, реализующих RAG?
Преимущества RAG
RAG не требует сложной структуризации документов, достаточно разбить текст на осмысленные фрагменты (чанки).
RAG система может работать на внутренних серверах, что критично для соблюдения требований к безопасности и конфиденциальности данных.
При обновлении документации достаточно переиндексировать данные или обновить эмбеддинги, без затратного переобучения модели.
Для развертывания и поддержания системы нужны меньшие вычислительные ресурсы, чем для дооубучения моделей при fine-tuning.
Ограничения RAG
У промптов ограниченный объем контекста, поэтому в них невозможно передать всю доступную информацию.
Если передавать слишком много информации, то при росте объема контекста падает качество и скорость ответов.
Требуется реализация алгоритма поиска по документам, что при не эффективной реализации будет причиной пропуска важной информации или извлечения некорректных фрагментов.
Внутренние документы часто содержат чувствительные данные, что исключает использование облачных API. Развёртывание LLM приходится делать локально, что усложняет инфраструктуру компании.
Перейдем к рассмотрению файнтюнинга.
Fine-tuning
Fine-tuning - это дообучение модели под конкретные задачи, которые она изначально не выполняла. Это достигается путем корректировки её внутренних параметров (весов).
Для успешного fine-tuning-а нужен подготовленный набор данных - массив с размеченными данными в формате {"instruction": "...", "output": "..."}. Для обучения достаточно 500-1000 примеров на одну задачу.
Есть два типа файнтюнинга:
Классический файнтюнинг - осуществляет настройку всех параметров предварительно обученной модели. Но он слишком ресурсоёмкий и непрактичный для современных LLM.
Поэтому сейчас применяют оптимизированные алгоритмы, такие как PEFT (Parameter-Efficient Fine-Tuning). Суть PEFT заключается в том, что большая часть весов модели остаётся без изменений (замороженной), а дообучению подвергается лишь небольшое количество параметров под конкретную задачу. Существует несколько методов PEFT, самый популярный — LoRA (Low-Rank Adaptation), а для квантованных моделей — QLoRA.
Алгоритм создания и работы fine-tuning системы
Для того, чтобы разработать и развернуть систему fine-tuning необходимо сделать следующие шаги:
1). Собрать данные, сформировать датасет в определенном формате.
2). Выбрать базовую open-source модель, скачать и загрузить ее в инфраструктуру, в которой будет производится fine-tuning. Для этого необходима графическая карта с достаточным объемом памяти.
3). Применить fine-tuning с выбранной оптимизацией, например LoRA и сохранить адаптированную модель для дальнейшего использования в стандартной инфраструктуре компании.
4). Пользователь задает вопрос, система формирует промпт.
5). Промпт передается в донастроенную LLM.
6). LLM формирует ответ, который может иметь сложную структуру и служебную информацию. Также в ответе может содержаться несколько ответов и оценки уверенности модели в их релевантности.
7). Поэтому необходим этап очистки ответа (postprocessing), во время которого происходит очистка от технических данных, выбор лучшего варианта ответа, приведение к читаемому виду.
8). После этого пользователю возвращается финальный ответ.
Какие преимущества и ограничения есть у систем файнтюнинга?
Преимущества fine-tuning
LLM дообучается на внутренней документации, что повышает её релевантность в специализированных вопросах.
Fine-tuning система лучше справляется с генерацией специфического стиля текста.
Информация не передаётся в промптах, т.к. зашита в весах модели, что повышает конфиденциальность данных.
Инференс быстрее, чем в RAG, так как fine-tuning система не требует предварительного поиска и работает с более короткими промптами.
Ограничения fine-tuning
Сбор и подготовка обучающего датасета трудоёмки и критически важны для качества модели.
Затраты на вычислительные ресурсы больше чем у RAG, т.к.процесс обучения требует наличия графических карт.
Необходимость регулярного обновления модели – при изменении документации или выходе новой версии базовой LLM модели требуется повторное переобучение.
Высокий порог входа – требует привлечения ML-инженеров с экспертизой в дообучении языковых моделей.
При развертывании LLM в облаке есть риск утечки данных, "зашитых" в весах модели.
Практика с системой RAG
Перейдём к практике. В этой статье мы не будем строить промышленную систему, как в моей статье “Мозг промышленного масштаба или как воплотить мечту в реальность?”. Вместо этого сделаем упрощённый пример, который можно запустить в Google Colab.
Выбор модели для RAG
Мы возьмем одну из самых популярных на сегодня моделей — Qwen 2.5 с 7B параметрами, квантованную в 4-bit, т.к.
7 миллиардов параметров достаточно для большинства NLP-задач.
4-bit квантование позволяет уместиться в ограничения памяти Google Colab.
У Unsloth есть готовые примеры использования.
Данные для RAG
В нашем эксперименте возьмем один pdf файл с актуальным ГОСТ-ом “РАЗРАБОТКА БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ”, в нем описаны требования к реализации безопасного программного обеспечения. По структуре и содержанию документ аналогичен внутренним регламентам IT-компаний, поэтому он хорошо подходит для демонстрации работы системы.
Библиотека LangChain
Для реализации взаимодействия с LLM и построения RAG систем существует библиотека LangChain. Она включает в себя все необходимые инструменты:
Document loaders - загрузчики документов в разных форматах;
Splitters - разбивка текста на фрагменты;
Embedding models - коннекторы к популярным моделям создания цифровых векторов из текста;
Vector stores - коннекторы к векторным базам данных;
Retrievers - получение текстовых фрагментов из базы данных в соответствии с запросом;
Prompt Templates - формирование запросов к языковым моделям;
LLM - коннекторы к языковым моделям;
Output parsers - обработка ответов LLM и представление их пользователю.
Формирование эмбедингов
В нашем примере мы будем использовать модель LaBSE “Language-agnostic BERT sentence embedding” от Google, урезанную для двух языков: русского и английского. Эту модель (cointegrated/LaBSE-en-ru) можно найти на HuggingFace.
Векторная база данных
В нашем эксперименте будем использовать FAISS - высокоэффективную дазу данных для векторного поиска, разработанную FAIR - той же компанией, что предложила концепцию RAG. Есть и другие решения для работы с векторными базами данных:
Запуск примера с RAG в Google Colab
Ноутбук с полной реализацией RAG системы доступен в моем GitHub репозитории;
PDF-файл с ГОСТ-ом загружаем в папку Google Colab с именем 'ГОСТ Р 56939-2016 - безопасность ПО.pdf':
В меню: Runtime / Change runtime type устанавливаем:
Runtime type: "Python 3";
Hardware accelerator: "T4 GPU";
Выполняем все ячейки ноутбука;
Результаты работы RAG
В примере задаются два вопроса. Один - по информации из документа, второй - на общие знания. В таблице для сравнения собраны ответы на эти вопросы трех моделей:
Нашей построенной системы на основании Qwen 2.5-7B с использованием RAG.
Базовая версия модели Qwen 2.5-7B без RAG.
Для проверки качества спрашиваем у DeepSeek R1.
LLM | Вопрос / Ответ по документу: "Что такое безопасное программное обеспечение?" |
Qwen 2.5-7B с использованием RAG | Безопасное программное обеспечение - это программа или система, которая прошла все необходимые проверки и тестирование для выявления возможных ошибок, уязвимостей и потенциально опасных действий, чтобы гарантировать ее надежность, стабильность и сохранность данных пользователя |
Базовая Qwen 2.5-7B | Программное обеспечение, которое не содержит уязвимостей, которые могут быть использованы для получения несанкционированного доступа к компьютеру или сети. |
Для проверки качества спрашиваем у DeepSeek R1 | Безопасное ПО — это программы, защищённые от кибератак, утечек данных и несанкционированного доступа. Оно должно: - Защищать данные (шифрование, контроль доступа) - Устойчиво к взлому (закрывает уязвимости типа SQL-инъекций) - Соответствовать стандартам (ГОСТ, ISO 27001) |
LLM | Вопрос / Ответ не по документу: "Какое расстояние до луны?" |
Qwen 2.5-7B с использованием RAG | Я не знаю! |
Базовая Qwen 2.5-7B | 384 400 км. |
Для проверки качества спрашиваем у DeepSeek R1 | Расстояние до Луны: - Среднее: 384 400 км - Ближайшее (перигей): ~363 300 км - Дальнее (апогей): ~405 500 км |
Выводы из ответов
На основе полученных результатов можно сделать следующие выводы:
Система с RAG успешно справляется со своей задачей:
Корректно отвечает на вопросы, используя информацию из документа.
Если вопрос выходит за рамки документа, система, следуя промпту, честно отвечает "Я не знаю!" и не генерирует ложные данные.
LLM без RAG дает более общие ответы, опираясь на свои внутренние знания, которые, естественно, не отражают содержимое документа.
DeepSeek R1 предсказуемо демонстрирует более высокий уровень интеллекта по сравнению с Qwen.
Практика с системой fine-tuning
Основой для практики послужил стандартный пример файнтюнинга от Unsloth. Другие примеры можно найти в их официальной документации.
В примере используется уже знакомая нам модель Qwen 2.5 с 7 миллиардами параметров, квантованная до 4 бит.
Для дообучения применяется искусственно сгенерированный датасет Alpaca-Cleaned, который ранее использовался для тренировки модели Alpaca LLM. Его формат позволяет адаптировать его для файнтюнинга других языковых моделей.
Запуск примера в Google Colab
Ноутбук с примером файнтюнинга доступен в моём GitHub-репозитории.
Запуск аналогичен настройке RAG-системы, описанной ранее.
После запуска потребуется несколько минут ожидания, т.к. даже для небольшого файнтюнинга требуются значительные вычислительные мощности.
Результат работы fine-tuning
В примере задается один вопрос к трем LLM: "Дай три совета чтобы оставаться здоровым". Ответы собраны в таблицу:
LLM | Ответ |
Модель Qwen 2.5-7B с fine-tuning | 1. Правильное питание: Включайте в свой рацион больше овощей, фруктов, цельнозерновых продуктов и ограничьте употребление сахара, жиров и соли. Также важно пить достаточное количество воды. 2. Физическая активность: Включайте в свой график регулярные физические упражнения, такие как ходьба, бег, плавание или йога. Это поможет укрепить мышцы, сердце и улучшить общее здоровье. 3. Сон: Убедитесь, что вы получаете достаточный сон. Взрослым рекомендуется 7-9 часов сна в сутки. Сон помогает восстановить организм, улучшить иммунитет и уменьшить стресс. |
Qwen 2.5-7B без fine-tuning | 1. Употреблять здоровую пищу: включать в свой рацион больше фруктов, овощей и цельнозерновых продуктов. 2. Вести активный образ жизни: заниматься спортом или ходить пешком хотя бы несколько раз в неделю для поддержания хорошего самочувствия. 3. Спать достаточно. |
1. Питайтесь правильно – больше овощей, фруктов, белка, меньше сахара и фастфуда. Пейте воду. 2. Двигайтесь – 30 минут активности в день (ходьба, спорт, зарядка). 3. Спите 7–9 часов и контролируйте стресс – медитация, отдых, режим. |
Выводы из результатов
После дообучения модель сохранила базовые знания, но стала давать более детализированные ответы. Пример: конкретное указание на 7-9 часов сна вместо общих рекомендаций.
Модель DeepSeek R1 демонстрирует аналогичные Qwen знания в этом вопросе про здоровье.
Заключение
Существует всего два способа 'накормить' модель документами - RAG и fine-tuning. Оба подхода обладают своими преимуществами и ограничениями.
Для выбора наилучшего решения необходимо учитывать много факторов: особенности задачи, структуру данных, желаемый уровень интеллектуальности ответов, требования безопасности, наличие вычислительных мощностей и т.д.
'Накормить' модель данными просто, но что ей понравится предугадать невозможно, нужно пробовать!
Дополнительная информация для изучения
Курсы по AI от Aleron автора канала Data Feeling без воды, все по делу:
Как разработать работающее решение на современных языковых моделях: Создаем свой AI-продукт на базе ChatGPT и других LLM
Быстрый старт в разработке с использованием ИИ AI-программирование | Экспресс-курс
Обзорная статья про проекты с LLM + хороший список дополнительной литературы: Что нужно знать перед внедрением LLM
Практические советы по оптимизации RAG: Борьба с низким качеством ответов при экономии GPU
Запуск LLM локально: Обзор Open Source LLM и их запуск локально
Установка DeepSeek R1 локально: Как запустить DeepSeek R1 на своем ПК
Статья для размышлений о перспективах AGI (Artificial General Intelligence) и развития ИИ в 2025: Сэм Альтман знает, как достичь AGI. Я тоже, и сейчас расскажу
