Аналитика, машинное обучение /machine learning, ML и ИИ/AI на пальцах

🤖 Локальный RAG за 30 минут через готовые интерфейсы и совершенно бесплатно

1. Ставим сервер инференса (LM Studio / vLLM)
2. Запускаем Open WebUI — как удобную обёртку
3. Загружаем конфиденциальные документы — и система уже отвечает по ним
Всё локально, бесплатно и легально в РФ (выбраны программы доступные в РФ).

🚀 Если вы не программист — этот гайд для вас. Настройка не сложнее установки обычной программы.

Пошаговый чек-лист:

Шаг № 1. Архитектура системы
Шаг № 2. Устанавливаем Сервер инференса и модели
Шаг № 3. Поднимаем локальный сервер инференса
Шаг № 4. Установка RAG-клиента (Open WebUI)
Шаг № 5. Подключение Open WebUI к LM Studio
Шаг № 6. Загружаем документы и тестируем RAG
Шаг № 7. Автоматизация задач

🛠 Шаг 2. Сборка рабочего процесса в n8n

Ч.1. Как за час запустить оркестрацию с локальной LLM и n8n

Шаг 1. Событийно-управляемый триггер (Schedule Trigger)
- Trigger Interval: Weeks
- Trigger on Weekdays: Среда
- Trigger at Hour: 13

Шаг 2. Чтение DOCX (Read/Write Files from Disk)
- Operation: Read File(s) From Disk
- File(s) Selector: C:\Users\PC\Desktop\meetings\*.docx
- Options: Put Output File in Field → data

Шаг 3. Извлечение текста (DocuParse)
Community-узел (устанавливается через Settings → Community Nodes → n8n-nodes-liteparse-local)
- Operation: Parse Document
- Input Binary Field: data
- Output Format: Markdown

Шаг 4. Запрос к LM Studio (HTTP Request)
- Method: POST
- URL: http://127.0.0.1:1234/v1/chat/completions
- Headers: Content-Type: application/json
- Body (JSON): (см. полный код ниже)

Шаг 5. Обработка ответа и трансформация данных (Code)
В этом узле:
- Извлекается JSON-массив из ответа модели
- Сопоставляются исполнители и продуктовая линейка (справочные данные)
- Формируются исходящие интеграционные сообщения

Шаг 6. Отправка исходящих сообщений
- Operation: Send a Text Message
- Credentials: токен бота
- Parse Mode: HTML
- Retry on Fail: включить (3 попытки)
- Timeout: 120000 (2 минуты)

📝 Код трансформации данных (узел Code), вайбкодинг

// ===== 1. Получаем ответ от LM Studio =====
const lmResponse = $json;
if (!lmResponse) throw new Error('Нет ответа от LM Studio');

let rawText = '';
if (lmResponse.choices?.[0]?.message?.content) {
rawText = lmResponse.choices[0].message.content;
} else {
rawText = JSON.stringify(lmResponse);
}

// ===== 2. Убираем markdown =====
const jsonMatch = rawText.match(/```json\n([\s\S]*?)\n```/);
let tasks;
if (jsonMatch) {
try {
tasks = JSON.parse(jsonMatch[1]);
} catch (e) {
throw new Error('Ошибка парсинга JSON из markdown: ' + e.message);
}
} else {
const simpleMatch = rawText.match(/\[[\s\S]*\]/);
if (!simpleMatch) throw new Error('Не найден JSON-массив в ответе LM Studio');
try {
tasks = JSON.parse(simpleMatch[0]);
} catch (e) {
throw new Error('Ошибка парсинга JSON: ' + e.message);
}
}

if (!Array.isArray(tasks) || tasks.length === 0) {
throw new Error('Задачи не найдены');
}

// ===== 3. Справочные данные: специалисты =====
const specialists = [
{ name: "Имя_сотрудника_1", tg_id: "@tg_username_1" },
{ name: "Имя_сотрудника_2", tg_id: "@tg_username_2" },
// ... добавьте остальных
];

// ===== 4. Справочные данные: продукты =====
const courses = [
{ name: "Продукт_1", short: "П1" },
{ name: "Продукт_2", short: "П2" },
// ... добавьте остальные
];

