RAG в агросекторе: как устроена система, которая находит нужный регламент за секунды вместо часов

Агрохолдинги работают с тысячами страниц нормативной документации — СанПиН, регламенты применения СЗР, технические паспорта удобрений. Агрономы тратят до 30% рабочего времени на поиск нужного пункта в этом массиве. RAG-система решает задачу за секунды, но её архитектура для агросектора отличается от типовых решений. Разбираем, как это устроено и где подводные камни.

Почему стандартные решения не работают в агросекторе

Типичный чат-бот для бизнеса построен на FAQ-базе: вопрос → заготовленный ответ. Для интернет-магазина или банковской поддержки этого достаточно. Для агрохолдинга — нет.

Причина в специфике документации. Агроном оперирует не типовыми вопросами, а контекстно-зависимыми запросами: «допустимая норма внесения глифосата для озимой пшеницы на чернозёме при температуре выше 25°C». Ответ зависит от пересечения нескольких документов — регламента применения СЗР, технического паспорта препарата и действующих санитарных норм.

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

Retrieval-Augmented Generation решает обе проблемы: система ищет релевантные фрагменты в реальных документах компании и генерирует ответ на их основе, со ссылкой на источник. Агроном получает не абстрактную рекомендацию, а конкретный пункт конкретного регламента.

Задача: масштаб и боль

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

Холдинг с посевными площадями от 50 000 га и штатом агрономов в 30–60 человек оперирует документационной базой в 800–1 500 документов. Это регламенты применения средств защиты растений, технические паспорта удобрений, актуальные СанПиН, внутренние инструкции, протоколы полевых испытаний. Документы обновляются — новые редакции СанПиН выходят несколько раз в год, производители меняют рекомендации по препаратам.

Агроном в поле сталкивается с конкретной ситуацией — допустим, нетипичная реакция культуры на обработку — и ему нужно быстро найти: совместим ли препарат A с препаратом B, каков период ожидания, не превышена ли допустимая кратность обработок. Сейчас это ручной поиск по PDF-файлам, звонки коллегам, обращения к главному агроному.

По нашим оценкам, на такие консультации уходит 8–12 часов в неделю на одного специалиста в пиковый сезон. Умножьте на штат — и получите сотни человеко-часов, которые агрономы тратят не на агрономию, а на поиск информации.

Архитектура RAG-системы для работы с нормативной документацией

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

Загрузка и предобработка документов → Chunking с учётом структуры → Генерация embeddings → Индексация в векторном хранилище → Гибридный retrieval → Генерация ответа с цитированием

Каждый этап имеет нюансы, которые отличают эту систему от «типового RAG по туториалу».

Индексация: от PDF с таблицами до семантического поиска

Главная техническая сложность агродокументации — формат. Регламенты применения СЗР содержат многоуровневые таблицы с дозировками, привязанными к культуре, фазе развития, типу почвы. СанПиН — это юридический текст со ссылками между пунктами. Технические паспорта удобрений часто приходят в виде сканов.

Стандартный подход «разбить PDF на чанки по 500 токенов» здесь ломается. Таблица, разрезанная пополам, теряет смысл — строка с дозировкой без заголовка столбца бесполезна.

Что мы применили на практике:

• Структурный парсинг вместо простого текстового извлечения. Для таблиц — отдельный pipeline с сохранением связи «заголовок столбца → значение ячейки → заголовок строки». Каждая строка таблицы превращается в самодостаточное утверждение: «Норма расхода препарата X для культуры Y составляет Z л/га».
• OCR с постобработкой для сканированных документов. Tesseract + ручная верификация на выборке. Точность OCR на типичных агродокументах — около 92–95%, что недостаточно для цифр дозировок. Поэтому критические числовые значения проходят дополнительную валидацию.
• Метаданные чанка: тип документа, дата редакции, область применения. Это позволяет фильтровать результаты — если агроном спрашивает про озимую пшеницу, система не будет подтягивать регламенты для кукурузы.
• Версионирование: при обновлении СанПиН или регламента старая версия помечается как архивная, новая индексируется автоматически. Система всегда отвечает по актуальной редакции, но может показать историю изменений.

Для embeddings мы использовали модели, хорошо работающие с русскоязычными техническими текстами. Тестировали multilingual-e5-large и E5-mistral — для агрономической терминологии E5-large показал лучший recall при меньших вычислительных затратах.

