У любой компании старше пары лет есть склад знаний, к которому неудобно подойти. Регламенты в общей папке, инструкции в PDF, переписка с поставщиками в почте, схемы в чертежах, а половина ответов — в голове у двух человек, к которым ходят все остальные.
Вопрос «где посмотреть, какой допуск на этот узел» стоит десять минут чужого времени. Умножьте на количество таких вопросов в день.
Идея подключить к этому языковую модель приходит быстро. Дальше начинается развилка: дообучить модель на своих документах или подкладывать ей нужные куски в момент вопроса. Второй путь называется RAG, и для корпоративных знаний он почти всегда оказывается правильным. Разберём почему.
Что означают буквы
RAG — retrieval-augmented generation, «генерация, дополненная поиском». Название описывает порядок действий буквально.
Сотрудник задаёт вопрос. Система сначала ищет в ваших документах фрагменты, относящиеся к делу. Потом отдаёт их модели вместе с вопросом: вот текст, вот что спросили, ответь по этому тексту. Модель формулирует ответ и указывает, откуда он взят.
Ключевое здесь — что модель не «знает» ваши документы. Она их читает в момент вопроса, как читал бы человек, которому дали нужные страницы. Никаких изменений внутри модели не происходит.
Из этого следуют почти все практические свойства RAG, и хорошие, и плохие.
Чем это отличается от дообучения
Дообучение меняет саму модель. Берётся размеченный набор примеров, арендуются видеокарты, запускается процедура, на выходе — новая версия модели, в которой ваши знания растворены в весах.
Звучит солиднее. На практике для базы знаний это плохой выбор, и вот почему.
Документы меняются, модель — нет. Обновился регламент — при дообучении нужно повторять процедуру целиком. При RAG достаточно переиндексировать изменившийся файл, и ответы поменяются в тот же день. Для знаний, которые живут неделями, а не годами, это решающий довод.
Дообучение не даёт ссылки на источник. Модель выдаёт ответ, но не может показать, откуда он. Для корпоративных знаний это часто неприемлемо: сотрудник должен иметь возможность открыть страницу и убедиться. RAG возвращает ссылку по построению — фрагмент-то был у него в руках.
Разграничить доступ невозможно. Если знания растворены в весах, нельзя сделать так, чтобы одному отделу модель отвечала, а другому нет. В RAG права раздаются на уровне документов, как в обычной файловой системе.
Цена отличается на порядок. Дообучение — это разметка, вычисления и повторение при каждом обновлении. RAG — это разбор документов и поиск.
| Дообучение | RAG | |
|---|---|---|
| Обновление знаний | Повторить процедуру | Переиндексировать файл |
| Ссылка на источник | Нет | Есть |
| Разграничение доступа | Невозможно | По документам |
| Стоимость изменений | Высокая | Низкая |
| Что меняется | Сама модель | Только индекс |
Дообучение остаётся оправданным там, где нужно изменить манеру модели, а не её знания: особый формат ответа, узкая терминология, специфический стиль. Это другая задача, и решают её другие средства.
Где RAG ломается
Честный разговор про RAG обязан включать и это. Три места, где простая схема «нашёл — отдал — ответил» перестаёт работать.
Вопрос сформулирован не теми словами. Сотрудник спрашивает своими словами, а в документе то же самое названо иначе, нередко на другом языке. Простой поиск по смыслу это частично закрывает, но не всегда: если в инструкции написано «превышение допустимого момента затяжки», а спросили «сорвал резьбу», совпадение может не найтись.
Ответ не в тексте, а на картинке. В технической документации значительная часть полезного лежит на схемах соединений, чертежах, скриншотах интерфейсов и таблицах, вставленных картинкой. Система, которая умеет работать только с текстом, честно ответит «не нашлось» — хотя ответ есть, просто нарисован.
Ответа нет вовсе. Самый опасный случай. Поиск что-то нашёл — не то, но похожее. Модель получила фрагмент и по своей природе построила из него правдоподобный ответ. Неправильный ответ, поданный уверенно, вреднее отказа: на него сошлются.
Первые два решаются тем, что поиск перестаёт быть одноходовым: система смотрит, что нашлось, и решает, что делать дальше — переформулировать запрос, взять страницу целиком, открыть рисунок. Такую надстройку обычно называют агентом над документами, и на простой базе знаний разница почти не видна, а на технической документации она решает исход дела.
Третий случай не решается техникой в принципе — его решают проверкой. Отдельно собирается набор вопросов, на которые в документах ответа заведомо нет, и проверяется, что система отказывается отвечать. Отказ в нужный момент — такой же измеримый результат, как правильный ответ.
Что нужно, чтобы начать
Вопреки распространённому ожиданию, начинать надо не с выбора базы данных.
Понять, где лежат документы и в каком они виде. Текстовый PDF и скан страницы — две разные задачи. Сканы решаются, но это отдельная работа, и лучше знать о ней заранее, чем обнаружить в середине проекта.
Оценить, сколько стоит поиск сейчас. Не «сколько у нас документов», а «сколько человек и сколько времени тратят на поиск ответа». Нижней границы по количеству документов нет: если пять человек ежедневно ищут по двадцать минут, окупается и на сотне файлов.
Собрать проверочные вопросы. Несколько сотен реальных вопросов с заранее известными правильными ответами — вместе с теми, кто отвечает на них сейчас. Это самая скучная часть подготовки и самая важная: без неё улучшать систему невозможно, потому что не с чем сравнивать.
Решить вопрос с контуром. Если в документах коммерческая тайна, конструкторская документация или персональные данные, система разворачивается на вашем сервере и наружу не ходит вовсе. Это штатный вариант, а не экзотика.
Три ошибки, которые повторяются
Эти три встречаются чаще остальных вместе взятых — и все три случаются до того, как написана первая строка кода.
Свалить в систему всё подряд. Логика понятна: пусть будет, лишним не будет. На практике лишнее вредит. В общей папке компании годами копятся черновики, устаревшие редакции регламентов, переписка и три версии одного документа с разными правками. Поиск честно находит их все, и система начинает отвечать по отменённой инструкции. Разбор корпуса — что берём, что выбрасываем, какая редакция действующая — почти всегда оказывается длиннее, чем разработка, и почти всегда его не планируют.
Считать качество на глаз. «Задали десять вопросов, ответы хорошие» — это не измерение. Десять вопросов не показывают ни разброса, ни провалов на конкретных типах запросов, ни того, стало ли лучше после правки. Нужен набор в несколько сотен вопросов с зафиксированными ответами, и собирать его должны те, кто знает предметную область, — не разработчики.
Обещать сотрудникам всезнающего помощника. Завышенное ожидание убивает внедрение вернее плохой точности. Система, которая честно отвечает на восемь вопросов из десяти и отказывается на двух, полезна. Система, которую представили как «спросите что угодно», после первого же уверенного вранья теряет доверие целиком — и им перестают пользоваться даже там, где она работает.
Общее у всех трёх — то, что они не про технику. Техническая часть RAG за последние два года стала довольно предсказуемой; проекты спотыкаются о данные, измерение и ожидания.
Что происходит после запуска
RAG — не коробка, которую поставили и забыли. Документы меняются, а вместе с ними должен меняться индекс: обновление корпуса нужно поставить на регулярную основу, иначе система за несколько месяцев тихо разойдётся с действительностью, продолжая отвечать уверенно.
Второе — набор проверочных вопросов живёт вместе с системой. Появился новый тип обращений, который она обрабатывает плохо, — он попадает в набор, и дальше видно, помогла ли правка.
Третье — журнал вопросов. Он показывает, о чём спрашивают на самом деле, и это почти никогда не совпадает с тем, что предполагали при запуске. По нему видно и дыры в самих документах: если десять человек спросили об одном и том же, а ответа в регламентах нет, проблема не в поиске.
Сколько документов — много
Практический потолок выше, чем принято думать. В нашем проекте по документации станков с ЧПУ система работает на библиотеке из 107 руководств общим объёмом более 48 000 страниц — с чертежами, схемами и таблицами-картинками. На наборе из нескольких сотен проверочных вопросов точность ответов составила 94,7%, и весь стек помещается на одной видеокарте: отдельный дата-центр для этого не нужен.
Важнее объёма другое — насколько документы структурированы и насколько к ним применимы одни и те же правила разбора. Сто однотипных регламентов разбираются проще, чем десять документов, каждый со своей вёрсткой.
Мы разрабатываем RAG-агентов для документации компании — от разбора корпуса и набора проверочных вопросов до промышленной версии в закрытом контуре. Подробности одного такого проекта — в разборе кейса.
Связаться: Telegram @xtrueman · info@llmtech.ru · llmtech.ru