// ===== 5. Формируем исходящие сообщения =====
const messages = tasks.flatMap(task => {
let assignees = [];
if (Array.isArray(task.assignee)) {
assignees = task.assignee;
} else if (typeof task.assignee === 'string') {
assignees = [task.assignee];
} else {
assignees = ['Не указан'];
}

return assignees.map(assigneeName => {
const specialist = specialists.find(s =>
assigneeName.toLowerCase().includes(s.name.toLowerCase()) ||
s.name.toLowerCase().includes(assigneeName.toLowerCase())
);
const mention = specialist
? `<a href="tg://user?id=${specialist.tg_id}">${specialist.name}</a>`
: assigneeName;

const courseName = task.course || '';
const course = courses.find(c =>
courseName.toLowerCase().includes(c.name.toLowerCase()) ||
c.name.toLowerCase().includes(courseName.toLowerCase())
);
const courseDisplay = course ? course.short : courseName || 'Не указан';

const taskText = task.task || task.title || task.задача || 'Задача без описания';
const deadline = task.deadline || task.срок || 'Не указан';

return {
chatId: 'Ваш_Chat_ID', // заменить
text: `📋 *Задача:* ${taskText}\n📚 *Курс:* ${courseDisplay}\n👤 Исполнитель: ${mention}\n📅 Дедлайн: ${deadline}`
};
});
});

return messages;

✅ Процесс запущен на постоянной основе.

🦾 Прикладной ИИ без кода: оркестрация рабочего процесса с использованием локальной LLM и n8n
Как без кода автоматизировать задачи с синхронизаций между двух департаментов: 19 продуктов, 10+ сотрудников, 20+ вопросов

📌 Почему n8n?

Это инструмент интеграции корпоративных приложений (EAI) в сервис-ориентированной архитектуре (SOA): соединяет независимые сервисы в единый процесс.

В отличие от облачных аналогов (Make, Zapier):
- инструмент с открытым исходным кодом (open-source)
- нет лимитов на количество операций
- работает локально (критично для 152-ФЗ)
- бесплатно (не требует подписки)
- устанавливается без заблокированного в РФ Docker (через Node.js)

🫡 Мой пример (проблема)

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

💡 Решение

Автоматизировать постановку задач.

🚀 Что учесть на старте

• Настройка с нуля может занять от часа до трёх
• Логику можно адаптировать под многие регулярные задачи
• На этапе сборки могут возникнуть сложности:
- выбор и интеграция сервисов
- платные подписки и платные API
- неочевидная стоимость на этапе тестирования

Я столкнулась с этим при выборе расшифровщика аудио: Fathom и VK Cloud отпали по разным причинам, остановилась на MyMeet — он дал нужный функционал без платного API на старте.

🏗 Архитектура рабочего процесса (workflow) в n8n

Мой состоит из 6 шагов:

1. Событийно-управляемый триггер (Schedule Trigger) — запускает оркестрацию каждую неделю после совещания
2. Чтение DOCX (Read/Write Files from Disk) — оркестратор забирает DOCX-файл из папки
3. Извлечение текста (DocuParse) — парсинг и трансформация данных: превращает DOCX в текст для анализа
4. Запрос к локальной LLM (HTTP Request) — отправляет текст в нейросеть и получает JSON с задачами
5. Обработка ответа и сопоставление со справочными данными (Code) — парсит JSON, сопоставляет исполнителей и продукты, формирует исходящие интеграционные сообщения
6. Отправка уведомлений с тегами

📌 Сборка

Шаг №1. Подготовка

1. Установка Node.js и n8n
2. Настройка бота
3. Развертывание локальной LLM
4. Создание папки для файлов

🛠 Установка n8n

1. Установить Node.js LTS (среда для запуска n8n в условиях заблокированного Doker)
- Перейти на официальный сайт Node.js
- Скачать LTS-версию (например, 18.x или 20.x)
- Установить (настройки по умолчанию)

2. Установить n8n через менеджер пакетов (npm)
Открыть командную строку на ПК (cmd) от имени администратора и выполнить:
npm install -g n8n

3. Запустить n8n
n8n start
После запуска открыть адрес http://localhost:5678 в браузере. Создать локальную учётную запись.

4. Включить community-узлы
Community-узлы используются, когда нужной функции нет среди встроенных узлов n8n. В нашем случае — для парсинга DOCX-файлов.
По умолчанию n8n может блокировать установку community-узлов по причинам безопасности и политики инстанса.
Запускаем n8n с флагом:
`n8n start --nodes-exclude="[]"`
Этот флаг включает все узлы, включая community-узлы, которые по умолчанию могут быть отключены.