Векторное хранилище — Qdrant. Выбор обусловлен поддержкой фильтрации по метаданным (нужно для ограничения поиска по типу документа и дате актуальности) и хорошей производительностью на объёмах до 500 000 чанков.

Retrieval: гибридный поиск под запросы агронома

Чисто семантический поиск плохо работает с агрономическими запросами. Причина — высокая плотность специфических терминов. «Метрибузин» и «Зенкор» — это одно и то же (действующее вещество и торговое название), но семантически они далеки друг от друга. «ПДК нитратов» — устойчивый термин, и поиск по смыслу может подтянуть нерелевантные документы про другие ПДК.

Решение — гибридный поиск, сочетающий семантический (по embeddings) и ключевой (BM25). Для названий препаратов, действующих веществ и стандартных аббревиатур (ПДК, МДУ, СЗР) ключевой поиск надёжнее. Для сложных контекстных запросов — семантический.

На практике это реализуется через reciprocal rank fusion: результаты обоих поисков объединяются с весами. Мы подобрали оптимальное соотношение 0.6 (semantic) / 0.4 (keyword) для агрономических запросов — при этом для запросов, содержащих конкретные названия препаратов, вес ключевого поиска автоматически повышается.

Примеры запросов, на которых тестировали:

• «Период ожидания после обработки метрибузином на картофеле» → система находит техпаспорт Зенкора и регламент применения, выдаёт конкретное значение в днях.
• «Совместимость фунгицида X и инсектицида Y в баковой смеси» → поиск по таблицам совместимости и примечаниям в техпаспортах обоих препаратов.
• «Нормы СанПиН по содержанию нитратов в столовой свёкле» → точная выдержка из действующего СанПиН с номером пункта.

Порог релевантности (relevance threshold) настроен жёстко: если ни один чанк не набирает score выше 0.72, система отвечает «Не удалось найти достоверную информацию по вашему запросу» вместо генерации ответа. Для задач с дозировками и нормативами лучше не ответить, чем ответить неточно.

Подводные камни: что ломается и как чинить

Этот раздел — то, что обычно не попадает в статьи про внедрение ИИ. Но именно здесь скрыта разница между демо и рабочей системой.

Галлюцинации в цифрах

LLM уверенно генерирует текст, но с числами обращается вольно. В контексте агрономии это критично: разница между 0.5 л/га и 5 л/га — это разница между нормой и уничтоженным полем.

Мы добавили слой валидации: если в ответе есть числовые значения, система сопоставляет их с числами из найденных чанков. При расхождении — ответ блокируется и передаётся с пометкой «требует проверки». По нашим тестам, это отсекает около 3–4% ответов, которые содержали бы искажённые цифры.

Дополнительная мера — обязательное цитирование. Каждый ответ содержит ссылку на конкретный документ, страницу и пункт. Агроном видит не только ответ, но и первоисточник, и может верифицировать за 10 секунд вместо 10 минут.

Качество OCR на старых документах

Часть нормативной базы существует только в виде сканов — некоторые внутренние инструкции, старые редакции регламентов. OCR на таких документах даёт ошибки в цифрах и специальных символах. «1,2 л/га» может превратиться в «12 л/га» или «1.2 п/га».

Решение: для документов с OCR-confidence ниже порога система помечает ответ как «основан на документе с возможными ошибками распознавания — проверьте оригинал». Параллельно запускается процесс ручной верификации проблемных документов.

Сопротивление пользователей

Техническая задача часто проще организационной. Опытные агрономы с 20-летним стажем не доверяют «роботу» — и это рациональное поведение. Они знают цену ошибки.

Что работает:

• Прозрачность: система показывает источник каждого ответа. Это не чёрный ящик.
• Режим помощника, а не замены: система позиционируется как ускоренный поиск по документам, а не как «ИИ-агроном».
• Пилот на добровольцах: первые 2–4 недели системой пользуются те, кто сам захотел попробовать. Их позитивный опыт убеждает остальных лучше любых презентаций.
• Обратная связь: кнопки «ответ полезен / не полезен» на каждом ответе. Данные используются для доработки — и агроном видит, что его мнение влияет на систему.

