чанкинг

что это

когда документы загружают в rag-систему, их не кладут целиком — режут на фрагменты, чанки. поиск потом находит не «регламент на 40 страниц», а конкретный кусок про возвраты. аналогия: разделать тушу перед заморозкой. можно заморозить целиком, но когда понадобится стейк — придётся размораживать всё. нарезал правильно — достаёшь ровно нужное.

вся хитрость в том, где резать. порезали посреди таблицы — в одном чанке шапка, в другом цифры, и поиск находит бессмысленные половинки. слишком крупно — в кусок попадает лишнее и путает модель. слишком мелко — теряется контекст: «пункт 4.2 отменяет предыдущий» без пункта 4.1 рядом.

зачем это бизнесу

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

о чём спросить подрядчика

• «как вы режете наши документы и почему именно так?» — правильный ответ привязан к структуре ваших документов. ответ «стандартно, по 1000 символов» означает, что ваши таблицы и разделы никто не смотрел.
• «что происходит с таблицами, сканами и колонтитулами?» — именно они превращаются в мусорные чанки. кто с этим работал — расскажет, как обрабатывает; кто нет — впервые задумается на созвоне.