LLM Council от Карпати переосмысляет концепцию промежуточного ПО для ИИ
В эти выходные Андрей Карпаты (Andrej Karpathy), бывший директор по искусственному интеллекту в Tesla и один из основателей OpenAI, захотел почитать книгу. Но читать ее в одиночку ему не хотелось; он предпочел бы компанию целого комитета ИИ, где каждая модель предлагает свой собственный взгляд, критикует другие и в конечном итоге синтезирует окончательный ответ под руководством «председателя».
Чтобы воплотить это в жизнь, Карпаты написал то, что он назвал «проектом в вайб-кодинге» — программное обеспечение, созданное наскоро, во многом с помощью ИИ-ассистентов, скорее ради развлечения, чем для серьезной работы. Он выложил результат — репозиторий под названием LLM Council («Совет LLM») — на GitHub с суровым отказом от ответственности: «Я никак не собираюсь поддерживать это… Код теперь мимолетен, а библиотеки канули в лету».
Тем не менее, для тех, кто принимает технические решения на уровне корпораций, за этим небрежным предупреждением кроется нечто гораздо более значительное, чем просто игрушка на выходные. Всего в нескольких сотнях строк Python и JavaScript Карпаты набросал эталонную архитектуру для важнейшего, неопределенного слоя современного программного стека: оркестрового связующего ПО (middleware), находящегося между корпоративными приложениями и изменчивым рынком моделей ИИ.
Поскольку компании завершают формирование своих инвестиций в платформы на 2026 год, LLM Council предлагает трезвый взгляд на дилемму «создать или купить» в отношении инфраструктуры ИИ. Проект демонстрирует, что хотя логика маршрутизации и агрегации моделей ИИ удивительно проста, истинная сложность кроется в операционной «обертке», необходимой для готовности системы к корпоративному использованию.
Как работает LLM Council: четыре модели ИИ спорят, критикуют и синтезируют ответы
Для стороннего наблюдателя веб-приложение LLM Council выглядит практически так же, как ChatGPT. Пользователь вводит запрос в поле чата. Но за кулисами приложение запускает сложный трехэтапный рабочий процесс, который повторяет принципы работы человеческих коллегиальных органов принятия решений.
Сначала система отправляет запрос пользователя группе передовых моделей (frontier models). В конфигурации Карпаты по умолчанию в нее входят GPT-5.1 от OpenAI, Gemini 3.0 Pro от Google, Claude Sonnet 4.5 от Anthropic и Grok 4 от xAI. Эти модели генерируют свои первоначальные ответы параллельно.
На втором этапе программное обеспечение выполняет экспертную оценку (peer review). Каждой модели передаются анонимизированные ответы ее «коллег», и ее просят оценить их с точки зрения точности и глубины инсайтов. Этот шаг превращает ИИ из генератора в критика, принудительно вводя уровень контроля качества, который редко встречается при обычном общении с чат-ботами.
Наконец, назначенный «LLM-председатель» (в текущей конфигурации — Gemini 3 от Google) получает исходный запрос, индивидуальные ответы и экспертные рейтинги. Он синтезирует эту массу контекста в единый, авторитетный ответ для пользователя.
Карпаты отметил, что результаты оказались неожиданными. «Довольно часто модели с удивительной готовностью признают ответ другой LLM лучше собственного», — написал он в X (ранее Twitter). Он описал использование инструмента для чтения глав книг, заметив, что модели неизменно хвалили GPT-5.1 как самую глубокую, в то время как Claude оценивали ниже всех. Однако собственная качественная оценка Карпаты разошлась с мнением его цифрового совета; он счел GPT-5.1 «слишком многословной» и предпочел «сжатый и обработанный» результат работы Gemini.
FastAPI, OpenRouter и аргументы в пользу того, чтобы рассматривать передовые модели как взаимозаменяемые компоненты
Для технических директоров (CTO) и архитекторов платформ ценность LLM Council заключается не в его литературной критике, а в его конструкции. Репозиторий служит первичным документом, точно показывающим, как выглядит современный минималистичный стек ИИ в конце 2025 года.
Приложение построено на «тонкой» архитектуре. Бэкенд использует FastAPI, современный фреймворк Python, в то время как фронтенд представляет собой стандартное приложение React на базе Vite. Хранение данных осуществляется не с помощью сложной базы данных, а посредством простых JSON-файлов, записываемых на локальный диск.
Ключевым элементом всей операции является OpenRouter — API-агрегатор, который нивелирует различия между различными поставщиками моделей. Направляя запросы через этого единого брокера, Карпаты избежал необходимости писать отдельный код интеграции для OpenAI, Google и Anthropic. Приложению не важно, какая именно компания предоставляет искусственный интеллект; оно просто отправляет промпт и ожидает ответа.
Этот архитектурный выбор подчеркивает растущую тенденцию в корпоративной архитектуре — превращение слоя моделей в биржевой товар (коммодитизация). Рассматривая передовые модели как взаимозаменяемые компоненты, которые можно подменять путем изменения всего одной строки в конфигурационном файле (а именно списка COUNCIL_MODELS в коде бэкенда), архитектура защищает приложение от привязки к конкретному вендору (vendor lock-in). Если новая модель от Meta или Mistral возглавит чаты на следующей неделе, ее можно будет добавить в совет за считанные секунды.
Чего не хватает для перехода от прототипа к продакшену: аутентификация, маскирование PII и комплаенс
Хотя основная логика LLM Council изящна, она также служит яркой иллюстрацией пропасти между «хаком выходного дня» и промышленной системой. Для команды корпоративной платформы клонирование репозитория Карпаты — это лишь первый шаг марафона.
Технический аудит кода выявляет отсутствие той самой «скучной» инфраструктуры, которую коммерческие вендоры продают за большие деньги. В системе отсутствует аутентификация; любой, у кого есть доступ к веб-интерфейсу, может делать запросы к моделям. Понятие ролей пользователей также отсутствует, а значит, у начинающего разработчика ровно те же права доступа, что и у CIO.
Более того, уровень управления и контроля (governance) полностью отсутствует. В корпоративной среде одновременная отправка данных четырем различным внешним провайдерам ИИ немедленно вызывает вопросы комплаенса. Здесь нет механизма маскирования или удаления личных данных (PII) до того, как они покинут локальную сеть, как нет и журнала аудита для отслеживания того, кто и что запрашивал.
Надежность — еще один открытый вопрос. Система предполагает, что OpenRouter API работает всегда, а модели ответят вовремя. В ней отсутствуют предохранители (circuit breakers), стратегии резервного копирования и логика повторных попыток, которые поддерживают работоспособность критически важных приложений при сбоях у провайдера.
Эти пробелы не являются недостатками кода Карпаты — он прямо заявлял, что не намерен поддерживать или улучшать проект, — но именно они определяют ценностное предложение коммерческого рынка инфраструктуры ИИ.
Компании вроде LangChain, AWS Bedrock и различные стартапы в области ИИ-шлюзов по сути продают «укрепляющую оболочку» поверх той базовой логики, которую продемонстрировал Карпаты. Они обеспечивают средства безопасности, наблюдаемости (observability) и комплаенса, которые превращают сырой скрипт оркестрации в жизнеспособную корпоративную платформу.
Почему Карпаты считает код теперь «мимолетным», а традиционные библиотеки ПО — устаревшими
Пожалуй, самым провокационным аспектом проекта является лежащая в его основе философия. Карпаты охарактеризовал процесс разработки как «на 99% созданный с помощью вайб-кодинга», намекая, что вместо построчного написания кода он в значительной степени полагался на ИИ-ассистентов.
«Попросите вашу LLM изменить его так, как вам нравится», — написал он в документации репозитория.
Это заявление знаменует собой радикальный сдвиг в возможностях разработки программного обеспечения. Традиционно компании создают внутренние библиотеки и абстракции для управления сложностью, поддерживая их годами. Карпаты же намекает на будущее, в котором код воспринимается как «подмостки для промптов» — одноразовые, легко переписываемые ИИ и не предназначенные для долговечности.
Для лиц, принимающих решения на уровне предприятий, это ставит сложный стратегический вопрос. Если внутренние инструменты можно создать методом вайб-кодинга за выходные, имеет ли смысл покупать дорогие и громоздкие программные пакеты для внутренних рабочих процессов? Или командам платформ стоит дать своим инженерам возможность самим создавать кастомные, одноразовые инструменты под свои точные нужды за малую долю стоимости?
Когда модели ИИ судят ИИ: опасный разрыв между машинными предпочтениями и потребностями человека
Помимо архитектуры, проект LLM Council невольно проливает свет на специфический риск автоматизированного развертывания ИИ: расхождение между человеческими и машинными оценками.
Наблюдение Карпаты о том, что его модели предпочитали GPT-5.1, в то время как сам он отдавал предпочтение Gemini, говорит о том, что моделям ИИ могут быть свойственны общие предвзятости. Они могут благоволить многословию, определенному форматированию или риторической уверенности, которые не обязательно совпадают с потребностями человеческого бизнеса в краткости и точности.
Поскольку предприятия все чаще полагаются на системы «LLM как судья» для оценки качества своих клиентских ботов, это несоответствие имеет критическое значение. Если автоматический оценщик стабильно вознаграждает «многословные и пространные» ответы, в то время как клиенты-люди хотят лаконичных решений, метрики будут демонстрировать успех при стремительном падении удовлетворенности клиентов. Эксперимент Карпаты показывает, что полагаться исключительно на ИИ при оценке ИИ — это стратегия, чреватая скрытыми проблемами с выравниванием (alignment issues).
Чему команды корпоративных платформ могут научиться у хака выходного дня перед созданием своего стека на 2026 год
В конечном счете, LLM Council действует как тест Роршаха для индустрии ИИ. Для любителя это забавный способ почитать книги. Для вендора — угроза, доказывающая, что основной функционал их продуктов может быть воспроизведен всего в нескольких сотнях строк кода.
Но для лидера корпоративных технологий это эталонная архитектура. Проект демистифицирует уровень оркестрации, показывая, что техническая проблема заключается вовсе не в маршрутизации промптов, а в управлении данными.
Направляясь в 2026 год, многие команды платформ наверняка будут анализировать код Карпаты не для того, чтобы развернуть его, а чтобы понять его суть. Он доказывает, что стратегия с использованием нескольких моделей технически вполне достижима. Вопрос лишь в том, будут ли компании выстраивать слой управления самостоятельно или заплатят кому-то другому за облачение «вайб-кода» в броню корпоративного уровня.