По опыту, критическая масса для органического принятия — 30–40% команды. После этого остальные подключаются сами, потому что коллеги находят ответы быстрее.

Ожидаемые результаты: реалистичные метрики

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

Время на консультацию. При ручном поиске агроном тратит 15–40 минут на один запрос (зависит от сложности и знакомства с документацией). RAG-система выдаёт ответ за 8–15 секунд. Сокращение времени на 60–70% — реалистичная метрика для систем с качественно подготовленной базой.

Точность ответов. На нашей тестовой выборке из 200 вопросов по агрономическим регламентам система показала точность 91–94% (ответ полностью корректен и подтверждён источником). 4–6% ответов — частично корректны (правильная информация, но неполная). 2–3% — отказ от ответа (что лучше, чем неправильный ответ).

Экономика. Допустим, 40 агрономов тратят на поиск по документации в среднем 8 часов в неделю. При сокращении на 65% высвобождается ~210 человеко-часов в неделю, или ~10 900 часов в год. При ставке специалиста 800–1 500 руб./час экономия составляет 8,7–16,3 млн руб. в год. Стоимость разработки и поддержки RAG-системы такого масштаба — 3–6 млн руб. в первый год (включая разработку, инфраструктуру и токены LLM). Окупаемость — 4–8 месяцев.

Стоимость токенов для генерации — около 40–80 тыс. руб./мес при 500–800 запросах в день, в зависимости от выбранной модели и длины контекста.

Когда RAG оправдан: чек-лист для производственных компаний

RAG — не универсальное решение. Вот конкретные критерии, по которым можно оценить, нужен ли он вашей компании.

RAG даст результат, если:

• Объём документации превышает 500 страниц и продолжает расти
• Специалисты тратят более 5 часов в неделю на поиск информации в документах
• Запросы контекстно-зависимые — ответ зависит от пересечения нескольких документов
• Критична точность: ошибка в ответе стоит дороже, чем отсутствие ответа
• Документы регулярно обновляются (нормативы, регламенты, стандарты)
• Есть хотя бы 50 сотрудников, которые работают с этой документацией

RAG не нужен, если:

• Документация статична и умещается в 100 страниц — хватит хорошего поиска по Confluence
• Запросы типовые и повторяющиеся — FAQ-бот справится дешевле
• Нет требований к точности цитирования источника
• Команда — 5 человек, которые и так всё помнят наизусть

Честный ответ «вам не нужен RAG» экономит обеим сторонам месяцы и бюджеты. Не каждая задача требует LLM — иногда достаточно полнотекстового поиска с фасетной фильтрацией.

Где ещё работает этот подход

Агросектор — нестандартная ниша для RAG, но паттерн универсален. Любая отрасль с объёмной, обновляемой нормативной базой и специалистами, которые в ней ежедневно ищут информацию, — кандидат на такое решение.

Строительство: СНиП, ГОСТ, своды правил. Инженер-проектировщик проверяет соответствие нормам — те же контекстно-зависимые запросы, та же потребность в точном цитировании.

Фармацевтика: GMP-регламенты, инструкции по применению, протоколы клинических испытаний. Цена ошибки ещё выше, чем в агросекторе.

Энергетика: ПУЭ (Правила устройства электроустановок) — более 1 000 страниц нормативов, с которыми работают ежедневно. Добавьте РД, СТО и внутренние стандарты — и объём документации сопоставим с агрохолдингом.

Госсектор: регламенты предоставления услуг, нормативные акты, административные процедуры.

Архитектура во всех случаях идентична на 70–80%. Отличия — в предобработке документов (у каждой отрасли своя структура) и настройке retrieval (специфика терминологии и запросов). Это значит, что отработанный pipeline переносится в новую отрасль за недели, а не месяцы.

Вместо итога

RAG в агросекторе — пример того, как технология, ассоциирующаяся с юристами и медиками, решает вполне приземлённую задачу: помочь агроному быстро найти нужный пункт в регламенте, не перелопачивая тысячу страниц PDF. Архитектура не тривиальна — таблицы, OCR, отраслевая терминология требуют отдельных решений. Но ROI считается в конкретных рублях и человеко-часах, а окупаемость измеряется месяцами.

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

---

Подписывайтесь на наш канал: @vibelogia

Поделимся опытом

hello@vibelab.ru

8 800 201 85 68

Написать в Telegram