В октябре 2025 ко мне пришёл управляющий партнёр юридической фирмы из Москвы. Контора средняя, 25 человек, специализация - корпоративные споры и сопровождение M&A сделок. Запрос звучал коротко: "У нас 12 тысяч документов за 11 лет, найти что-то реально невозможно, ищем час, не находим, делаем заново. Нужен поиск, который понимает смысл".
Внедрение заняло пять месяцев. Бюджет вышел на 420 тысяч на запуск плюс 32 тысячи ежемесячно на поддержку. Что в итоге работает, что не сработало и почему RAG не серебряная пуля, расскажу по порядку. Пишу для тех, кто думает "а нам тоже надо", и хочет понять, что реально внутри.
С чем пришёл клиент
Юридическая фирма основана в 2013 году. С тех пор накопилось всё, что можно накопить. Договоры (свои шаблоны и подписанные с клиентами), меморандумы, заключения, переписка с регуляторами, материалы по делам, экспертизы, корпоративные документы клиентов, своя внутренняя аналитика по практике. Хранится частично в файловой шаре на корпоративном сервере, частично в почте, частично в личных папках партнёров на ноутбуках. У некоторых старых дел вообще только бумажные сканы, которые в своё время сложили в подвал и потом отсканировали как попало.
Боль номер один. Партнёр готовит позицию по новому корпоративному спору. Помнит, что в 2019 году у них было похожее дело, и там нашли удачную формулировку. Как искать? Внутренний поиск Windows по шаре ищет по именам файлов и кускам внутри, но если документ в PDF без слоя текста, то для поиска он не существует. Имена файлов разные: "Иск_Петров_итог.docx", "petrov_iskovoe_v2.docx", "Финал договор Петров (правки от Маши).docx". Кто эти Петровы, какой из них тот самый, непонятно.
Боль номер два. Помощник юриста за один поиск нужного прецедента из их же архива убивает в среднем 8-15 минут. Иногда полчаса, если документ старый. На команде в 25 человек, где у каждого по 4-7 таких поисков в день, это набегает в 20-40 рабочих часов в день. То есть фактически 2-5 человек на полной занятости заняты поиском по собственному архиву.
Боль номер три. Знание уходит вместе с людьми. Партнёр на пенсии или в другой фирме, а в его делах было что-то ценное. Найти невозможно. Спросить - тоже не у кого.
Почему RAG, а не индексный поиск
Первый вопрос, который я задаю в таких случаях: точно ли нужен ИИ? Иногда хватает нормально настроенного индексного поиска, например ElasticSearch с парсингом документов и нормальной разметкой по типам. Это дешевле и надёжнее.
Здесь не подошло. Запросы юристов почти всегда смысловые, не по точным словам. "Найди мне меморандум, где мы обосновывали недействительность дополнительного соглашения, заключённого после реорганизации". В классическом поиске такой запрос ни во что не превратится. По ключевым словам выпадает 800 документов с упоминанием "дополнительного соглашения". А с RAG-системой выпадают пять самых релевантных, потому что модель понимает смысл запроса.
Кстати, та же история подробно описана в разборе RAG-систем на Хабре: классический поиск работает на точных совпадениях, RAG работает на смысловой близости. Для юристов это критично, потому что одно и то же явление описывается десятью способами.
Если хотите глубже разобраться, чем RAG отличается от файнтюна и когда что выбирать, я писал отдельно: RAG или дообучение, что выбрать. Здесь скажу коротко: для архива из 12 тысяч документов RAG почти всегда правильный выбор. Файнтюн дороже, медленнее и работает хуже на документах, которые меняются.
Этап первый: аудит документов и санитарная зачистка
Первое, что я попросил клиента до начала всех ИИ-работ: дайте мне посмотреть, что у вас за документы и в каком они состоянии. Это заняло три недели и оказалось одной из самых полезных частей всего проекта.
Цифры из аудита получились такие. Изначально клиент говорил "у нас 12 тысяч документов". После того как мы прошлись по всем папкам, выгрузили почту и подсчитали честно, получилось 14 700 файлов. Из них около 1 800 - это были дубли с разными названиями. Примерно 600 - устаревшие версии живых документов (черновики, промежуточные правки). Около 400 - это вообще не документы, а случайно сохранённые скриншоты, картинки из мессенджеров, спам-вложения.
Из реально нужных 11 900 документов формат распределился примерно так. PDF с нормальным текстовым слоем - 4 200. DOCX и DOC - 5 100. Старые DOC из Word 2003 - 600. Сканы PDF без слоя текста - 1 700. Эксели с таблицами - 300. И ещё были HTML-выгрузки из системы документооборота, RTF от старых клиентов, пара десятков ODT.
Со сканами без слоя текста разобрались отдельно. Прогнали через OCR. Здесь была первая болезненная история. Качество сканов оказалось разным. Свежие сканы 2022-2024 годов читались хорошо, точность распознавания за 97%. А вот сканы из подвала, сделанные ещё в 2015 году на потёртом МФУ, давали такую кашу, что часть из них пришлось пересканировать вручную. Около 200 документов сначала прогнали через специализированный OCR для рукописных и плохих сканов, и всё равно процентов 30 текста в них так и осталось мусором. Эти документы мы пометили отдельно как "качество распознавания низкое, проверяйте оригинал".
У меня про эту часть отдельный продукт собран: OCR документов под ИИ. Не первый раз спасает на этапе подготовки.
По дублям. Применили хэширование плюс смысловое сравнение. Если файлы побайтно идентичны - дубль удалили. Если содержание совпадает на 95%+ (разные даты сохранения, разные кодировки) - оставили один, остальные перенесли в архив с пометкой. Если совпадение 70-94% - это, скорее всего, разные версии одного документа, оставили все, но связали логически. Эта работа отняла ещё две недели.
Отдельная история - секретные документы. У клиента есть категория дел, к которым имеют доступ только два партнёра и младший юрист, ведущий конкретное дело. Если эти документы загнать в общий RAG-индекс, любой сотрудник через ИИ-поиск может косвенно вытащить из них фрагменты. Это недопустимо. Мы выделили эти документы в отдельный индекс с ограниченным доступом, к которому подключаются только аккаунты с правами. Это добавило сложности, но без этого проект делать было нельзя.
Этап второй: векторизация и выбор движка
Когда документы готовы и пронумерованы, наступает самое интересное. Их надо нарезать на куски, превратить каждый кусок в вектор и положить в векторную базу.
Нарезка - это отдельное искусство. Если резать слишком мелко, теряется контекст. Если слишком крупно, поиск становится размытым. Для юридических документов мы остановились на чанках по 800-1200 символов с перекрытием 150 символов между соседними кусками. Договоры режутся по пунктам, меморандумы - по смысловым абзацам, иски - по разделам "обстоятельства - доводы - требования". Каждому чанку добавили метаданные: имя документа, тип, дата, ответственный партнёр, статус дела.
На каждый чанк выпускается эмбеддинг - длинный вектор чисел, в котором закодирован смысл текста. Мы использовали российскую эмбеддинг-модель, так как часть документов содержит специфическую юридическую лексику и латиницу из англоязычных контрактов одновременно. Зарубежные модели на смешанной лексике хуже работают. Стоимость векторизации 11 900 документов вышла около 18 тысяч рублей разовых затрат на API и около 40 часов работы инженера на подготовку и прогон.
Выбор векторной базы оказался отдельной развилкой. Кандидатов рассматривал три. Qdrant, Milvus и pgvector. На сравнительном обзоре векторных БД на Хабре хорошо разобран этот выбор, повторяться смысла нет.
Кратко по моей логике. Milvus - это инфраструктура для гигантских объёмов, миллиарды векторов, нужен Kubernetes и команда DevOps. Для 12 тысяч документов с 60-80 тысячами чанков это перебор. pgvector хорош, если у клиента уже работает PostgreSQL и команда умеет с ним обращаться. У моего клиента вообще не было своих разработчиков, и Postgres никто не настраивал. Qdrant написан на Rust, работает быстро, разворачивается одним файлом, отлично умеет фильтровать по метаданным (а это для юристов критично: "ищи только в документах за 2020-2023 годы по корпоративным спорам"). Выбрали Qdrant.
Поставили self-hosted на сервер клиента. Сервер арендовали у российского хостера, конфигурация без вакханалии: 8 ядер, 32 ГБ памяти, 500 ГБ NVMe. Стоит 14 тысяч рублей в месяц. Облачный Qdrant Cloud вышел бы дешевле, но у клиента жёсткое требование "ничего не должно покидать наш контур", и я их понимаю.
Этап третий: интерфейс, к которому будут привыкать люди
Технология без интерфейса бесполезна. Если поиск через RAG надо запускать из командной строки или возиться с какими-то техническими интерфейсами, юристы им пользоваться не будут. Это закон, проверенный на десяти проектах.
Мы собрали простой веб-интерфейс. Сверху строка поиска (то есть запроса), как у Гугла. Ниже два режима: "Просто найди документы" и "Найди документы и сделай выжимку по ним". Первый режим возвращает 5-7 самых релевантных документов с прямыми ссылками на оригиналы и подсвеченными цитатами. Второй режим дополнительно прогоняет найденные куски через LLM, которая составляет ответ на запрос со сносками "это из документа такого-то, страница такая-то".
Важный момент: ответ от модели всегда сопровождается списком источников. Никаких "ИИ так считает" без указания, откуда. Юристы первым делом проверяют первоисточник. Без этого они системе доверять не будут.
Сбоку панелька с фильтрами. Тип документа, дата, ответственный партнёр, статус дела, метка конфиденциальности. Эти фильтры комбинируются с семантическим поиском. Можно искать "формулировки про возмещение убытков по неосновательному обогащению" только в документах партнёра Иванова за 2020-2022 годы.
Веб-интерфейс мы собрали довольно быстро, потому что у меня заготовка под такие задачи есть. Подключение к Qdrant, ранкер, генератор ответов на основе российской LLM, прокрутка прав доступа через корпоративный SSO. На всё про всё ушло около трёх недель работы инженера и пару дней дизайна.
Этап четвёртый: разграничение прав и аудит
Юристы работают с секретными данными. У них есть категории дел, которые открыты не всем. Я уже упоминал, что секретные документы выделили в отдельный индекс. Но это только полдела. Внутри обычного индекса тоже есть градации.
Помощник юриста не должен видеть документы стратегических сделок партнёрской верхушки. Партнёр одного клиента не должен видеть документы другого клиента, если только это специально не разрешено (например, в спорах между связанными лицами). У каждого документа в RAG появились метаданные с тегами доступа. При запросе система проверяет, кто спрашивает, и фильтрует результаты ещё до выдачи ответа.
Это сделать оказалось сложнее, чем казалось вначале. Потому что у клиента не было нормальной структуры прав. На файловой шаре права раздавались на ходу, копировались с предыдущих папок, никто давно не проверял, у кого к чему есть доступ. Мы фактически вместе с управляющим партнёром заново описали матрицу прав: кто, к каким категориям дел, в какой роли. Это растянулось на десять дней встреч, и я честно сказал клиенту: половина этой работы вам нужна была независимо от RAG, теперь хоть появился повод сделать.
Дополнительно настроили аудит-лог. Каждый запрос пишется: кто, когда, что искал, какие документы получил. Это нужно и для безопасности (если что-то утечёт, понятно, кто смотрел), и для аналитики (партнёр видит, какие документы запрашивают чаще всего, и понимает, что в фирме востребовано).
Этап пятый: обучение пользователей
Самый недооценённый этап во всех ИИ-проектах. Запустили красивую систему, повесили её на портал, написали инструкцию. Через две недели пришли, проверили логи - пользуются три человека из 25.
Если хотите, чтобы люди реально пользовались, надо учить. Лучше всего работает формат коротких встреч по 30 минут с конкретной командой и реальными примерами. Не "вот тут поле ввода, нажмите кнопку", а "вот ваш реальный случай за прошлую неделю, посмотрите, как это найти за 20 секунд через систему".
Мы провели четыре такие встречи. Старшие партнёры, младшие юристы, помощники, секретариат. У каждой группы свои сценарии. Партнёры ищут прецеденты и формулировки. Младшие юристы готовят первичные документы и им нужны шаблоны. Помощники готовят подборки материалов по делам. Секретариат проверяет, отправляли ли мы уже клиенту что-то похожее.
Из этих встреч пришли неожиданные пожелания. Партнёры просили "сравни мне эти два меморандума и подсвети различия в позициях". Помощники просили "сгруппируй документы по делу X в хронологический список". Часть этих фич мы потом добавили, часть отложили.
Через два месяца после обучения активные пользователи - 22 человека из 25. Двое почти не используют (один из них через полгода вообще уволился, что не связано с RAG). Один партнёр пользуется только через своего помощника, что нормально и ожидаемо.
Что не сработало и от чего отказались
Изначально хотели затащить в RAG вообще всё. Включая шаблоны типовых документов и FAQ по внутренним процессам ("как оформить отпуск", "куда сдать командировочные"). Это была ошибка.
Шаблоны типовых договоров в RAG-системе работают плохо. Когда юрист ищет "договор поставки с отсрочкой", он не хочет, чтобы ему ИИ написал свой вариант на основе пяти разных образцов. Он хочет открыть конкретный шаблон, который партнёры утвердили как стандартный, и работать с ним. Шаблоны - это структурированные документы, и им место в Notion или внутренней вики с понятной навигацией. Мы вытащили шаблоны из RAG отдельно, выложили в Notion с тегами и поиском по полям. Это работает в десять раз лучше для этой задачи.
Внутренний FAQ ("как оформить отпуск") - тоже не задача для RAG. У клиента таких документов было всего 30 штук, и они меняются редко. Поставили обычную базу знаний с поиском по тегам. RAG здесь оверкилл.
Ещё одно, от чего отказались: автоматическая генерация документов по запросу ("составь мне иск на основе этих материалов"). На пилоте попробовали. Качество вышло такое, что юристы переписывали 80% автоматического текста, и быстрее было написать с нуля. К тому же риски ошибок в формулировках в юридическом тексте критичные. От этой идеи отказались. RAG остался поисковым ассистентом, а не автогенератором.
В качестве отдельного эксперимента пробовали привязать RAG-результаты к таск-менеджеру (Jira), чтобы при создании задачи по новому делу автоматически подтягивались похожие старые дела. Заработало неплохо, но требует много ручной разметки тегами и пока на паузе. Возможно, доделаем во второй очереди.
Метрики и окупаемость
Главное, ради чего всё затевалось.
Среднее время поиска документа до внедрения: измеряли через хронометраж за две недели на десяти сотрудниках. Получилось 8-15 минут, среднее 11 минут. Иногда вообще не находили и решали без него.
После внедрения: 12-30 секунд от ввода запроса до открытия нужного документа. С учётом того, что юристу всё равно надо ознакомиться с найденным, общее время "нашёл и понял, что использовать" сократилось до 1-3 минут. Это в 4-10 раз быстрее.
Считаем экономику. 25 человек, в среднем 5 поисков в день у каждого, экономия 8-10 минут на поиск. Получается 1000-1250 человеко-минут в день, или 17-21 час. На рабочей ставке среднего юриста по Москве (хорошие юр.фирмы платят 200-350 тысяч в месяц, час старшего юриста для клиента биллится в 8-15 тысяч) экономия выходит ощутимая. Если считать по внутренней ставке (без наценки на клиента), экономия 80-120 тысяч в неделю. По биллингу клиентам они теперь продают больше часов с одной и той же командой.
Окупаемость на старте: 420 тысяч за внедрение. Ежемесячные расходы: 32 тысячи (хостинг сервера 14, обслуживание 18). При самой консервативной оценке экономии в 280 тысяч в месяц на ставках команды, окупаемость на четвёртый месяц. Если считать по биллингу (что клиент стал выдавать больше работы), быстрее.
На похожем кейсе у CROC система работает на тысячах сотрудников и срок внедрения растянулся почти на год. На 25 сотрудниках всё проходит в разы быстрее, но и польза от каждого внедрения скромнее по абсолюту.
Подводные камни, о которых надо знать
Если читаете и думаете "хочу себе такое", ниже список того, что обязательно вылезет.
Документы плохого качества. Если у вас половина архива это сканы из 2015 года или DOC из Word 2003, готовьтесь к расходам на OCR и реставрацию. Это от 50 до 150 тысяч на средний архив, в зависимости от состояния.
Дубли и версионность. Без чистки на этапе аудита RAG будет находить вам пять копий одного документа, и пользователь начнёт ругаться. Чистка обязательна.
Права доступа. В большинстве компаний матрица прав никак не описана. Внедрение RAG заставит её описать. Это полезно само по себе, но это месяц работы.
Российская специфика моделей. Зарубежные эмбеддинг-модели на чистом русском работают неплохо, на смешанном (юридический русский с английскими включениями договоров) хуже. Без тестирования на ваших данных не выбирайте модель.
Контур безопасности. Если ваши документы коммерческая или адвокатская тайна, гонять их через зарубежное облако нельзя. Локальная установка дороже на 30-50% и требует серверной мощности. У моего клиента это всё равно было обязательным требованием.
LLM на бэкенде. Тут отдельная тема. Для генерации ответов нужна модель. Можно подключать GigaChat или YandexGPT по API, это от 8 до 30 тысяч в месяц на средний объём запросов. Можно ставить локальную LLM на свой сервер, это требует видеокарт и инженера, который умеет с ними. У меня про оба варианта отдельный продукт: локальные LLM на вашем сервере. Какой путь выбрать, зависит от чувствительности данных.
Цены на запуск и поддержку, без приукрашиваний
На запуск среднего корпоративного RAG (5-15 тысяч документов, 20-50 пользователей, базовое разграничение прав, веб-интерфейс) бюджет от 320 до 500 тысяч рублей. В моём кейсе вышло 420, и это считаю нижней границей честной цены. Если кто-то предлагает за 150 тысяч, либо не учтена половина работ по аудиту, либо качество будет ниже.
Что входит в эту сумму: аудит документов и подготовка данных, выбор стека, развёртывание, написание парсеров под форматы клиента, OCR-обработка сканов (если не более 500 страниц), разработка веб-интерфейса с авторизацией, настройка прав доступа, обучение пользователей. Расходы клиента на свою инфраструктуру (сервер, OCR пакетами) отдельно, обычно 20-40 тысяч на старте.
Ежемесячная поддержка: от 25 до 40 тысяч в месяц. Что туда входит: мониторинг работы системы, обновление индекса при добавлении новых документов, дообучение под новые запросы пользователей, фикс мелких багов, аудит логов. Если документы добавляются массово (например, выгружаете подшивку какого-то нового крупного дела разово), это считается отдельно.
По обзору рынка RAG-систем в РФ за 2026 год цены такие. Пилоты от 500 тысяч до 1.5 миллиона. Полноценный production от 3 до 10 миллионов. Поддержка 150-500 тысяч в месяц. Мой кейс попадает ближе к нижнему пилотному порогу, потому что задача была локальная, а не корпоративная на 500+ человек. Если у вас огромная компания и десятки тысяч пользователей, ценник другой и сроки тоже.
Если у вас задача поменьше моей (300-500 документов, команда из 5-7 человек), готовьте 180-280 тысяч. Если задача масштабнее, считайте кратно. По моему опыту самые честные оценки получаются после двух-трёх часов разговора с заказчиком, когда понятно, что лежит в шкафу.
Подробнее по тарифам и сценариям моих RAG-проектов: RAG-системы под ключ. По смежной теме коннекторов к корпоративным системам: MCP-серверы для бизнеса.
Что я понял за пять месяцев
RAG работает, но это не "загрузил папку, получил поиск". Это проект на стыке data engineering, безопасности, UX и бизнес-аналитики. Большая часть бюджета уходит не на нейросетку, а на подготовку данных и интеграцию. Это та же история, что в обзоре рынка: 60-70% бюджета на data prep, безопасность и оценку качества. Я подписываюсь под каждым словом.
Юридическая фирма из моего кейса сейчас, через семь месяцев после запуска, использует систему ежедневно. Управляющий партнёр говорит, что забрать её обратно уже невозможно: "если выключите, неделю не будем работать, пока не привыкнем заново". На прошлой неделе они подписали договор на расширение - добавляем еще один индекс с архивом писем за 8 лет и интерфейс с интеграцией в их корпоративный мессенджер. Это уже вторая очередь, отдельный бюджет.
Что советую тем, кто думает у себя сделать. Сначала честно посчитайте, сколько времени теряете на поиск и сколько это стоит. Если меньше 100 тысяч в месяц - подождите, RAG скорее всего не окупится за разумные сроки. Если больше - имеет смысл считать дальше. Дальше идите к подрядчику или собирайте собственную команду. Сами через GitHub-туториалы соберёте за выходные демо, которое в проде упадёт на пятый день. Я такое видел три раза, и каждый раз приходил восстанавливать.
И последнее. Не пытайтесь засунуть в RAG вообще всё. Будут шаблоны, FAQ, инструкции, картинки. Им место в других системах. RAG для смыслового поиска по тексту, и в этой роли он бесподобен. В роли универсального хранилища он только захлебнётся.
Если нужно сначала разобраться в основах, из каких блоков состоит такая система и как считать бюджет, это есть в разборе что такое RAG-система и сколько стоит внедрение.
Близкие темы
RAG-системы под ключ - продуктовая страница с моими сценариями и ценами. MCP-серверы для бизнеса - как связывать RAG с другими корпоративными системами. Локальные LLM на своём сервере - вариант для тех, кому в принципе нельзя в облако. RAG или дообучение модели, что выбрать - разбор, когда что лучше работает. OCR документов с ИИ - первая ступенька любого RAG-проекта на старых архивах.
Источники
- Хабр - что такое RAG, полный разбор от теории до продакшена
- Хабр, CROC - RAG вместо GPT, кейс внутреннего ассистента CAFY
- Хабр, OTUS - Law and Practice Ensemble RAG для юридических задач
- Хабр - выбор векторной БД для AI-агентов и RAG
- Хабр - документный хаос и RAG-система с Qdrant
- Хабр - RAG или умный поиск по документам, как это работает
- AI Market Rating - рынок RAG-систем РФ 2026, цены и кейсы
- Хабр, Рунити - построение корпоративного RAG-ассистента
- CNews - RAG-поиск в новом релизе 1С Itilium
- Qdrant - официальные тарифы Qdrant Cloud
У вас архив документов, который никто не находит?
Опишите задачу: сколько документов, какие форматы, сколько человек ищут. Дам оценку сроков и бюджета за 24 часа. Бесплатно, до подписания.
Обсудить задачу
Добавить комментарий