🔧 Настройка бота

1. Найти @BotFather в Telegram → `/newbot`
2. Задать имя и username (обязательно с `_bot`)
3. В настройках бота включить **Allow Groups?** → `Turn groups on`
4. Отключить **Group Privacy** → `Turn off`
5. Добавить бота в группу и сделать администратором
6. Получить **Chat ID** группы через:
`https://api.telegram.org/bot<TOKEN>/getUpdates`

🤖 Развертывание локальной нейросети

Настроила также без кода ранее. Инструкция: тут. Протестировала — поняла, что без оркестрации малополезен. Так появилась эта идея.

📁 Источник данных

В моём случае это DOCX-отчёты из расшифровщика. Этот шаг можно адаптировать под:
- письма из почты (триггер на новое письмо)
- новые строки в таблице
- заказы с маркетплейса через API
- сообщения из чата с тегом #задача

Логика автоматизации остаётся той же.

💬 Далее:
Шаг 2. Сборка рабочего процесса (workflow) в n8n

🦾 Автоматизация умного поиска (RAG) на локальной нейросети (LLM) без навыков программирования
или как моя нейросеть и оркестратор n8n вернули мне 70% потерянных задач

🧩 Как заставить RAG работать самостоятельно

Контекст:
Поднимаем локального RAG-помощника на базе LLM за 30 минут

RAG даёт инсайты, но не действия. Без автоматизации это пассивный инструмент. А задачи, где он полезен, регулярные — иначе заморачиваться с локальной LLM не имеет смысла. Так что RAG важно и нужно автоматизировать.

Покажу пример конвейера (pipeline), который легко автоматизирует RAG-процесс.

Стек:
• n8n (оркестратор, без заблокированного в РФ Docker)
• LM Studio (локальный сервер с моделью)

Почему именно такой стек — становится понятно, если бегло взглянуть на иерархию инструментов автоматизации.

🧩 Иерархия инструментов автоматизации

Понимание уровня сложности защищает от двух главных ошибок:
• Overengineering — использование слишком сложных систем для простых задач
• Underengineering — попытка построить сложный процесс на «костылях»

Глобально в автоматизации есть 4 уровня сложности:

1. Без кода (No-Code) — клик-решил

Сборка логики из готовых блоков через графические интерфейсы. Вы вообще не видите код.

Инструменты: Bubble, Make, Zapier, Albato.

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

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

2. Мало кода (Low-Code) — мой кейс

Основная часть системы собирается из готовых блоков, но ключевую бизнес-логику (обработка JSON, запросы к нейросетям, сопоставление данных) вы дописываете руками на JavaScript / Python внутри отдельных узлов.

Инструменты: n8n, Retool, скрипты в Airtable.

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

3. Программирование через ИИ (Vibe Coding)

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

Инструменты: Cursor, Claude Code, Lovable, Replit Agent.

Подходит для быстрого прототипирования (например, показать инвесторам MVP-идею).

4. Классическая разработка (Pro-Code)

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

Незаменима для высоконагруженных систем, нестандартной логики, а также для поддержки легаси-проектов.

Вывод

В 80% операционных бизнес-задач можно обойтись No-Code / Low-Code и сэкономить ресурсы разработки.

Для своего кейса я выбрала Low-Code платформу n8n. Бесплатная, доступная без защищенных соединений, она дала нужную гибкость без необходимости писать код с нуля.

Пример автоматизации RAG на n8n

Я — основной спикер на встрече. Моя роль — вести диалог, принимать решения, раздавать поручения. Фиксировать задачи в моменте не могу, ассистента у меня, конечно, нет. Фиксация задач — на исполнителях и полностью зависит от уровня их личной ответственности (на практике процесс буксует). Только посчитайте: 10+ участников, ≈ 20–25 задач, результат: до 70% потерянных поручений.

Я настроила автоматизацию, которая сама расшифровывает встречи, выделяет задачи и тегает ответственных в чате. Без программиста, без облаков и без защищённых сервисов.

🏗 Архитектура

Яндекс Телемост (запись)
↓
MyMeet.ai (транскрипция → DOCX-отчёт)
↓
Локальная папка (автоматический мониторинг)
↓
n8n (автоматизация по расписанию):
- Чтение DOCX
- Извлечение текста
- Отправка в LM Studio
- Парсинг JSON-ответа
- Сопоставление со справочником специалистов
- Формирование сообщений с тегами
↓
Telegram (отправка в группу)

