RAG-системы для бизнеса 2026: AI, который знает вашу базу знаний

Что такое RAG простыми словами

За 2024-2026 я внедрил несколько RAG-систем в проде — от чат-бота по юридической базе на 1200 документов до корпоративного поискового помощника на 12 000+ файлов. У меня есть сертификации Vanderbilt University по AI Agents и MongoDB Inc. по RAG и Vector Search — обе 2026 года, и обе — про то, что описано в этой статье. Это не для красоты в резюме: я писал эти пайплайны руками, и знаю, где они ломаются.

Простая аналогия. Представьте GPT-4 как очень начитанного эрудита. Он прочитал миллионы книг, знает историю, физику, программирование, медицину — но он никогда не видел вашу внутреннюю документацию, ваш прайс-лист 2026 года, ваш регламент по обработке возвратов. Спросите его «какая у нас процедура согласования отпуска» — и он либо честно скажет «не знаю», либо, что хуже, выдумает правдоподобный, но ложный ответ. Это называется галлюцинация, и для бизнеса она опаснее, чем «не знаю».

RAG — это библиотекарь, который подсказывает эрудиту нужную страницу из вашей библиотеки прямо перед ответом. Процесс такой: пользователь задаёт вопрос → система ищет в вашей базе документов 5-10 самых релевантных кусочков (chunks) → передаёт их LLM с инструкцией «ответь по этим кускам, ничего не выдумывай» → пользователь получает ответ со ссылкой на источник. Эрудит не знал ваших регламентов, но теперь у него в руках именно те страницы, которые нужны, и он формулирует ответ по ним.

Аббревиатура расшифровывается как Retrieval-Augmented Generation — «генерация, дополненная поиском». Термин ввели исследователи Facebook AI в 2020 году, но массовый бум начался в 2023-2024, когда стало понятно: дообучать (fine-tune) большие модели под каждую компанию — дорого, медленно и не работает, а вот «прикрутить поиск» — дёшево, быстро и работает.

Когда RAG нужен и когда — нет

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

Правило большого пальца: если ответы на запросы лежат в вашей базе документов от 200 файлов или 1 миллиона токенов, и при этом нужна точность и ссылка на источник — RAG ваш выбор. Если данные есть в общих знаниях LLM (например, как написать SQL-запрос) или их можно получить через API (текущая погода) — RAG избыточен.

Архитектура RAG: что под капотом

Полный поток выглядит так:

1. Загрузка документов. PDF, Word, Excel, HTML, Markdown, базы данных. На этом этапе живёт первая большая боль: парсинг таблиц, OCR сканов, обработка форматирования. Я часто 30-40% времени проекта трачу именно тут.
2. Очистка и нормализация. Убираем мусор: колонтитулы, навигацию HTML, дубликаты, лишние пробелы. Преобразуем в чистый текст с метаданными (источник, дата, раздел).
3. Chunking. Разбиваем длинные тексты на куски по 300-1500 токенов с перекрытием 50-200 токенов. Эта самая недооценённая часть пайплайна — о ней отдельная глава ниже.
4. Embeddings. Для каждого chunk считаем векторное представление (вектор из 384-3072 чисел). Эти векторы — «смысловые координаты» текста в многомерном пространстве. Семантически близкие тексты дают близкие векторы.
5. Сохранение в Vector DB. Записываем векторы вместе с исходным текстом и метаданными в специализированную БД, которая умеет быстрый kNN-поиск.
6. Query embedding. Когда приходит вопрос пользователя — превращаем его в вектор той же моделью.
7. Retrieval (поиск). Достаём top-k (обычно 5-20) ближайших по косинусной близости chunks.
8. Reranking. Если k большой — прогоняем кандидатов через более точную модель (cross-encoder), которая выбирает реально лучшие 3-5.
9. Prompt assembly. Собираем итоговый промпт: системная инструкция + выбранные chunks + вопрос пользователя.
10. LLM generation. Отправляем в YandexGPT/GigaChat/Claude/локальную модель, получаем ответ.
11. Post-processing. Проверяем ответ на наличие ссылок, валидируем по схеме, логируем.

Это базовый пайплайн. В продакшене сверху накручиваются: кеширование embeddings, инкрементальное обновление базы при изменении документов, A/B-тестирование разных конфигураций, мониторинг качества ответов через LLM-judge, обратная связь от пользователей. Объём кода production-RAG — обычно 2-5 тысяч строк плюс инфраструктура.

