Статья Как создать RAG-базу из технических книг

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

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

В этой статье разберём:

• как устроен RAG;
• чем RAG отличается от обучения модели;
• как подготовить технические книги;
• зачем нужны OCR, чанки и embedding-модель;
• как создать базу знаний в Open WebUI;
• какие параметры использовать для локальной нейросети;
• как проверить качество поиска;
• почему модель иногда «не видит» загруженные книги.

---

Что такое RAG​

RAG состоит из двух основных этапов:

1. Поиск информации в базе документов.
2. Генерация ответа языковой моделью с использованием найденного текста.

Упрощённо процесс выглядит так:

Технические книги
        ↓
Извлечение текста
        ↓
Очистка и разбиение на фрагменты
        ↓
Преобразование фрагментов в векторы
        ↓
Сохранение в векторную базу
        ↓
Вопрос пользователя
        ↓
Поиск подходящих фрагментов
        ↓
Передача фрагментов языковой модели
        ↓
Ответ на основе найденных материалов

Например, пользователь задаёт вопрос:

Какие поля содержит структура EPROCESS в Windows?

Система не передаёт модели все загруженные книги целиком. Вместо этого она:

1. преобразует вопрос в числовой вектор;
2. ищет похожие по смыслу фрагменты;
3. выбирает несколько наиболее подходящих отрывков;
4. добавляет их в контекст нейросети;
5. просит модель сформировать ответ.

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

---

RAG не обучает нейросеть​

Важно понимать, что загрузка книг в RAG-базу не изменяет веса языковой модели.
Книги не становятся частью Qwen, Llama, Mistral или другой модели. Они сохраняются отдельно и используются только во время обработки запроса.

Это принципиальное отличие от LoRA и полноценного дообучения.

Технология	Что происходит
RAG	Модель получает найденные фрагменты документов во время запроса
LoRA	Создаётся дополнительный адаптер, изменяющий поведение модели
Fine-tuning	Изменяются веса или часть весов модели
Full Context	Документ целиком передаётся в контекст каждого запроса

Преимущества RAG:

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

Недостатки тоже существуют:

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

---

Из каких компонентов состоит RAG​

Для создания полноценной базы знаний потребуются следующие компоненты.

1. Источники​

Это могут быть:

• PDF-книги;
• EPUB;
• DOCX;
• Markdown;
• HTML;
• текстовые файлы;
• документация проектов;
• исходный код;
• научные статьи;
• руководства производителей;
• внутренние инструкции.

2. Обработчик документов​

Он извлекает текст, структуру, таблицы и заголовки.
Популярные варианты:

• Docling;
• Apache Tika;
• PyMuPDF;
• Unstructured;
• OCRmyPDF;
• Tesseract OCR;
• специализированные OCR-сервисы.

3. Разделитель текста​

Большая книга разбивается на небольшие фрагменты — чанки.

4. Embedding-модель​

Embedding-модель преобразует текст в набор чисел — вектор.

5. Векторная база​

В ней хранятся:

• векторы;
• текстовые фрагменты;
• названия книг;
• номера страниц;
• главы;
• дополнительные метаданные.

6. Языковая модель​

Например:

• Qwen Coder;
• Qwen Instruct;
• Llama;
• Mistral;
• Kimi;
• GPT;
• Claude.

Языковая модель получает найденные фрагменты и формирует итоговый ответ.

---

Этап 1. Подготовка библиотеки​

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

Windows Internals/
├── Windows Internals. Part 1.pdf
├── Windows Internals. Part 2.pdf
├── Windows Kernel Programming.pdf
└── Windows Native API.pdf

Или:

Linux Kernel/
├── Linux Kernel Development.pdf
├── Linux Device Drivers.pdf
├── Understanding the Linux Kernel.pdf
└── Linux Kernel Documentation/

Лучше создавать отдельную базу для каждой темы:

• Windows Internals;
• Linux Kernel;
• разработка драйверов;
• анализ вредоносного ПО;
• сетевые технологии;
• Docker и Kubernetes;
• реверс-инжиниринг;
• веб-безопасность;
• языки программирования.

Так поиск будет получать меньше посторонних результатов.

Не смешивайте всё в одной базе​

Если загрузить в одну коллекцию книги по Windows, PHP, Cisco, биологии и бухгалтерии, поиск всё равно будет работать, но качество может снизиться.
Лучше использовать несколько тематических баз:

Windows Internals
Linux Kernel
Malware Analysis
Reverse Engineering
Network Security
Docker and Kubernetes
Python Development
C and C++ Development

При необходимости модель сможет обращаться сразу к нескольким базам.

---

Этап 2. Проверка PDF​

PDF может содержать:

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

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

Признаки проблемного PDF​

После копирования текста могут появляться:

W i n d o w s  K e r n e l

или:

������� ���������

или строки в неправильном порядке:

третья колонка
первая колонка
вторая колонка

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

---

Этап 3. Извлечение текста​

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

PDF
 ↓
Docling
 ↓
Структурированный документ
 ↓
Markdown или JSON
 ↓
Разбиение на чанки

Docling особенно полезен для документов, в которых присутствуют:

• многоуровневые заголовки;
• таблицы;
• подписи к изображениям;
• колонки;
• списки;
• программный код;
• сложная структура страниц.

Однако даже хороший обработчик не гарантирует идеального результата. После обработки необходимо проверить извлечённый текст.

Что проверить​

Откройте предварительный просмотр документа и найдите:

• название первой главы;
• несколько абзацев из середины книги;
• фрагмент программного кода;
• таблицу;
• текст на русском языке;
• текст на английском языке;
• последнюю главу.

Проверьте, что:

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

---

Этап 4. Очистка документов​

Перед индексацией желательно удалить лишние элементы:

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

Например, вместо такого фрагмента:

Windows Internals — Seventh Edition
Page 523
Chapter 8

Процесс в Windows представлен объектом...
Windows Internals — Seventh Edition

желательно получить:

# Chapter 8. Processes

Процесс в Windows представлен объектом...

Чем чище исходный текст, тем лучше работает поиск.

---

Этап 5. Разбиение текста на чанки​

Нельзя сохранять книгу как один огромный фрагмент. Документ необходимо разделить на небольшие части.
Такой фрагмент называется chunk, или чанк.
Пример:

Книга: Windows Internals
Глава: Processes
Страница: 123
Текст: Каждый процесс Windows представлен исполнительным объектом процесса...

Следующий чанк может содержать продолжение раздела.

Почему размер чанка важен​

Слишком маленькие чанки теряют смысл.
Например:

Структура содержит следующие поля:

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

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

Перекрытие чанков​

Для сохранения связи между соседними фрагментами используется Chunk Overlap.
Например:

Chunk 1:
A B C D E

Chunk 2:
D E F G H

Часть D E присутствует в обоих чанках. Благодаря этому предложение или определение не теряется на границе разделения.

Стартовые параметры​

Для локальной модели с небольшим контекстом:

Параметр Значение
Text Splitter token
Chunk Size 1000
Chunk Overlap 100
Top K 3–5
Markdown Header Splitting включить
Full Context выключить


Для модели с контекстом от 16 000 до 32 000 токенов:

Параметр Значение
Text Splitter token
Chunk Size 1200–1500
Chunk Overlap 150–200
Top K 5–10
Markdown Header Splitting включить


Для модели с контекстом от 32 000 токенов:

​

Параметр Значение
Text Splitter token
Chunk Size 1500–2000
Chunk Overlap 200
Top K 10–20
Markdown Header Splitting включить

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

---

Этап 6. Создание векторов​

После разбиения каждый чанк передаётся embedding-модели.
Embedding-модель превращает текст в массив чисел:

"Процесс Windows содержит объект EPROCESS"

условно преобразуется в:

[0.128, -0.442, 0.039, 0.771, ...]

Это не шифрование и не сжатый текст. Числа описывают смысловое положение фрагмента в многомерном пространстве.
Похожие по смыслу тексты получают близкие векторы.
Например:

Как устроен процесс Windows?

и:

Структура ядра, представляющая процесс в Windows

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

---

Как выбрать embedding-модель​

Embedding-модель влияет на качество поиска сильнее, чем многие предполагают.
Для простого локального запуска можно использовать:

sentence-transformers/all-MiniLM-L6-v2

Преимущества:

• небольшая;
• быстро работает;
• потребляет мало памяти;
• подходит для первоначального тестирования.

Для более серьёзной локальной базы можно рассмотреть:

nomic-embed-text
mxbai-embed-large
BAAI/bge-m3

При выборе необходимо учитывать:

• поддержку русского языка (BAAI/bge-m3 поддерживает русский язык);
• поддержку английского языка;
• качество работы с техническими терминами;
• размер модели;
• потребление RAM или VRAM;
• скорость индексации;
• размер генерируемых векторов;
• максимальную длину входного текста.

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