💬 Далее пошаговая настройка компонентов автоматизации:
• Установка n8n без Docker
• Сборка пайплайна
• Настройка Telegram-бота

🚀 Кейс можно адаптировать под разные бизнес-задачи:
• еженедельные отчеты
• обработка заказов на маркетплейсе
• создание контент-заводов

Контекстное окно и токены. Ч. 2. Управление настройками
Практика

Контекст:
Контекстное окно и токены. Ликбез

🛠️ Два уровня настройки

❗️ Их нельзя путать.

🔧 Уровень 1. Клиент (Open WebUI) — настройка RAG-параметров

• Chunk Size — размер фрагмента в токенах
- Таблицы/цифры: 256–512
- Сплошной текст: 512–1024

• Chunk Overlap — перекрытие между чанками (10–20% от Chunk Size)

• Top‑K — сколько чанков отправляем
- Большие документы: 3–5
- Маленькие таблицы: 10–15

⚙️ Уровень 2. LM Studio — сколько модель может принять

Параметр модели. Он задаётся до загрузки весов в память.

Как изменить Context Length:

1. LM Studio → My Models → шестерёнка у модели
2. Поле `Context Length` (`n_ctx`) → новое значение
3. Обязательно: Сохранить → выгрузить → загрузить модель заново. LM Studio не умеет подхватывать изменения на лету.

⚠️ Увеличение Context Length в 2 раза увеличивает потребление KV‑кэша примерно в 4 раза (квадратичная зависимость). Если после увеличения модель не загружается — включите CPU Offload.

⚙️ CPU Offload — когда видеокарте тяжело

Если модель не влезает в VRAM, часть вычислений можно переложить на процессор. Медленнее (CPU считает хуже GPU). Для RAG — актуально, когда нужно увеличить `n_ctx`, а видеопамяти не хватает.

🚨 Выходное окно (`max_tokens`)

❗️Не путай контекстное окно (вход) с длиной ответа (выход).

- Context Length (`n_ctx`) — сколько токенов модель читает
- Max Tokens (`max_tokens`) — сколько токенов модель генерирует

⚠️ Эти параметры независимы, но оба упираются в общий бюджет памяти модели.

📊 Примеры расчётов

Текст, 10 страниц (≈ 4 K слов)
- 4 K × 0.75 = 3 K токенов
- Chunk Size = 512, Top‑K = 3 → 1536 токенов в промпт
Итог: ~2 K токенов — влезает

Таблица, 30×5
- ~1,5 K–2 K токенов сырых
- Chunk Size = 256, Top‑K = 10 → все чанки в промпт
Итог: ~2,5 K токенов — влезает

😱 Документ больше контекстного окна

Документ на 8686 токенов при n_ctx = 8192
Результат: ошибка n_keep >= n_ctx

Решение зависит от ресурсов и структуры документа:

• Нет VRAM → используй только чанки (экономь память)
• Есть VRAM → увеличить окно
• Документ цельный (связанные абзацы) → увеличь окно и отдай документ целиком
• Документ рыхлый (можно вырезать куски) → разбивай смело на чанки

✂️ Как чанки режут разные типы файлов

Текст
Режется по границам предложений или абзацев. Риск — потеря смысла на стыках.
Решается Overlap (10–20% от Chunk Size).

Таблицы
⚠️ Самый опасный случай! Чанкинг режет таблицу по строкам. Если строки связаны между собой (суммы, итоги, зависимости) — модель теряет логику.
Для таблиц лучше: увеличивать n_ctx (если таблица небольшая) или преобразовывать таблицу в текст.

Код
Режется по строкам или функциям. Может разорвать логические блоки → модель не увидит целостность функции.

PDF с колонками
Режется как текст, но ломает порядок колонок (теряется смысл). Лучше отдать не pdf, а текстовый документ.

Правило: таблицы и структурированные данные не любят чанкинг. Их надо отдавать модели целиком (увеличивай n_ctx).

🔄 Регулярные задачи

- Новый чат — сбрасывает историю (проще всего)
- Очистить историю — вручную в Open WebUI
- N-последних сообщений — не отправлять при каждом запросе всю историю, а только только последние N (см. настройки: Context Messages, History Length, Max Messages in Context)