Векторные базы данных: что выбрать в РФ 2026

Vector DB — это сердце RAG. От её выбора зависят скорость поиска, бюджет, удобство эксплуатации и доступность в России. Свожу всё что пробовал в один обзор.

Мой личный выбор для проектов 2026:

• Прототипы и MVP. Chroma локально — поднимается одной командой pip install chromadb, не требует отдельного сервера.
• Малый-средний production (до 500к chunks). pgvector. Главный плюс — это просто extension к PostgreSQL, которая уже стоит у каждой второй компании. Бэкапы, репликация, мониторинг — всё уже есть.
• Серьёзный production (от 500к chunks). Qdrant. Российская команда, отличная документация на английском и русском, скорость на голову выше pgvector, есть GUI.
• Enterprise (от 10M chunks). Milvus или ClickHouse Vector Search. Оба горизонтально масштабируются и проверены на сотнях миллионов векторов.

Если компания уже использует MongoDB — Atlas Vector Search логичен, потому что нет нужды поднимать отдельную БД. Но для self-hosted-варианта потребуется MongoDB Enterprise, что недешёво.

Embeddings модели в РФ: что реально доступно

Выбор модели для embeddings — второе важное решение. От неё зависит качество поиска. Хорошая модель попадает в правильные документы в 85-95% случаев, плохая — в 50-70%. Разница в качестве итогового ответа RAG будет колоссальная.

Что выбираю на практике:

• Если документы на русском и есть GPU-сервер. bge-m3 или multilingual-e5-large локально. Качество отличное, после первоначальной настройки — бесплатно навсегда.
• Если нужно через API и важна простота. YandexGPT Embeddings — оптимальное соотношение цены, качества и юридической чистоты в РФ.
• Если документы технические или на английском. bge-large-en-v1.5 локально, иначе OpenAI text-embedding-3-large (через прокси или если можно вывозить данные).
• Чувствительные ПД / госконтур. Только локальные модели на собственных серверах. Никаких API.

Важное замечание про размер вектора. YandexGPT даёт всего 256 чисел — это быстро и дёшево, но потолок качества ниже, чем у моделей с векторами 1024-4096. Для базы из 5000 коротких FAQ — 256 хватит за глаза. Для базы из 50 000 юридических документов с тонкими формулировками — лучше брать модель с большим вектором.

Chunking: самая недооценённая часть RAG

Десятки разговоров с другими инженерами я начинал с «у меня RAG плохо отвечает». В 70% случаев причина — кривой chunking, а не модель и не БД.

Базовый вопрос: какого размера должны быть кусочки? Слишком маленькие (50-100 токенов) — теряется контекст, модель не понимает о чём кусок. Слишком большие (2000+ токенов) — в выбранный chunk попадает мало релевантной информации, размытые ответы и больше галлюцинаций. Золотая середина — 300-800 токенов с перекрытием 50-150 токенов.

Перекрытие (overlap) нужно, чтобы важная фраза не разрезалась пополам на границе кусков. Если документ говорит «Срок исковой давности по этому виду споров составляет три года.» — без overlap фраза может попасть наполовину в один chunk, наполовину в другой, и retrieval не достанет нужное.

Есть несколько стратегий chunking. По сложности нарастающей:

1. Fixed-size. Тупо режем по N символам. Просто, быстро, низкое качество. Для прототипа сойдёт.
2. By sentences. Режем по предложениям, набираем до N токенов. Лучше чем fixed.
3. By paragraphs / headers. Используем структуру документа: заголовки H1-H3, абзацы. Очень хорошо работает на структурированных документах.
4. Semantic chunking. Вычисляем embeddings для каждого предложения, режем там, где «смысл меняется» — между соседними предложениями большое расстояние векторов. Дорого считать, но качество на 10-20% выше.
5. Recursive character splitter. Иерархическая стратегия — сначала пытаемся резать по двойным переносам, не получилось вместить — по одинарным, потом по предложениям, потом по словам. Это дефолт в LangChain.

Вот рабочий пример recursive character splitter на Python, который я использую как стартер для большинства проектов:

from typing import List

