Двигатель с шестью полюсами — Миф о десяти строках кода

Расследование в шести частях о причинах, по которым корпоративный чат-бот, который вам продали, продолжает выдумывать — и о другом направлении, которое кто-то начал прокладывать в начале 2026 года.

Расследование в шести частях о причинах, по которым корпоративный чат-бот, который вам продали, продолжает выдумывать — и о другом направлении, которое кто-то начал прокладывать в начале 2026 года.

Введение — Двигатель с восемью полюсами (но на самом деле с шестью)

Милан, март 2026 г. Менеджер открывает внутренний корпоративный чат-бот, из тех, что «собрали за две недели» из IT-отдела с большим энтузиазмом и небольшим недоверием. Очень простой вопрос: «Сколько полюсов у двигателя CMP40M?». Чат-бот отвечает со всей уверенностью, которую умеют демонстрировать большие языковые модели: «Двигатель CMP40M имеет восемь полюсов.»

Неверно. У него шесть. Правильный ответ не содержался в каталоге из 422 страниц, который кто-то, месяцы назад, с полной уверенностью загрузил в векторную базу данных, убежденный, что отныне система "будет знать все". Этих данных просто не было в каталоге. Они находились в PDF-файле, прикрепленном к электронному письму от технических специалистов SEW, и хранились в папке, которую никто не удосужился индексировать.

Эта сцена, с вариациями в зависимости от отрасли и диалекта, повторяется в сотнях итальянских офисов. Обещание было простым и соблазнительным: предоставьте вашему AI-ассистенту все корпоративные документы, и он сможет ответить на любой вопрос по ним. Реальность гораздо более прозаична: чат-бот читает, но не понимает, ищет, но не находит, и когда не находит — вместо того чтобы сказать об этом — выдумывает. Выдумывает плавно, с идеальной грамматикой, с правдоподобными цифрами. Что гораздо хуже, чем не отвечать.

С конца 2024 года до начала 2026 года мы потратили месяцы на вскрытие этих неудач. Не для того, чтобы разжигать споры, а чтобы понять одну вещь: почему такая линейная идея — "дайте ему документы, а затем задавайте вопросы" — становится такой сложной, когда она сходит со сцены демонстрации и попадает в комнату с реальными серверами.

Это шестиглавое расследование рассказывает о том, что мы обнаружили: тихие ошибки, удалявшие целые каталоги, облачные переранжировщики с неправильными оценками, галлюцинации, возникшие не из-за модели, а из-за загрязненных данных, накопленных годами ранее, счета, которые делали каждый запрос дороже его стоимости, и "популярные" фреймворки, обещающие все в десять строк кода при условии, что от них не требуют слишком многого. И в последней главе — другое направление, которое кто-то начал тихо прокладывать в начале 2026 года — архитектура, в которой стратегия поиска перестает быть кодом и становится документом, который любой сотрудник компании может читать и изменять.

Каждая глава является самостоятельной. Если вы хотите начать с истории о 342 исчезнувших таблицах или с истории о лживом переранжировщике, вы можете сделать это. Но в целом рассказ имеет мораль, которая проявляется только в конце: корпоративный RAG — этот технический акроним, обозначающий Retrieval-Augmented Generation, то есть "генерируй ответы, основываясь на документах, которые ты сначала извлекаешь" — еще не готовый продукт. Это граница. И как и все границы, до сих пор о ней рассказывали в основном продавцы. Пришло время послушать и тех, кто жил внутри.

Глава 1 — Миф о десяти строках кода

Слайд идентичен на каждой конференции по ИИ, начиная с 2023 года: "Ваш корпоративный помощник по документам в 10 строках кода." Под заголовком — блок Python в пастельных тонах, демонстрирующий библиотеку с открытым исходным кодом — обычно одну из известных американских, название которой вызывает ассоциации с цепями деревьев или тибетскими ламами — которая загружает PDF-файлы, разбивает их на части, вставляет в векторную базу данных и запрашивает с помощью языковой модели. За пять минут у вас есть чат-бот. За пять минут — аплодисменты. За пять минут итальянская компания среднего размера убеждается, что проблема решена, и что ее IT-отдел справится с этим за две недели.

Проблема — о которой этот слайд не говорит — заключается в том, что демонстрация построена на трех хорошо отформатированных PDF-файлах, вопросе, специально подобранном для соответствия содержанию, сцене без реальной задержки и докладчике, который протестировал все это двадцать семь раз, прежде чем подняться на сцену. В реальности, корпоративные документы — это геологическая катастрофа: сканы сканов, таблицы, перекрывающие текст, сноски, вклинивающиеся в абзацы, буквенно-цифровые коды типа "RH1M", которые чанкер разрезает пополам, принимая их за слова, изображения, содержащие семьдесят процентов полезной информации, но которые никто не извлекает, и макеты, настолько креативные, что требуют археолога, а не парсера.

RAG — это идея, лежащая в основе — отличная идея. Возьмите вопрос пользователя, найдите в своем архиве наиболее релевантные документы, передайте их языковой модели и получите ответ, основанный на этих документах. Теоретически, это элегантно решает проблему галлюцинаций: модели больше не нужно "знать" ответ, ему нужно только "прочитать" его в предоставленных вами фрагментах. На практике каждое звено цепи — чанкинг, эмбеддинг, поиск, повторный ранжирование, финальная генерация — имеет свои способы сломаться, и поломка редко проявляется как видимая ошибка. Она проявляется как слегка неверный ответ. Затем как совершенно неверный ответ. Затем как менеджер, который задается вопросом, почему он платит за систему, которая знает меньше, чем стажер.

Фреймворки с открытым исходным кодом, популяризировавшие RAG, созданы для демонстрации, а не для производства. Это элегантные цепочки абстракций, в которых каждый слой скрывает невысказанное предположение: что ваши PDF-файлы имеют приличное распознавание текста, что ваши фотографии уже были описаны, что ваши таблицы соответствуют определенной конвенции, что модель внедрения действительно говорит на вашем языке (спойлер: многие хорошо говорят только на английском), что ваш архив уже очищен от дубликатов. Когда одно из этих предположений не выполняется — а хотя бы одно не выполняется всегда, почти всегда три — система не перестает работать. Хуже того: она перестает работать хорошо, но продолжает давать ответы. Беглые, уверенные, и часто оторванные от реальности.

Есть фраза, которая ходит среди тех, кто профессионально занимается созданием этих систем, и которую вы никогда не прочтете в обучающих материалах: "RAG легко сделать, и сложно сделать хорошо." Между первым демо и производственным сервисом лежит пропасть, которую нельзя преодолеть, просто добавив GPU или сменив модель. Ее можно преодолеть, поняв одну неудобную вещь: когда вы строите корпоративный RAG, вы не пишете код. Вы проектируете небольшой, упрямый поисковый движок, настроенный на ваши документы, со всеми редакционными решениями, которые это влечет за собой — что является шумом, что сигналом, что нужно индексировать дважды, а что выбросить. Просто в обучающих материалах из десяти строк эти решения принимаются за вас один раз, кем-то, кто никогда не видел ваших документов. И они почти всегда неправильные для вашего случая.