Правило:
Разные документы → разные чаты
Один документ → можно один чат, но чистить историю (иконка корзины)

🧩 Алгоритм

• Оценить размер документа в токенах: `символы ÷ 4` (для русского языка)
• Выбрать режим загрузки в Open WebUI: < 2 K токенов → «Полный контекст» (весь файл), если больше → включите RAG с чанками
• Chunk Size: таблицы 256, текст 512/1024
• Overlap: 10–20%
• Top‑K: 3–5 (большие доки) или 10–15 (маленькие)
• Проверить сумму: `(Chunk Size × Top‑K) + вопрос + системный промпт + max_tokens` < 80% от `n_ctx`
• Не влезает? Уменьшить Chunk Size или Top‑K. Или увеличить `n_ctx` в LM Studio
• Перезагрузить модель: если изменил любые настройки модели

Контекстное окно и токены. Часть 1
Ликбез

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

🔤 Токены

Модель не понимает текст — она работает только с числами. Превращение текста в числа происходит в три этапа:

1. Токенизация — разбивка на атомарные единицы

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

2. Векторизация — вложение смысла

Следующий слой модели — Embedding — преобразует каждый ID в вектор от сотен до тысяч координат. Например:
[-0.41,..., 0.5]

Этот вектор (эмбеддинг) кодирует семантику токена и его связи с другими понятиями в многомерном пространстве. Два близких по смыслу слова окажутся рядом в пространстве.

Подробнее про эмбеддинги

3. Подача на вход трансформеру

Именно эти эмбеддинги, а не исходный текст и не ID, поступают на вход механизму внимания (attention) трансформера для дальнейших вычислений.

Для русского языка:
• 1 токен ≈ 4 символа (включая пробелы и пунктуацию)
• Или 1 токен ≈ 0.75 слова

В английском токенизатор чаще выделяет целые слова (word-level), в русском — субслова (subword), т.к. больше окончаний, суффиксов.

📦 Контекстное окно

Контекстное окно (context window / n_ctx) — это максимальное количество токенов, которое трансформер-декодер может одновременно удерживать в своём механизме внимания (attention) при генерации одного ответа. По сути аналог оперативной памяти.

Сравнение моделей:
- Saiga Nemo 12B → 8 192 токена
- Llama 3.1 8B → 128 K
- GPT-4o / Claude 3.5 → 128 K – 200 K
- DeepSeek-V3 → 1M токенов (3 небольших книги!)

Что съедает место внутри окна:

• Системный промпт (инструкция для модели)
• Вопрос пользователя
• Найденные чанки из RAG (Top‑K фрагментов)
• История диалога (если она передаётся)
• Ответ модели (генерируется внутри этого же окна)

При привышении n_ctx модель либо:
• выдает ошибку (n_keep >= n_ctx)
• обрезает начало запроса (необратимая потеря данных)

🧠 Потеря в середине (lost in the middle)

Даже если документ целиком помещается в контекстное окно, это не гарантирует, что модель его усвоит. Исследования (например, Liu et al., 2024) показывают устойчивую закономерность распределения внимания модели:

✅ Начало контекста — запоминает лучше всего (привычный паттерн)
✅ Конец — запоминает хорошо (последние токены имеют высокий вес)
❌ Середина — часто «проваливается», получает меньше внимания

Что это означает для RAG-архитектуры:

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

🔗 Как контекстное окно провоцирует галлюцинации

Связь прямая и жёсткая. Рассмотрим цепочку:
• Документ не влезает в окно → модель видит только часть данных или обрезает запрос с начала → теряет критически важный контекст.
• Нужные данные оказались в середине → модель «забывает» их из-за lost in the middle → даже при формальном наличии факта в окне модель может его не использовать.
• Модель не нашла факт в контексте → и вынуждена опираться на свои внутренние веса, обученные на интернете. Включается априорное распределение P(токен | веса) вместо P(токен | контекст, веса).

Когда контекст не доминирует над «интернет-паттернами», модель выбирает наиболее статистически вероятный ответ из своего обучения — и как правило он противоречит вашему запросу (модель начинает галлюцинировать).

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

Как работает поиск в RAG

Понимание логики кодирования снимает с LLM и RAG ореол магии, превращая их в инженерию. Знание эволюции методов — ключ к осознанной настройке RAG.

💡 Первые идеи