def recursive_split(
    text: str,
    chunk_size: int = 600,
    chunk_overlap: int = 100,
    separators: List[str] = None,
) -> List[str]:
    """Рекурсивно режет текст по убыванию приоритета разделителей."""
    if separators is None:
        separators = ["\n\n", "\n", ". ", " ", ""]
    if len(text) <= chunk_size:
        return [text] if text.strip() else []

    sep = separators[0]
    rest = separators[1:]

    if sep == "":
        # Базовый случай — режем посимвольно
        return [text[i:i+chunk_size] for i in range(0, len(text), chunk_size - chunk_overlap)]

    parts = text.split(sep)
    chunks, current = [], ""
    for part in parts:
        candidate = current + (sep if current else "") + part
        if len(candidate) <= chunk_size:
            current = candidate
        else:
            if current:
                chunks.append(current)
            if len(part) > chunk_size:
                # Часть слишком большая — рекурсивно режем по следующему разделителю
                chunks.extend(recursive_split(part, chunk_size, chunk_overlap, rest))
                current = ""
            else:
                current = part

    if current:
        chunks.append(current)

    # Добавляем перекрытие
    if chunk_overlap > 0 and len(chunks) > 1:
        overlapped = [chunks[0]]
        for i in range(1, len(chunks)):
            tail = chunks[i-1][-chunk_overlap:]
            overlapped.append(tail + " " + chunks[i])
        chunks = overlapped

    return chunks

Что важно помнить про chunking в проде. Хранить надо не только сам текст chunk, но и метаданные: исходный файл, страница, заголовок раздела, дата документа, тип документа. Это позволяет фильтровать retrieval («ищи только в актуальных версиях регламентов»), показывать пользователю источник, и анализировать ошибки. Если вы не сохранили метаданные — потом не поймёте, откуда ответ пришёл.

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

Базовый поиск — это cosine similarity между вектором запроса и векторами всех chunks. Все Vector DB это умеют из коробки. Возвращается top-k (обычно k=5..20) ближайших.

Но cosine similarity — это не серебряная пуля. У него есть провалы:

• Семантический сдвиг. «Какова стоимость отгрузки» и «Сколько стоит доставка» — близкие по смыслу, embeddings справится. Но «доставка по СПб» и «доставка по Санкт-Петербургу» — для модели иногда расстояние больше, чем хотелось бы.
• Низкая способность к точным совпадениям. Если ищут «договор № 247/2026» — vector search может отдать договор № 247/2025 как «семантически похожий». Это смерть для юридических задач.
• Чувствительность к шуму. Если в запросе много стоп-слов, поиск размывается.

Решение — гибридный поиск: vector search + BM25 (классический полнотекстовый поиск). BM25 точно ловит совпадения по ключевым словам, vector search — семантику. Скоры комбинируются (часто как взвешенная сумма с весами 0.5+0.5 или 0.7+0.3 в пользу vector).

Поверх гибридного поиска ставится reranking. Берём top-20 из гибридного поиска и прогоняем через cross-encoder, который для каждой пары (запрос, chunk) выдаёт точный скор релевантности. Cross-encoder дороже по вычислениям, но точнее на 15-30%. В РФ доступны:

• bge-reranker-large — open-source, self-hosted, отличное качество, поддержка русского.
• Cohere Rerank v3 — API, $1/1000 запросов, без проблем с РФ.
• ColBERT v2 / ColBERTv2.5 — late-interaction модель, отличное качество, требует GPU.
• YandexGPT-Lite для rerank через prompt — кустарно, но в простых случаях работает.

Метрики, по которым оценивают качество retrieval: recall@k (доля случаев, когда правильный документ попал в top-k), MRR (mean reciprocal rank — насколько высоко правильный документ в списке), nDCG@k (учитывает порядок). Для RAG обычно стремятся к recall@5 на уровне 90%+ и MRR от 0.7.

Промпт-инжиниринг для RAG: запрет галлюцинаций

Достали правильные документы — теперь надо заставить LLM отвечать только по ним. Без жёсткого системного промпта модель будет добавлять «общие знания» и галлюцинировать. Вот мой проверенный шаблон, который я использую почти на всех проектах с небольшими адаптациями:

SYSTEM_PROMPT = """Ты — ассистент-эксперт по корпоративной базе знаний компании.

ПРАВИЛА ОТВЕТА:
1. Отвечай СТРОГО на основе предоставленных документов в блоке [КОНТЕКСТ].
2. Если ответа в [КОНТЕКСТ] нет — честно скажи "В моей базе нет точного ответа
   на этот вопрос. Рекомендую обратиться к [укажи кому]". Не выдумывай.
3. После каждого факта в скобках указывай источник: [Источник: имя файла, стр. N].
4. Не используй общие знания из интернета или своего обучения.
5. Если в [КОНТЕКСТ] есть противоречия — назови оба варианта и предложи уточнить.
6. Отвечай кратко и по делу, без вступлений типа "Согласно документам...".
7. Если вопрос не относится к компании — вежливо откажись.

ФОРМАТ ОТВЕТА:
- Прямой ответ на вопрос (1-3 предложения)
- Детали, если нужны (списком)
- Источники в конце

[КОНТЕКСТ]
{retrieved_chunks}
[/КОНТЕКСТ]

ВОПРОС ПОЛЬЗОВАТЕЛЯ: {user_question}
"""

Несколько важных деталей. Размещение контекста до вопроса работает лучше, чем после — модель «помнит» контекст свежее. Явная фраза «не выдумывай» снижает галлюцинации на 30-50% (тестировано). Требование указывать источники после каждого факта — самая мощная техника против фантазий: модель буквально не может «придумать» источник, если его нет в контексте.

Дополнительно — на проде я добавляю валидацию ответа: после генерации проверяю, что в ответе есть метка [Источник: ...], и эта метка действительно ссылается на один из переданных chunks. Если валидация падает — повторяю запрос или эскалирую к человеку.

Реальный кейс: RAG на 10 000+ документов для юр-компании

Один из моих самых крупных проектов 2025-2026. Юридическая компания, средней величины — 40 сотрудников, среди них 25 юристов. Накопленная база за 12 лет работы: 10 200 документов (договоры, судебные решения, заключения, регламенты, шаблоны), общим объёмом около 47 ГБ. Из них примерно 4500 PDF, 3200 DOCX, 1100 HTML/Markdown, остальное — Excel и сканы.

Боль до проекта. Когда новый юрист получал задачу «найди похожие судебные решения по моему делу» — он тратил 25-45 минут на поиск через сетевой диск с непродуманной структурой папок и Windows-search. Старшие юристы помнили базу наизусть и решали те же задачи за 5 минут — но они стоили часов клиентам.

Стек, который я собрал:

• Vector DB: MongoDB Atlas Vector Search (on-prem, в их инфраструктуре). Выбрали потому, что вся остальная база (CRM, документооборот) уже на MongoDB.
• Embeddings: e5-mistral-7b-instruct, локально на GPU-сервере (RTX 4090). Все документы внутри периметра компании, никаких внешних API.
• Chunking: recursive splitter с размером 700 токенов и overlap 150. Для договоров — отдельная стратегия с резкой по пунктам.
• Retrieval: гибридный (vector + BM25 через MongoDB Atlas Search), top-25.
• Rerank: bge-reranker-large на том же GPU.
• LLM: для конфиденциальных дел — Llama 3.3 70B локально, для общих запросов — YandexGPT 5 Pro через корпоративный аккаунт Yandex Cloud.
• UI: веб-приложение на React, интегрировано с их системой авторизации (Active Directory).

Результаты после 6 месяцев в продакшене:

• Среднее время поиска похожих документов: 25-45 минут → 30-90 секунд.
• Точность retrieval (нужный документ в top-5): 87% (мерили на 200 ручных кейсах).
• Точность ответов на типовые юр-вопросы: 92% (юр-эксперты проверяли).
• Экономия времени юристов: суммарно около 380 часов в месяц.
• Срок окупаемости: 4 месяца (стоимость проекта — 420 тыс ₽ разработка + 35 тыс ₽/мес инфраструктура).
• NPS пользователей системы: 8.4/10.

Что я бы сделал по-другому. Слишком долго возился с первоначальным chunking по умолчанию — потерял 2 недели, прежде чем понял, что для договоров нужен свой парсер по пунктам. И недооценил время на «обучение» пользователей задавать правильные вопросы — у нас две недели после релиза была фаза «эта штука не работает», пока юристы не научились формулировать запросы более конкретно.

Юридические нюансы RAG в РФ 2026

RAG-системы часто работают с конфиденциальными или персональными данными — это сразу включает 152-ФЗ и связанные акты. Главные подводные камни:

Запрет на отправку ПД в зарубежные сервисы. Если ваши документы содержат персональные данные (ФИО, телефоны, email клиентов и сотрудников — почти всегда), то отправка их в OpenAI/Anthropic/Cohere через VPN — это трансграничная передача без согласия и без выполнения условий ст. 12 152-ФЗ. Штраф для юрлиц — от 1 до 6 млн ₽ с июня 2025 (а оборотный — до 500 млн ₽ при утечке). Если у вас есть ПД в базе — embeddings и LLM должны быть либо локальными, либо российскими (YandexGPT, GigaChat). Подробнее в статье про локализацию ПД.