Нельзя менять embedding-модель без переиндексации​

Если документы были проиндексированы одной моделью, а пользовательские запросы преобразуются другой, поиск станет неправильным.
После смены embedding-модели необходимо:

1. удалить старые векторы;
2. повторно обработать документы;
3. создать новые embeddings;
4. заново проверить контрольные вопросы.

Исходные PDF при этом можно оставить.

---

Этап 7. Векторная база​

Созданные векторы необходимо где-то хранить.
Для этого применяются векторные базы данных:

• ChromaDB;
• Qdrant;
• Milvus;
• pgvector;
• Elasticsearch;
• OpenSearch.

Для небольшой локальной установки часто достаточно встроенной базы Open WebUI.
Для крупной библиотеки, нескольких пользователей или отдельного RAG-сервиса можно использовать Qdrant или pgvector.
Один объект в векторной базе может выглядеть примерно так:

{
  "id": "windows-internals-7-part1-page-123-chunk-4",
  "vector": [0.128, -0.442, 0.039],
  "text": "Каждый процесс Windows представлен исполнительным объектом...",
  "metadata": {
    "book": "Windows Internals",
    "chapter": "Processes",
    "page": 123,
    "language": "en"
  }
}

Метаданные позволяют показать пользователю источник ответа:

Источник: Windows Internals, глава Processes, страница 123

---

Создание базы знаний в Open WebUI​

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

Шаг 1. Настройте обработку документов​

Откройте административные настройки документов.
Проверьте:

• выбранный Content Extraction Engine;
• адрес Docling или другого обработчика;
• embedding-модель;
• размер чанков;
• overlap;
• Top K;
• разрешённые расширения файлов;
• лимит размера загружаемых файлов.

Для технических PDF в качестве обработчика можно использовать Docling.

Шаг 2. Выберите embedding-модель​

Для первоначального теста можно оставить небольшую локальную модель.
Для русскоязычной или смешанной библиотеки желательно протестировать несколько вариантов на одинаковом наборе вопросов.
Не оценивайте embedding-модель только по скорости. Главный критерий — находит ли она правильные главы и страницы.

Шаг 3. Создайте Knowledge Base​

Откройте:

Workspace → Knowledge

Создайте новую базу, например:

Название: Windows Internals
Описание: Книги по внутреннему устройству Windows, ядру, процессам, памяти и драйверам.

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

Разные книги

Хорошее описание:

Технические книги по внутреннему устройству Windows: процессы, потоки,
виртуальная память, Object Manager, I/O Manager, драйверы и механизмы безопасности.

Шаг 4. Сначала загрузите одну книгу​

Не загружайте всю библиотеку сразу.
Добавьте один PDF и дождитесь завершения обработки.
После этого:

1. откройте извлечённый текст;
2. убедитесь, что документ не пустой;
3. проверьте несколько страниц;
4. выполните тестовый поиск;
5. задайте несколько вопросов модели.

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

Шаг 5. Дождитесь завершения индексации​

Большая книга может обрабатываться продолжительное время, особенно если:

• используется OCR;
• Docling работает на CPU;
• книга содержит сотни страниц;
• embedding-модель большая;
• сервер имеет мало оперативной памяти;
• загружается несколько файлов одновременно.

Не добавляйте документ в базу через API сразу после загрузки, пока его обработка не завершилась.

Шаг 6. Подключите базу к чату или модели​

Базу знаний можно:

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

Для отдельной модели можно создать конфигурацию:

Название: Zer0Kernel Windows Researcher
Базовая модель: Qwen Coder
Knowledge Base: Windows Internals

При этом новая модель не является копией Qwen. Это конфигурация, которая использует базовую модель вместе с выбранным системным промптом и базой знаний.

---

Focused Retrieval и Full Context​

В Open WebUI могут использоваться два основных режима работы с документами.

Focused Retrieval​

Система ищет только наиболее подходящие чанки.
Подходит для:

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

Преимущества:

• экономия контекста;
• высокая скорость;
• возможность работать с большой библиотекой.

Недостатки:

• поиск может пропустить нужный раздел;
• ответ зависит от качества embeddings;
• модель не видит документ целиком.

Full Context​

В контекст передаётся весь документ.
Подходит для:

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

Для книги на 800 страниц Full Context обычно не подходит. Она может не поместиться в контекст или вытеснить историю разговора.

---