1. Прямое кодирование меток / Label Encoding
Присвоить порядковые номера (конфета → 1, котлета → 2). Порядок есть, смысла нет.

2. Прорыв многомерных точек
Объект решили представлять точкой в N‑мерном пространстве с координатами (кортеж).
В дискретном пространстве количество ближайших соседей растёт линейно с размерностью:
1D → 2 соседа
2D → 4 соседа
ND → 2N соседей

Больше измерений = больше возможностей выразить сложные отношения между объектами.

3. Вектор вместо точки
Но к точке не применима математика, очередной тупик. Решили представлять точку как вектор (из начала координат), дав возможность производить алгебраические операции:
- сложение и вычитание — комбинирование смыслов
- косинусное подобие — сравнение направлений
- векторные аналогии: король – мужчина + женщина ≈ королева.

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

🦾 Эволюция кодирования в NLP

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

• One‑Hot Encoding (1950–1960‑е): векторы размером со словарь, разреженные, семантически слепы.
• Мешок слов (BoW) / TF‑IDF (1954–1970‑е): учёт частотности слов, но не порядка и контекста. «Собака виляет хвостом» = «Хвост виляет собакой».
• Word2Vec / GloVe (2013–2014): прорыв после долгой стагнации — статические эмбеддинги по контексту. Слова близки по смыслу — близки в пространстве. Но вектор не меняется от окружения → проблема омонимов (девушка с косой = смерть с косой).
• Transformer (2017): архитектура от Google на механизме внимания (Attention). Обрабатывает все токены параллельно, учитывает весь контекст (контекстно-зависимые эмбеддинги). Именно на нём построены все современные LLM.

🤩 Эволюция размерности

Размерность = количество координат у вектора. Чем она выше, тем тоньше смыслы, но дороже хранение и поиск:

• 300: статика (Word2Vec, GloVe, FastText от FB* (*Meta признана в РФ экстремистской организацией)), 2013–2018
• 768: контекстные модели (BERT, RoBERTa), 2018–2022
• 1536: современные RAG (OpenAI ada-002, Cohere, GTE), 2023–н.в.

🔣 Пайплайн индексации RAG (общая архитектура)

• Векторизация: модель эмбеддингов превращает неструктурированные данные (текст, изображения) в векторы
• Индексирование: векторы загружаются в векторную БД (например, ChromaDB). БД не просто хранит их, а строит по ним индекс (Vector Index) для быстрого поиска по косинусной близости

👨‍🎓 Эмбеддинги в RAG на примере Open WebUI

Контекст:
Как за 30 минут собрать локального RAG-помощника

• Индексация — чанки документа → векторы (например, all‑MiniLM‑L6‑v2)
• Хранение — векторы + текст в ChromaDB
• Запрос — вопрос → его вектор
• Поиск — находим чанки с максимальным косинусным сходством
• Передача — топ‑K (top‑K) чанков в промпт LLM

👨‍💻 Управление эмбеддингами в Open WebUI

В настройках администратора (раздел «Документы») выбирается модель:
- по умолчанию — all‑MiniLM‑L6‑v2 (384‑мерная, лёгкая, но менее точная);
- альтернативы — all‑mpnet‑base‑v2 (768D, точнее, но медленнее в обработке);
- для русского языка — многоязыковые модели (например, distiluse‑base‑multilingual‑cased‑v2), которые Open WebUI загружает автоматически или вручную через Hugging Face.

Количество возвращаемых чанков (top‑K) регулируется отдельно в настройках RAG — обычно 3–5 фрагментов для баланса между полнотой и релевантностью.

📌 Главное при настройке RAG

• Выбор модели эмбеддингов (задаёт размерность вектора): выше размерность и мощнее модель → точнее, но медленнее и дороже
• Настройка параметра top‑K (сколько фрагментов передать в LLM): больше top‑K → выше полнота, но больше токенов → дороже и медленнее, риск выйти за лимит контекста

💬 Далее:
Контекстное окно — как работает, чем опасно и как управлять токенами

Как за 30 минут развернуть локального RAG-помощника на LLM
Бесплатно, легально в РФ (без облаков и регистраций)
Практика

Шаг № 1. Архитектура системы
Шаг № 2. Устанавливаем Сервер инференса и модели
Шаг № 3. Поднимаем локальный сервер инференса
Шаг № 4. Установка RAG-клиента (Open WebUI)
Шаг № 5. Подключение Open WebUI к LM Studio
Шаг №6: Загружаем документы и тестируем RAG