Уведомление в РКН. Если ваш RAG обрабатывает ПД (а он почти наверняка обрабатывает) — нужно подать уведомление в РКН с указанием способов обработки, целей, источников, передач. Большинство компаний пропускают этот шаг, потом получают штрафы за непредставление информации (статья 19.7 КоАП — до 5 тыс ₽, но это плюс к основному).

Соглашение с обработчиком. Если вы заказываете RAG у подрядчика и он будет иметь доступ к вашим документам с ПД — нужно договор поручения по ст. 6 152-ФЗ. Я как разработчик всегда подписываю такой документ, и рекомендую всегда требовать его от любого подрядчика.

Безопасность хранения. Vector DB с ПД — это база с ПД. К ней применяются те же требования: контроль доступа, журналы, шифрование «at rest». ФСТЭК-сертифицированных Vector DB пока нет, поэтому используют общие меры — шифрование диска (LUKS, BitLocker), сетевая изоляция, RBAC.

Сколько стоит RAG-система в 2026

Цены делю на три категории — прототип, продакшен, enterprise.

Что входит в разработку: парсинг и нормализация документов, настройка chunking, выбор и интеграция Vector DB, embeddings, retrieval с reranking, промпт-инжиниринг, UI (если нужен), интеграция с авторизацией компании, мониторинг качества, документация, обучение пользователей.

Месячные расходы в основном — это инфраструктура (сервера, GPU), токены LLM (если через API), поддержка. На GPU-сервер для embeddings + reranking хватает RTX 4090 или 5090 — 5-7 тыс ₽/мес в облаке (Selectel, VK Cloud) или единоразовая покупка за 150-250 тыс ₽. Токены YandexGPT 5 Pro — 0.40-0.80 ₽ за 1000 токенов вывода, для среднего использования это 5-30 тыс ₽/мес.

Топ-5 ошибок при внедрении RAG

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

1. Игнорирование качества документов. «У нас в Confluence/SharePoint всё лежит — давайте сделаем RAG». А там 30% документов устарели, 20% — дубликаты, 15% — черновики. RAG прилежно достанет устаревший регламент 2019 года и выдаст ответ по нему. Перед запуском нужна ревизия: пометить актуальные, удалить устаревшее, разрешить только проверенные источники.

2. Слепая вера в дефолтные настройки. Chunk size 1000, overlap 200, top-k=5 — это разумные дефолты для англоязычного текста. Для русского, для длинных юридических документов, для технической документации — другие оптимумы. Без A/B-тестирования на ваших данных гарантированно получите средненький результат.

3. Отсутствие метрик качества. Запускают RAG, спрашивают «работает?», получают «да вроде», уходят. Через 3 месяца выясняется, что точность 40%. Нужен ground truth (50-200 пар вопрос-правильный документ) и автоматический мониторинг retrieval-метрик после каждого изменения системы.

4. Один промпт на все случаи жизни. Чем сложнее задача, тем больше шансов, что нужны разные стратегии: для FAQ — один промпт, для генерации drafts документов — другой, для аналитических запросов — третий. Роутинг по типу вопроса (через классификатор) — экономит 20-40% точности.

5. Игнорирование обратной связи пользователей. Кнопка «помогло / не помогло» под каждым ответом плюс поле «что не так» — простейший механизм, который даёт тысячи кейсов на улучшение системы. Без него вы летите вслепую.

Частые вопросы

Чем RAG отличается от fine-tuning?

Fine-tuning — это дообучение самой модели на ваших данных. Долго (дни-недели), дорого (от 500 тыс ₽), требует переобучения при каждом изменении базы знаний, и модель всё равно может галлюцинировать. RAG — это «подсунуть нужные документы в момент запроса». Дёшево, быстро меняется, ссылается на источник. В 95% бизнес-задач RAG лучше fine-tuning. Иногда их комбинируют — fine-tune под стиль/тон + RAG для фактов.

Можно ли сделать RAG без программистов?

Прототип — да, через no-code инструменты типа n8n + Pinecone (не для РФ), Flowise, LangFlow. Production-grade RAG с реальным качеством — почти всегда нет. Требуется настройка пайплайна, мониторинг, обработка edge-cases. No-code RAG обычно даёт recall@5 на уровне 50-70%, custom-разработка — 85-95%.