Native Function Calling и базы знаний​

В современных версиях Open WebUI модель может самостоятельно вызывать инструменты базы знаний.
Это означает, что подключённая база не всегда автоматически добавляется к каждому запросу. Модель должна решить, что ей необходимо выполнить поиск.
Некоторые локальные модели вызывают инструменты не всегда надёжно.

Для улучшения поведения можно добавить системную инструкцию:

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

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

Если в базе нет достаточной информации, прямо сообщи об этом.

Не придумывай отсутствующие факты.

По возможности указывай название документа, главу и страницу.

Для исследовательской модели можно использовать более строгий вариант:

Отвечай на вопросы по содержимому подключённой базы знаний.

Перед ответом обязательно выполни поиск по базе.

Сравни несколько найденных фрагментов, если вопрос затрагивает разные главы
или документы.

Отделяй сведения из источника от собственных выводов.

Если ответ не подтверждается документами, напиши:
"В подключённой базе знаний точная информация не найдена".

Если модель продолжает игнорировать документы:

1. проверьте доступ пользователя к базе;
2. убедитесь, что для модели включены инструменты Knowledge Base;
3. подключите базу к чату вручную;
4. проверьте системный промпт;
5. протестируйте режим без Native Function Calling, если установленная версия это поддерживает;
6. проверьте, работает ли поиск независимо от языковой модели.

---

Как правильно тестировать RAG​

Нельзя оценивать качество базы одним вопросом.
Подготовьте набор контрольных вопросов четырёх типов.

1. Точное совпадение​

Вопрос содержит термин из книги:

Что такое EPROCESS?

2. Переформулированный вопрос​

Вопрос не повторяет формулировку источника:

Каким объектом ядра Windows представлен пользовательский процесс?

3. Вопрос по нескольким разделам​

Чем объект процесса отличается от объекта потока и как они связаны?

4. Вопрос, ответа на который нет​

Как структура EPROCESS устроена в ещё не выпущенной версии Windows?

Хорошая RAG-система должна:

• найти правильный материал по точному вопросу;
• найти его при другой формулировке;
• объединить данные из нескольких чанков;
• признать отсутствие информации;
• не придумывать несуществующие цитаты и страницы.

---

Почему модель не видит книгу​

Это одна из наиболее частых проблем.

Причина 1. Из PDF не извлечён текст​

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

Причина 2. Извлечён повреждённый текст​

Например:

P r o c e s s   O b j e c t

или символы идут в неправильной последовательности.
Используйте другой обработчик документов или предварительно преобразуйте PDF.

Причина 3. Слишком маленькие чанки​

Отдельные фрагменты не содержат достаточного контекста.
Увеличьте:

Chunk Size
Chunk Min Size Target

Причина 4. Слишком большие чанки​

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

Причина 5. Неподходящая embedding-модель​

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

Причина 6. Слишком маленький Top K​

Если Top K = 1, модель получит только один найденный фрагмент.
Для сложных вопросов может потребоваться несколько чанков из разных глав.

Причина 7. Слишком большой Top K​

Если передать слишком много фрагментов, полезная информация может потеряться среди постороннего текста.
Кроме того, контекст модели может переполниться.

Причина 8. База подключена, но модель не выполняет поиск​

Это часто связано с Native Function Calling.
Добавьте явную инструкцию использовать базу знаний или подключите её к чату вручную.

Причина 9. У пользователя нет доступа​

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

Причина 10. Embedding-модель была изменена​

Старые документы продолжают содержать векторы предыдущей модели.
Запустите повторную индексацию всех документов.

---

Работа с программным кодом​

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

if (process != NULL) {
    initialize_process

Следующий чанк:

(process);
}

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

• отступы;
• фигурные скобки;
• символы *, &, <, >;
• шаблоны C++;
• команды Bash;
• пути Windows;
• обратные слеши;
• Markdown-кодовые блоки.

Особенно часто повреждаются:

C:\Windows\System32

\Device\HarddiskVolume1

char **argv

template<typename T>

Если код критически важен, иногда лучше отдельно загрузить примеры в формате Markdown или обычного текста.

---

Работа с таблицами и схемами​

Таблицы могут извлекаться как:

Поле
Тип
Описание
PID
ULONG
Идентификатор

В таком виде модель может не понять связи между колонками.
Лучше получить:

| Поле | Тип | Описание |
|---|---|---|
| PID | ULONG | Идентификатор процесса |

