ИИ-помощник может получать документы компании и всё равно отвечать невпопад. Катя Пославская, которая занимается RAG-системами и ИИ-агентами в KTS, разобрала, как на ответы влияют состояние базы знаний, разбиение документов и отбор найденных фрагментов. Её главный тезис: по практическому опыту автора, проблема часто возникает ещё до того, как языковая модель начинает составлять ответ.
Что получает модель вместо всей базы
RAG — это подход, при котором перед ответом система ищет сведения в базе знаний и передаёт найденное языковой модели. Для корпоративного помощника такой базой могут быть инструкции и внутренние статьи. Если принцип незнаком, пригодится руководство о том, как устроен RAG.
Пославская описывает знакомый ей разрыв между удачным прототипом на небольшой подборке и работой с полной корпоративной базой. В ней встречаются устаревшие материалы, дубликаты и противоречия. По её словам, успешная работа начинается с актуальных, полных и непротиворечивых данных. Более сложный поиск сам по себе не приводит документы в порядок.
Слишком мелкие фрагменты теряют смысл
Перед поиском большие документы делят на небольшие части — их называют чанками. Здесь важен не только размер: в одном фрагменте должна сохраняться понятная мысль. Разрезать инструкцию посередине формулы и пояснения к ней — значит передать следующему этапу обрывки вместо ответа.
Автор приводит случай с помощником, база которого была разбита на части по 100 токенов — единиц текста, с которыми работает модель. В инструкциях с функциями Excel формулы оказались оторваны от пояснений. По её разбору, именно такая нарезка мешала собрать содержательный ответ, хотя модель и остальные параметры были адекватными.
Для обычных информационных статей на русском Пославская ориентируется примерно на 1000 токенов на фрагмент, а для базы вопросов и ответов — примерно на 200, чтобы вопрос и ответ помещались вместе. Это ориентиры из её практики, а не универсальные настройки. Соседние части она рекомендует делать с перекрытием около 10%, чтобы не терять смысл на границе.
Больше найденного — не обязательно лучше
В качестве отправной точки автор рекомендует гибридный поиск: он сочетает поиск по смыслу с поиском по ключевым словам и терминам. Затем отдельная модель может заново расставить найденные фрагменты по соответствию вопросу.
Но такой отбор имеет пределы. Нужный отрывок может оказаться сразу за границей выбранного списка и не попасть в ответ. А несколько очень похожих фрагментов — занять почти все доступные места. По объяснению Пославской, поиск и последующее переупорядочивание оценивают близость каждого кандидата к вопросу, а не то, насколько кандидаты дополняют друг друга.
Простое увеличение числа фрагментов автор не считает универсальным решением: оно повышает стоимость и время ответа, а также добавляет посторонние сведения. Для общего вопроса о содержимом всей базы это особенно заметное ограничение: модель видит только выбранную часть, а не весь архив.
Когда усложнение оправданно
В классической схеме система один раз ищет информацию и формирует ответ. В агентской — языковая модель сама управляет поиском: выбирает инструменты и решает, нужны ли дополнительные обращения к базе. Пославская предупреждает, что за такую гибкость приходится платить скоростью, стоимостью и более сложным тестированием.
Начинать сразу с агентской схемы она не советует: классический вариант нужен хотя бы как основа для сравнения. В её практике работает и сочетание двух подходов, когда отдельная модель направляет простые и сложные вопросы по разным маршрутам.
Полезный вывод для команды, которая заказывает такого помощника: обсуждать стоит не только выбор языковой модели, но и то, какие именно сведения до неё доходят. Разбор KTS даёт ориентиры для этой диагностики, но не доказывает, что один размер фрагмента или один способ поиска исправит любую корпоративную базу.