Сколько документов нужно для запуска RAG?

Минимум — 50-100 документов, иначе vector search не имеет смысла, проще промптом скормить всё в контекст. Сладкая зона — от 500 до 50 000 документов. Свыше 100 000 — нужны продвинутые методы (hierarchical retrieval, графовые подходы), бюджет растёт.

Можно ли использовать ChatGPT/Claude для RAG в российской компании?

Если в документах нет персональных данных — теоретически да, но всегда проверяйте корпоративную политику. С ПД — нельзя из-за 152-ФЗ. С коммерческой тайной — рискованно, потому что условия использования OpenAI/Anthropic не дают гарантии конфиденциальности в нужном объёме. Безопаснее — российские модели (YandexGPT, GigaChat) или локальный Llama 3.3 / Qwen 2.5.

Какая модель лучше для русскоязычного RAG в 2026?

Для embeddings: bge-m3 локально или multilingual-e5-large локально, как API — YandexGPT Embeddings. Для генерации: YandexGPT 5 Pro в большинстве случаев, GigaChat 4 Pro как альтернатива, локально — Qwen 2.5 72B или Llama 3.3 70B. Если данные нечувствительные — Claude 4.7 Sonnet даёт лучшее качество, но требует решения вопроса с трансграничной передачей.

Сколько занимает разработка простого RAG?

MVP под одну задачу с базой до 5000 документов — 2-3 недели с одним инженером. Тестирование на ваших данных и адаптация — ещё 2-4 недели. То есть от ТЗ до боевого использования — обычно 5-7 недель. Production-grade — 2-4 месяца.

Что делать, если документы в виде сканов PDF?

Сначала OCR — Tesseract (бесплатно), ABBYY FineReader (платно, точнее), или специализированные модели типа Surya. Качество OCR критично — если в сканах путаются буквы, RAG будет искать «по опечаткам» и проваливаться. Для документов с таблицами — отдельный пайплайн с PyMuPDF или unstructured.io.

Можно ли подключить RAG к уже существующему чат-боту?

Можно и нужно. Базовый паттерн: бот получает сообщение пользователя, передаёт его в RAG-сервис, RAG возвращает ответ, бот отдаёт пользователю. Реализуется как отдельный HTTP-сервис на FastAPI. Если у вас уже есть n8n-сценарий — RAG встраивается как один из node.

Выводы: 5-шаговый план как сделать первый RAG за 2 недели

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

1. Неделя 1, дни 1-2. Соберите 100-500 самых актуальных документов из вашей базы знаний в одну папку. Только актуальные. Только проверенные. Удалите дубликаты. Это самый важный шаг — мусор на входе даёт мусор на выходе.
2. Дни 3-4. Поднимите минимальный стек: Python, Chroma локально, bge-m3 как embeddings (бесплатно). Парсинг — через unstructured.io или PyMuPDF для PDF. Загрузите все ваши документы в Chroma с базовым chunk_size=600, overlap=100.
3. Дни 5-6. Напишите минимальный chat-loop: вопрос пользователя → embedding → top-5 из Chroma → промпт по моему шаблону выше → YandexGPT 5 Pro. 100 строк кода, не больше. Не пытайтесь делать UI — командная строка достаточно.
4. Неделя 2, дни 7-10. Соберите ground truth — 30-50 пар «вопрос → правильный ответ». Прогоните через систему. Посчитайте recall@5 и precision. Если ниже 75% — крутите chunking и top-k, добавьте reranking. Если выше 85% — пора в продакшен.
5. Дни 11-14. Простейший UI (Streamlit или Telegram-бот), мониторинг (логи каждого запроса), кнопка «не помогло». Запустите внутри своей команды на 5-10 человек. Соберите фидбек, итерируйте.

За 2 недели вы получите рабочий MVP, который реально полезен. Дальше — итерации по качеству, расширение базы, интеграции, продакшен-инфраструктура. Это уже задача на 2-3 месяца, если делать самостоятельно, и 4-8 недель, если с опытным подрядчиком.

Если вам нужен RAG, который работает, а не выглядит — пишите. Разберём ваш кейс, спроектируем архитектуру под ваши документы и бюджет, дам честную оценку срока и стоимости. Никакого AI-маркетинга — только то, что работает в проде.