Тестируем RAG и боремся с галлюцинациями

Контекст:
Как за 30 минут развернуть локального RAG-помощника на LLM

📌 Тестируем

Загружаем в RAG таблицу с расходами на рекламу по нескольким каналам, в том числе:

tgads | 22.06.2026 | 18 311 р.
tgads | 22.06.2026 | 3 593 р.

Вопрос: «Посчитай сумму расходов по tgads». Ожидаем: 21 904 р.
Ответ: 549 330 р. 🤯
549 330 = 18 311 × 30. Модель взяла первую строку, умножила на 30 дней, вторую — проигнорировала.

✅ Да, это RAG!

С одной стороны — ура! RAG работает (самый надёжный способ убедиться — посмотреть цитаты-ссылки на источник, работает без доп.настроек (см. скрин)

С другой — что за глюки?

🔬 Галлюцинации

Это когда LLM уверенно генерирует правдоподобный ответ, который не соответствует предоставленному контексту.

В научной литературе также используются термины: конфабуляция (confabulation), фабрикация (fabrication), иллюзия (delusion) и даже пустословие (bullshitting).

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

❓ Почему LLM галлюцинируют

1. Данные — ошибки, шумы, противоречия и пробелы в обучающих данных.
2. Архитектура — модель хранит не факты, а веса (числовые матрицы). Трансформер не извлекает информацию — он достраивает текст по вероятностям.
3. Процесс обучения модели — честное «не знаю» ⚠️ штрафуется сильнее, чем уверенная догадка.

📂 Типы

1. Фактические галлюцинации (Factuality Hallucination)
Модель выдаёт неверную информацию о реальном мире. Пример: придумывает несуществующие судебные дела, факты, цитаты.

2. Галлюцинации верности (Faithfulness Hallucinations) — наш случай

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

Конфликт: между априорным распределением (веса модели, выученные на интернете) и условным распределением (контекст, который мы дали).

В нашем случае: модель выбрала паттерн «расход в день → расход за месяц» как наиболее вероятный. Модель не различает задачи «сложи» и «спрогнозируй» — она просто выбирает паттерн из весов (максимизирует $P(токен \mid контекст, веса)$).

🛠️ Как бороться

Работа строится на трёх уровнях:

1. До генерации — промпт-инжиниринг

- Точный промпт
❌ «Рассчитай расходы по каналу tgads»
✅ «Найди в таблице все строки с utm_source = tgads и сложи суммы из столбца sum»

- Системный промпт с правилами
В нашем случае бухгалтерская роль: «Ты — бухгалтер. Отвечай строго на основе данных из файла. Если данных нет — скажи честно. Не делай прогнозов»
💪 Системный промпт сужает распределение вероятностей — модель выбирает токены, согласованные и с контекстом, и с инструкцией.

- Настройки RAG в Open WebUI
`Настройки администратора → Настройки → Документы`

Выбрать подходящий режим
• Обычный RAG: чанкирует документ, ищет релевантные фрагменты (для больших документов, нескольких файлов)
• Полный контекст: весь документ целиком, но эмбеддинги создаются (для маленьких документов, где важна каждая деталь)
• Обход встраивания: весь документ целиком, RAG отключён (очень маленькие файлы, модель может выдать ошибку n_keep >= n_ctx (превышение длины контекста))

2. На этапе инференса — управление параметрами

Temperature: 0.1–0.3 (ниже → точнее)
Top-P: 0.9
Top-K: 40 (ограничивает количество рассматриваемых слов)

3. После генерации — валидация

- Задать вопросы:
«Подтверди, что каждый факт есть в документе»
«На основе каких строк ты сделал вывод?»
- Использовать отдельную LLM как оценщика (LLM-as-Judge)

🔍 Как детектировать галлюцинации

1. Проверить, не придумала ли модель того, чего нет в документе
2. Включить показ контекста в Open WebUI (отладка), чтобы увидеть, какие фрагменты попали в промпт
3. Перепроверить цифры — LLM часто ошибается в расчётах

📌 Итог

Задача инженера — сделать условное распределение доминирующим через:
- Точные промпты
- Системные правила
- Валидацию ответов

Корректируем промт → получаем 21 904 р. ✅
RAG работает, модель не галлюцинирует!

Как за 30 минут развернуть локального RAG-помощника на LLM
Бесплатно, легально в РФ (без облаков и регистраций)
Практика

Контекст:
Шаг № 1. Архитектура системы
Шаг № 2. Устанавливаем Сервер инференса и модели
Шаг № 3. Поднимаем локальный сервер инференса
Шаг № 4. Установка RAG-клиента (Open WebUI)
Шаг № 5. Подключение Open WebUI к LM Studio

📝 Шаг №6: Загружаем документы и тестируем RAG

1. Создаём рабочее пространство

- На главном экране Open WebUI нажмите «Рабочее пространство» (Workspace)
- Дайте имя, например: «Аналитика»
- В выпадающем списке выберите модель

🛠️ 2. Параметры индексации RAG

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

Где искать:
Настройки администратора (аватар в правом нижнем углу) → Настройки → Документы

Что изменить?
1. Уменьшить размер чанка (Chunk Size): 256 (вместо 512)
Маленькие чанки лучше для таблиц — модель не теряет строки
2. Увеличить количество чанков (Top-K) со стандартных 5 до 10-15ти
Больше чанков = больше данных попадает в контекст
3. Установить перекрытие чанков (Chunk Overlap) 50–100 токенов
Перекрытие, чтобы данные не обрывались на границе чанка

⚠️ Важно:
Новые настройки применятся только к новым загрузкам! Удалите ранее загруженный документ из Рабочего пространства (если уже загружали).

⚙️ 3. Настройка контекстного окна модели

При работе с большим количеством данных вы можете получить ошибку, например:
`n_keep: 8686 >= n_ctx: 8192` — это означает, что ваш запрос превышает лимит модели.

В этом случае нужно настроить контекстное окно (Context Length)

Где настраивать?

Проще через интерфейс LM Studio (можно через командную строку):
- Откройте вкладку «My Models»
- Выберете нужную модель, нажмите на иконку шестерёнки (⚙️)
- Найдите поле Context Length (или n_ctx)
- Установите нужное значение (например, 16384)
- Сохраните настройки
- Перезагрузите модель: нажмите «Unload», а затем снова «Load»

Готово! Теперь модель будет загружаться с новым размером контекста.

⚠️ Важно:
- Увеличение контекстного окна требует больше оперативной и видеопамяти. Если модель не загружается после увеличения — попробуйте уменьшить значение или переключить движок на CPU (расширенные настройки)
- Изменения применяются только при загрузке. Context Length — это параметр, который задаётся во время загрузки модели в память. Поэтому после изменения настроек обязательно перезагружайте модель.

4. Загружаем документы

- Внутри рабочего пространства перейдите во вкладку «Знания» (Knowledge)
- Нажмите «Загрузить» и выберите файлы (поддерживаются PDF, CSV, TXT, DOCX)
- Можно добавить URL веб-страницы — система спарсит и проиндексирует её

Что под капотом:

Open WebUI автоматически разбивает документы на чанки, вычисляет эмбеддинги (векторы) и сохраняет их во встроенную векторную БД (ChromaDB).

5. Два способа загрузки документов

• Постоянное хранилище (документы нужны постоянно) | Вкладка «Знания» (Knowledge) в Рабочем пространстве
• Одноразовая загрузка (разовый файл) | Скрепка в чате

Используйте постоянное хранилище — документы не потеряются после перезагрузки.

✅ 6. Как проверить, что RAG работает

- Задайте вопрос, ответ на который есть только в ваших документах (модель не может знать без контекста)
- Если ответ пришёл и содержит информацию из документов — RAG работает!
- Если модель отвечает «не знаю» или придумывает — проверьте настройки индексации

7. Настройка качества ответов (если в тестовом вопросе есть неточности)

Классическая проблема RAG — модель получает не весь файл целиком, а фрагменты (чанки). Поэтому в зависимости от настроек:
1. Модель видит не все данные
2. Модель путает данные

📌 Чек-лист если ответы неточные

Модель видит не все данные → Увеличьте Top-K
Таблица путается→ Переформатируйте в CSV с заголовками
Модель придумывает → Уменьшите Chunk Size
Слишком длинные ответы → Измените температуру модели (в настройках чата)

Готово! Теперь у вас есть локальный RAG-помощник. 🚀

💬 Далее
Тестируем RAG и боремся с галлюцинациями