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

Что считать структурированными данными для ИИ

Под структурированными данными обычно понимают таблицы, справочники и записи с явными полями: номенклатура и контрагенты в 1С, сделки в CRM, реестры заявок, спецификации, прайсы, кадровые приказы. Рядом лежит полусырое — PDF-регламенты, сканы договоров, письма, — которое после OCR и разбора превращается в те же поля. Практика показывает: в типовом российском контуре до 80 % ценных знаний распределено между учётной системой, файловым хранилищем и почтой, и именно их приходится приводить к машиночитаемому виду.

RAG: знание подставляется в контекст

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

Файн-тюнинг: знание вшивается в веса

Дообучение (SFT, LoRA, QLoRA) меняет параметры модели на подготовленном датасете. Это сильно, когда нужно закрепить формат: выдавать строгий JSON для интеграции с 1С, держать отраслевую терминологию, соблюдать корпоративный тон, устойчиво классифицировать обращения. Но факты, которые меняются ежедневно, в веса не зашить — модель запомнит цифру из датасета и будет уверенно её повторять. Плюс каждый цикл дообучения требует разметки, валидации и новой версии артефакта.

Чем отличаются на практике

• Источник истины. В RAG — внешняя база, которую можно проверить и показать ссылку на документ. В файн-тюнинге — распределённая память модели, аудит ответа затруднён.
• Скорость обновления. RAG — минуты и часы. Дообучение — дни и недели.
• Стоимость. RAG дороже на этапе индексации и поиска, дешевле в поддержке. Файн-тюнинг дешевле в инференсе, дороже в жизненном цикле данных.
• Галлюцинации. RAG снижает их за счёт опоры на источник и позволяет отвечать «в данных нет ответа». Дообучение повышает уверенность тона, но не гарантирует фактичность.
• Права доступа. В RAG фильтрация по ролям делается на уровне поиска: менеджер не получит фрагмент из чужого договора. В весах разграничение реализовать нельзя.

Гибридный сценарий

Рабочая схема для большинства проектов — комбинация. RAG отвечает за факты и цитаты, а небольшая LoRA-надстройка учит модель отвечать в нужном формате, не ломая структуру и не выдумывая поля. Иногда достаточно few-shot примеров в промпте вместо дообучения — это быстрее и дешевле проверить на пилоте.

Практические шаги

1. Проведите аудит источников: что уже структурировано, что требует OCR и нормализации.
2. Разделите знание на «меняется часто» (RAG) и «стабильный формат и стиль» (дообучение).
3. Соберите пилот на 100–200 реальных запросах сотрудников, а не на демо-вопросах.
4. Замерьте метрики: точность извлечения, полнота ответа, доля отказов, время ответа.
5. Продумайте контур: для чувствительных данных — приватная LLM на своих мощностях, логирование запросов, разграничение доступа.

Как мы можем помочь

Мы проектируем и внедряем такие системы под ключ: готовим структурированные данные из 1С, CRM и документов, собираем RAG-контур с контролем доступа, при необходимости дообучаем модель под ваш формат ответов и разворачиваем всё в приватном контуре. Начинаем с короткого аудита данных и пилота на ваших сценариях, чтобы решение опиралось на измеримый результат, а не на обещания. Обсудить проект