Схемы и изображения обычная текстовая RAG-система не понимает, если обработчик не создаёт их текстовое описание.
Возможные решения:

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

---

Как улучшить точность ответов​

Используйте гибридный поиск​

Векторный поиск хорошо находит смысл, но иногда плохо работает с точными идентификаторами:

EPROCESS
MmCopyVirtualMemory
IRP_MJ_DEVICE_CONTROL
CVE-2025-1234
0xC0000005

Для технической базы полезно объединять:

• векторный поиск;
• полнотекстовый поиск;
• BM25;
• reranker.

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

Добавляйте метаданные​

Для каждого чанка желательно сохранять:

Название книги
Автор
Издание
Глава
Раздел
Страница
Язык
Дата публикации
Тип документа

Это повышает удобство поиска и позволяет формировать нормальные ссылки на источники.

Удаляйте дубликаты​

Не стоит одновременно загружать:

• оригинальный PDF;
• его копию с другим именем;
• Markdown, автоматически созданный из того же PDF;
• разные сканы одного издания.

Дубликаты могут занять все позиции Top K одинаковыми фрагментами.

Разделяйте разные издания​

Сведения из разных изданий могут противоречить друг другу.
Например:

Windows Internals, 6th Edition
Windows Internals, 7th Edition

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

---

Безопасность и конфиденциальность​

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

• Open WebUI;
• Docling;
• embedding-модель;
• Qdrant;
• Qwen;

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

• облачная embedding-модель;
• внешний OCR;
• облачная языковая модель;
• сторонний API обработки PDF;
• удалённая векторная база.

Перед загрузкой конфиденциальных материалов проверьте весь маршрут данных:

Браузер
 → Open WebUI
 → обработчик документов
 → embedding-сервис
 → векторная база
 → языковая модель

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

---

Резервное копирование​

Для восстановления RAG недостаточно сохранить только языковую модель.
Необходимо резервировать:

Исходные PDF и документы
Данные Open WebUI
Базу метаданных
Векторную базу
Настройки embedding-модели
Настройки чанков
Системные промпты
Права пользователей
Docker Compose и конфигурации

Хорошая структура резервной копии:

backup/
├── documents/
├── open-webui/
├── vector-database/
├── configs/
├── prompts/
└── manifest.json

В manifest.json можно сохранить:

{
  "knowledge_base": "Windows Internals",
  "embedding_model": "BAAI/bge-m3",
  "chunk_size": 1500,
  "chunk_overlap": 200,
  "text_splitter": "token",
  "created_at": "2026-07-29"
}

Это позволит понять, с какими параметрами была создана база.

---

Обновление библиотеки​

Рекомендуемый процесс добавления новых документов:

1. сохранить оригинал;
2. проверить наличие текстового слоя;
3. выполнить OCR при необходимости;
4. извлечь текст;
5. проверить несколько страниц;
6. удалить явный мусор;
7. добавить метаданные;
8. проиндексировать документ;
9. задать контрольные вопросы;
10. сохранить результаты тестирования.

Не следует автоматически добавлять все найденные в интернете PDF. Один повреждённый или нерелевантный документ может ухудшить ответы всей базы.

---

Рекомендуемая конфигурация для технических книг​

Для локального сервера с Qwen Coder можно начать со следующего варианта:

Document Extractor: Docling
Text Splitter: token
Markdown Header Splitting: On
Chunk Size: 1500
Chunk Overlap: 200
Top K: 5–10
Embedding: многоязычная локальная модель
Retrieval: Focused Retrieval
Full Context: только для небольших документов
Reranking: включить после первоначальной проверки

Для первого теста достаточно трёх книг.
После загрузки подготовьте не менее 20 контрольных вопросов и записывайте:

Вопрос
Ожидаемый источник
Найденный источник
Правильность ответа
Наличие выдуманных фактов
Время ответа

Пример:

Вопрос	Ожидаемый источник	Результат
Что такое EPROCESS?	Windows Internals, Processes	Найдено
Как работает working set?	Memory Management	Частично
Что такое task_struct?	В базе отсутствует	Модель признала отсутствие

---

Заключение​

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

• качество PDF;
• правильное извлечение текста;
• OCR;
• размер чанков;
• embedding-модель;
• настройки поиска;
• объём контекста;
• метаданные;
• системный промпт;
• контрольные тесты.

Главное правило:

Сначала проверьте качество извлечённого текста и поиска, и только потом оценивайте ответы нейросети.

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