MTS: les premières décisions architecturales en AI prises aujourd’hui fixent des limites pour les décennies à venir
MTS a publié une chronique expliquant pourquoi l’architecture de l’AI ne se façonne pas seulement par les modèles, mais aussi par les premières décisions d’ingé

Текст МТС на Habr AI предлагает смотреть на развитие искусственного интеллекта не как на гонку моделей, а как на накопление архитектурных решений, которые потом живут десятилетиями. Главная мысль проста: первые слои кода, данных и процессов сегодня могут стать таким же неразбираемым фундаментом для будущих AI-систем, каким в «Гиперионе» стал Техно-Центр.
Метафора из «Гипериона»
Автор отталкивается от романа Дэна Симмонса «Гиперион», где искусственные интеллекты веками достраивали собственные системы поверх кода, написанного людьми. Со временем архитектура стала настолько сложной, что ни люди, ни сами ИскИны уже не понимали, почему ключевые механизмы устроены именно так. Для фантастики конца 1980-х это был эффектный образ.
Для сегодняшней индустрии ИИ — почти буквальное описание того, как накапливается технический долг в больших AI-платформах. Важно, что эта метафора говорит не о далеком восстании машин, а о вполне земной инженерной проблеме. Чем больше поколений команд, сервисов и моделей наслаиваются друг на друга без общего замысла, тем выше риск получить систему, которую нельзя уверенно развивать.
Она продолжает работать, но причины ее поведения становятся все менее очевидными. А там, где исчезает объяснимость архитектуры, быстро растут и стоимость изменений, и вероятность ошибок.
Как растет сложность Проблема не только в моделях.
Любой AI-продукт строится слоями: пайплайны данных, фильтры, векторные базы, оркестраторы, системные промпты, правила безопасности, интерфейсы для людей, интеграции с внешними сервисами. Каждый слой обычно появляется как ответ на срочную задачу бизнеса: ускорить релиз, сократить стоимость запросов, поднять качество ответов или закрыть риск. По отдельности такие решения выглядят разумно, но через несколько лет из них собирается конструкция, которую трудно объяснить, протестировать и безопасно менять.
Из-за этого архитектурные ошибки раннего этапа оказываются особенно дорогими. Если команда изначально не описала зависимости, не зафиксировала инварианты и не договорилась, где заканчивается ответственность модели, а где начинается ответственность продукта, потом все это превращается в системную неясность. Модель можно переобучить или заменить, а вот хаотично выросший контур вокруг нее — логирование, маршрутизация, правила эскалации, ручные костыли — живет дольше и мешает быстрее, чем сама нейросеть.
Что делать командам
Именно поэтому разговор о будущем ИИ все чаще смещается с размеров моделей на качество инженерных оснований. Речь не о том, чтобы заморозить эксперименты и бесконечно проектировать идеальную систему. Речь о минимальной дисциплине, без которой AI-стек быстро становится непрозрачным даже для собственной команды. В колонке МТС это звучит как предупреждение: сегодня рынок занят скоростью, но реальное преимущество завтра получат те, кто уже сейчас проектирует понятную и проверяемую архитектуру.
- Ясно разделять, что делает модель, а что — бизнес-логика продукта Документировать причины ключевых архитектурных решений, а не только итоговый код Ограничивать число скрытых зависимостей между данными, промптами, ретривером и интерфейсом Закладывать наблюдаемость: логи, трассировку, версии промптов и контроль качества Регулярно убирать временные костыли, пока они не стали постоянной инфраструктурой Это касается не только инженеров. Продуктовые команды, менеджеры и руководители тоже влияют на будущую сложность, когда требуют добавить еще один флаг, временно обойти ограничение или быстро склеить два контура. В AI-системах такие компромиссы особенно коварны: они прячутся не только в коде, но и в данных, настройках моделей, скрытых инструкциях и ручных операциях поддержки. Внешне продукт может работать, но внутри уже терять управляемость.
Что это значит
Для команд, которые строят AI-сервисы сегодня, главный вывод не в том, что сложность нужно остановить — это невозможно. Вывод в другом: каждое быстрое решение оставляет след в фундаменте. И если не управлять этими слоями с самого начала, через несколько лет именно они, а не качество модели, будут определять потолок скорости, надежности и безопасности продукта.