Стратегия как документ — Седьмая глава

Глава 6 — Стратегия как документ, а не как код

Мы подходим к инсайту, который, в рассказах тех, кто строил RAG с 2023 года и далее, чаще всего повторяется как "то, что я хотел бы понять с первого дня".

Традиционные фреймворки рассматривают стратегию поиска как код Python. Хотите, для технических каталогов, сначала искать по коду продукта, затем по ключевым словам, затем по семантическим векторам, и только в последнюю очередь генерировать ответ? Напишите функцию. Хотите, для фотоальбомов, полностью пропустить традиционный семантический поиск и полагаться на специализированный reranker для изображений? Напишите другую функцию. Хотите, для корпоративных видео, разделить аудио от визуального трека, транскрибировать их отдельно, обрабатывать как отдельные источники, а затем собирать их в окончательный ответ? Еще одна функция. Каждый тип контента, каждая область, каждый клиент в конечном итоге генерирует ветвь кода, которая расходится с другими, до такой степени, что изменение стратегии требует выпуска программного обеспечения, проверки кода, цикла тестирования, развертывания. Время между "у меня есть идея, как улучшить поиск по техническим руководствам" и "идея запущена в производство" измеряется неделями. Для каждой идеи.

Альтернативный взгляд прост в изложении, но глубок в своих последствиях: стратегия поиска — это не код. Это документ. JSON — структурированный текстовый формат, который любой редактор может прочитать с получасовой подготовкой — который говорит: "сначала попробуйте это, потом то, если первое не удастся, переходите к третьему, переранжируйте так, отвечайте этой моделью." Этот документ живет в базе данных, а не в репозитории. Он редактируется через интерфейс, а не через pull request. Он версионируется, копируется, специализируется для конкретной области. Стратегия для технических каталогов, одна для фотоальбомов, одна для руководств по установке, одна для видео, одна для аудио, одна для юридических контрактов, одна для финансовых отчетов. Все они сосуществуют в одной системе. Все они могут быть изменены в режиме реального времени.

Те, кто работал с этим подходом — назовем его, без особой фантазии, Meta-RAG — говорят об изменении скорости, которое выходит за рамки инженерии. Типичный запрос клиента "добавить поиск по кодам продуктов, содержащим аббревиатуры типа CMP40M или RH1M" больше не является задачей для разработки на две недели. Это новый шаг, добавленный к процедуре JSON, протестированный в среде подготовки, внедренный в производство за один день. На вопрос "что изменится, если мы будем использовать другой reranker для фотографий, сохранив текущий для текста?" можно ответить, изменив одну строку конфигурации. Эксперимент ничего не стоит, откат тоже ничего не стоит (достаточно восстановить предыдущую версию документа), а накопленные знания — что хорошо работает для определенного типа контента — становятся версионированным и передаваемым активом, а не невысказанным знанием того, кто написал эту конкретную ветку кода и сейчас в отпуске.

Существует также интересный социальный эффект, который проявляется в организациях, внедряющих этот подход. Когда стратегии представлены в виде документа, размывается грань между "разработчиком" и "экспертом-пользователем". Цифровой библиотекарь, корпоративный архивариус, эксперт в предметной области — руководитель технического отдела, менеджер по документации, продакт-менеджер, который лучше всех знает истинные вопросы клиентов — может прочитать стратегию, понять, что она делает, предложить изменения, а иногда и написать их напрямую. Ему не нужно проходить через воронку запросов в службу поддержки, не нужно объяснять разработчику вещи, которые разработчик не знает (потому что это не входит в его профессиональные обязанности). RAG перестает быть продуктом, который вы потребляете, и становится инструментом, который вы моделируете на основе своих организационных знаний. По опыту тех, кто это пробовал, это меняет моральный дух проекта еще до того, как меняются цифры метрик.

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

Закрытие — Седьмая глава, через несколько месяцев

К началу 2026 года, суммируя уроки предыдущих глав — таблицы, которые терялись, лживые переранжировщики, унаследованные галлюцинации, счета за облачные сервисы, которые росли быстрее, чем ценность, многообещающие, но жесткие фреймворки — кто-то в Италии начал строить RAG-сервер, отличный от других. Написанный на Python, предназначенный для работы на доступном оборудовании, способный взаимодействовать с облачными моделями, когда это выгодно, и с локальными моделями, когда этого требует конфиденциальность или стоимость не оправдывает себя. Сервер, в котором стратегии поиска являются изменяемыми документами, переранжировщик — это локальный процесс на GPU, таблицы не теряются, потому что к ним относятся как к первоклассным объектам, фотографии не наследуют объекты из пыльных архивов других эпох, а стоимость запроса — как в денежном выражении, так и в данных, передаваемых третьим лицам — известна и контролируется до цента.

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

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

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

Это расследование было составлено в апреле 2026 года на основе восемнадцати месяцев опыта проектирования, строительства и оптимизации корпоративных систем RAG с конца 2024 года до начала 2026 года.