Команда AI for Devs перевела статью, в которой автор делится прогнозами о будущем ИИ-агентов в 2025 году. Его выводы: несмотря на шумиху, «автономные агенты» столкнутся с экономическими и техническими барьерами. Почему текущий подход к архитектуре агентов не сработает и какие методы действительно приносят результат — читайте в статье.
Я разработал более 12 систем AI-агентов в таких областях, как разработка, DevOps и обработка данных. Вот почему текущий ажиотаж вокруг автономных агентов математически невозможен, и что действительно работает в продакшене.
Все говорят, что 2025 год — это год AI-агентов. Заголовки повсюду: «Автономный ИИ преобразит рабочие процессы», «Агенты — следующая граница», «Будущее за агентами». Тем временем, я провел последний год, создавая различные системы агентов, которые действительно работают в продакшене. И именно поэтому я ставлю против текущего ажиотажа.
Я не какой-то скептик, пишущий с боку. За последний год я разработал более десятка систем агентов, работающих в проде, по всему жизненному циклу разработки ПО:
Агенты для разработки: генераторы UI, которые создают функциональные React-компоненты из естественного языка, агенты для рефакторинга кода, которые модернизируют устаревшие кодовые базы, генераторы документации, которые автоматически поддерживают API-документацию, и генераторы функций, которые превращают спецификации в рабочие реализации.
Агенты для данных и инфраструктуры: агенты для работы с базами данных, которые обрабатывают сложные запросы и миграции, системы автоматизации DevOps, управляющие инфраструктурой как кодом на нескольких облачных провайдерах.
Агенты для качества и процессов: AI-управляемые CI/CD пайплайны, которые исправляют ошибки линтинга, генерируют полные тестовые наборы, выполняют автоматические ревью кода и создают детализированные pull-запросы с правильными описаниями.
Эти системы работают. Они приносят реальную ценность. Они экономят часы ручной работы каждый день. И именно поэтому я считаю, что многое из того, что говорят о 2025 годе как о «годе агентов», не учитывает ключевые реалии.
TL;DR: Три жесткие истины об AI-агентах
После создания AI-систем вот что я усвоил:
Ошибки накапливаются экспоненциально в многоступенчатых рабочих процессах. 95% надежности на каждом шаге = 36% успешности за 20 шагов. В продакшн-системах нужно 99,9%+.
Окна контекста создают квадратичные затраты на токены. Долгие разговоры становятся слишком дорогими при масштабировании.
Реальная проблема — не в возможностях ИИ, а в проектировании инструментов и систем обратной связи, которые агенты могут эффективно использовать.
Математическая реальность, о которой никто не говорит
Вот неудобная правда, вокруг которой все компании по разработке AI-агентов танцуют: накопление ошибок делает автономные многоступенчатые рабочие процессы математически невозможными на производственном уровне.
Посчитаем. Если каждый шаг в рабочем процессе агента имеет 95% надежности, что является оптимистичной оценкой для текущих LLM, то:
5 шагов = 77% успешности
10 шагов = 59% успешности
20 шагов = 36% успешности
Для продакшн-систем требуется надежность 99,9%+. Даже если вам удастся достичь 99% надежности на каждом шаге (чего пока никто не добился), вы получите лишь 82% успешности за 20 шагов. Это не проблема промптов. Это не проблема возможностей модели. Это математическая реальность.
Мой DevOps-агент работает именно потому, что это не автономный 20-шаговый рабочий процесс. Это 3-5 дискретных, независимо проверяемых операций с явными точками отката и человеческими контрольными точками. «Агент» управляет сложностью генерации инфраструктурного кода, но система спроектирована с учетом математических ограничений надежности.
Каждая успешная система агентов, которую я построил, следовала той же модели: ограниченные контексты, проверяемые операции и (иногда) человеческие точки принятия решений на критических этапах. Как только вы пытаетесь объединить больше нескольких операций в автономный процесс, математика убивает вас.
Экономика токенов, которая не сходится
Есть еще одна математическая реальность, которую проповедники агентов удобно игнорируют: окна контекста создают квадратичное увеличение стоимости, что делает разговорных агентов экономически невозможными.
Вот что на самом деле происходит, когда вы создаете «разговорного» агента:
Каждое новое взаимодействие требует обработки ВСЕГО предыдущего контекста.
Стоимость токенов растет квадратично с увеличением длины разговора.
100-шаговый разговор стоит от $50 до $100 только за токены.
Умножьте на тысячи пользователей, и вы получите экономику, которая не выдерживает конкуренции.
Я узнал это на собственном опыте, когда создавал прототип разговорного агента для работы с базой данных. Первые несколько взаимодействий были дешевыми. Но к 50-му запросу в сессии каждый ответ стоил несколько долларов — больше, чем сам результат. Экономика просто не работает для большинства сценариев.
Мой агент по генерации функций успешен, потому что он полностью без состояния: описание → функция → готово. Нет необходимости поддерживать контекст, отслеживать разговор, нет взрывного увеличения стоимости токенов. Это не «разговор с вашим кодом», это целенаправленный инструмент, который эффективно решает конкретную задачу.
Самые успешные «агенты» в продакшн-среде вовсе не являются разговорными. Это умные, ограниченные инструменты, которые делают одну вещь хорошо и не мешают работать.
Сталкиваемся с реальностью устройства инструментов
Даже если вы решите математические задачи, вы столкнетесь с другой проблемой: создание инструментов уровня продакшена для агентов — это совершенно другая инженерная дисциплина, которую многие команды недооценят.
Вызовы инструментов сейчас довольно точны. Реальная проблема — проектирование инструментов. Каждый инструмент должен быть тщательно разработан, чтобы предоставить правильную обратную связь, не перегружая окно контекста. Нужно подумать о следующем:
Как агент узнает, что операция частично удалась? Как сообщить о сложных изменениях состояния, не тратя токены?
Запрос к базе данных может вернуть 10 000 строк, но агенту нужно только знать: «запрос выполнен, 10 тыс. результатов, вот первые 5». Проектирование этих абстракций — это искусство.
Когда инструмент не работает, какую информацию агенту нужно для восстановления? Слишком мало — он застрянет; слишком много — вы потратите контекст.
Как справиться с операциями, которые влияют друг на друга? Транзакции базы данных, блокировки файлов, зависимости ресурсов.
Мой агент для работы с базой данных работает не потому, что вызовы инструментов ненадежны, а потому, что я потратил недели на проектирование инструментов, которые эффективно взаимодействуют с ИИ. Каждый инструмент возвращает структурированную обратную связь, которую агент может действительно использовать для принятия решений, а не просто необработанные ответы от API.
Компании, обещающие «просто подключите свои API, и наш агент все решит», не проделали эту инженерную работу. Они воспринимают инструменты как интерфейсы для человека, а не для ИИ. Результат — агенты, которые технически выполняют успешные вызовы API, но не могут выполнить сложные рабочие процессы, потому что не понимают, что произошло.
Грязный секрет каждой продакшн-системы агентов заключается в том, что ИИ выполняет, возможно, только 30% работы. Остальные 70% — это инженерия инструментов: проектирование интерфейсов обратной связи, эффективное управление контекстом, обработка частичных сбоев и создание механизмов восстановления, которые ИИ действительно может понять и использовать.
Проверка реальности интеграции
Но давайте предположим, что вы решили проблемы с надежностью и экономикой. Вам все равно нужно интегрироваться с реальным миром, а реальный мир — это беспорядок.
Корпоративные системы — это не чистые API, ожидающие, что ИИ-агенты будут их оркестровать. Это устаревшие системы с особенностями, частичными режимами сбоев, изменяющимися потоками аутентификации без предупреждения, лимитами скорости, которые зависят от времени суток, и требованиями соответствия, которые не укладываются в шаблоны подсказок.
Мой агент для работы с базой данных не просто «автономно выполняет запросы». Он управляет пулом соединений, обрабатывает откаты транзакций, учитывает реплики только для чтения, управляет тайм-аутами запросов и ведет логирование для аудитных следов. ИИ генерирует запросы, все остальное — это традиционное программирование систем.
Компании, обещающие «автономных агентов, которые интегрируются с всем вашим технологическим стеком», либо чрезмерно оптимистичны, либо еще не пытались создавать продакшн-системы в масштабе. Интеграция — это то место, где ИИ-агенты обречены.
Что действительно работает (и почему)
После создания более десятка различных систем агентов на протяжении всего жизненного цикла разработки ПО, я понял, что успешные системы следуют одному паттерну:
Мой агент для генерации UI работает, потому что каждый сгенерированный интерфейс проверяется человеком перед развертыванием. ИИ обрабатывает сложность перевода естественного языка в функциональные компоненты React, но окончательные решения о пользовательском опыте принимает человек.
Мой агент для работы с базой данных работает, потому что он подтверждает каждую разрушительную операцию перед выполнением. ИИ решает сложные задачи перевода бизнес-требований в SQL, но человек контролирует целостность данных.
Мой агент для генерации функций работает, потому что он работает в пределах четко определенных границ. Дайте ему спецификацию — получите функцию. Без побочных эффектов, без управления состоянием, без сложности интеграции.
Моя система автоматизации DevOps работает, потому что она генерирует инфраструктуру как код, который можно просматривать, версионировать и откатывать. ИИ обрабатывает сложность перевода требований в Terraform, но пайплайн развертывания поддерживает все механизмы безопасности, на которые мы привыкли полагаться.
Мой агент для CI/CD работает, потому что на каждом этапе есть четкие критерии успеха и механизмы отката. ИИ обрабатывает сложность анализа качества кода и генерации исправлений, но пайплайн контролирует, что действительно будет слито.
Паттерн ясен: ИИ справляется с сложностью, человек сохраняет контроль, а традиционная разработка ПО обеспечивает надежность.
Мои прогнозы
Вот мой конкретный прогноз о том, кто будет испытывать трудности в 2025 году:
Стартапы с венчурным финансированием, которые предлагают «полностью автономных агентов», столкнутся с экономическим барьером первыми. Их демонстрации отлично работают с 5-шаговыми рабочими процессами, но клиенты будут требовать процессы из 20+ шагов, которые ломаются с математической точки зрения. Затраты будут расти, когда они попытаются решить нерешаемые проблемы с надежностью.
Компании по разработке корпоративного ПО, которые добавили «AI-агентов» в существующие продукты, столкнутся с застоем в принятии. Их агенты не могут интегрироваться достаточно глубоко, чтобы обрабатывать реальные рабочие процессы.
Тем временем победителями станут команды, строящие ограниченные, специализированные инструменты, которые используют ИИ для сложных задач, сохраняя при этом контроль человека или строгие границы для критически важных решений. Меньше «автономности во всем» и больше «крайне способных помощников с четкими границами».
Рынок научится различать ИИ, который хорошо работает на демо, и ИИ, который стабильно выполняет задачи в реальности. Это обучение обойдется дорого для многих компаний.
Я не ставлю против ИИ. Я ставлю против текущего подхода к архитектуре агентов. Но я уверен, что будущее будет гораздо ценнее, чем предполагает текущий ажиотаж.
Как строить правильно
Если вы планируете создавать системы с ИИ-агентами, начните с этих принципов:
Определите четкие границы. Что именно ваш агент может делать, а что он передает человеку или детерминированным системам?
Проектируйте с учетом сбоев. Как вы будете обрабатывать 20-40% случаев, когда ИИ ошибается? Какие у вас механизмы отката?
Решите проблему экономики. Сколько стоит каждое взаимодействие и как это масштабируется с увеличением использования? Отсутствие состояния часто лучше его наличия.
Приоритет надежности над автономией. Пользователи доверяют инструментам, которые работают стабильно, больше, чем системам, которые иногда делают чудеса.
Стройте на прочных основах. Используйте ИИ для сложных частей (понимание намерений, генерация контента), но полагайтесь на традиционную разработку ПО для критически важных частей (выполнение, обработка ошибок, управление состоянием).
Революция агентов приближается. Только она будет выглядеть совсем не так, как обещают в 2025 году. И именно это обеспечит ей успех.
Русскоязычное сообщество про AI в разработке
Друзья! Эту статью подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!
Комментарии (50)
Wicron
24.09.2025 14:35Текст содержит серьёзные неточности. В частности квадратичная зависимость вычислительной сложности от длины контекста в случае сетей с мамба слоями уже близка к линейной. К тому же есть ИИ-агенты не классифицирующего акцента на кейсы с большей вариативной генеративностью, нежели с классифицируемостью
spirit1984
24.09.2025 14:35Интересно, не знал. Я знал про квадратичную зависимость. А сети с мамба слоями - они насколько распространены нынче? OpenAI работает на них? И насколько вообще вменяем агент, построенный по такому принципу?
Wicron
24.09.2025 14:35LLM с мамба слоями уже пару месяцев как появились, например NVIDIA Nemotron-H family 12b. Крайние релизы Qwen не пробовали смотреть? А hunyuan-t1? А это: https://habr.com/ru/companies/bar/articles/894370/
Как вам идея для начала Habr спарсить переложить его в RAG, потом по RAGу пройтись LLMкой и проверить свою статью на качество утверждений путем поиска иных утверждений с высоким индексом релевантности
Yrninibg
24.09.2025 14:35Пока мамба доберется до массового использования в enterprise, пройдет еще пара лет. Так что для текущего момента аргумент автора про квадратичную стоимость абсолютно валиден
Zippy
24.09.2025 14:35Ну можно верить не в самих агентов а в круглые сумы которые на этом зарабатываются
WASD1
24.09.2025 14:35Ну так нужны новые языки "под ключ" для агентов.
С новыми workflow и хранением проекта.
Workflow - снижает ошибки (ну т.е. обратные петли с тестированием и watchdog'ом зовущим челвоека разгребать если пайп не прошёл).
Проект - древовидная документация в конфлюесн + интерфейсы (боле-менее соответствующая структуре проекта в ФС).
Любой промпт (заливает в проект атомарно), вызывает следующие изменения:
1. Меняет "верхнеуровневую доку" конфлюенс (требует апрува от человека "продолжай")
2. По результатам изменений конфлюенса - меняет код, доуточняет изменение интерфейсов (которые через doxigen-like тоже экспортятся в доку) и нижнеуровневой доки
3. Дальше - прогоняет пайплайны, дописывает автотесты и т.д.
Основная фишка - проект это ВЕРХНЕУРОВНЕВАЯ ДОКА (которую читает агент) + код в файликах примерно в соотношении: 1 страничка : 1 файлик (с интерфейсами если есть разделение на них и реализацию).
arantar
24.09.2025 14:35код в файликах примерно в соотношении: 1 страничка : 1 файлик
Не очень понял, можете пример привести?
WASD1
24.09.2025 14:35Я пожалуй немного смягчу условие.
Возьмите свою доку - оформленную как древовидная структура страничек.
Каждый файлик вашего репозитория должен относится к какой-то странице (спекулятивное предположение - только к одной).
Если несколько файликов относятся к одной странице - назовите их как-то например "мета-файл" (не хочу применять термины "пакет" или "модуль" - т.к. они могут законфликтовать с уже применяемыми).
========================================================
Цель - помочь агентам с архитектурой.
Общая идея - отобразить семантическую структуру и доки и кода на архитектуру проекта.
Т.е. если вам надо как-то поменять "компонент-Х", вы находите его в дереве иерархии и:
1. Читаете саму страничку компонента
2. Читаете все станички "от корня до данной".
3. Читаете все под-странички компонента.
4. Читаете код исходных файликов, относящихся к этой страничке (по 2,3 - на этапе "предложи архитектуру" код читать не нужно).
flancer
24.09.2025 14:35А для чего confluence? Почему не держать всё в файловой системе - в md-файлах? Можно разнести по разным репозиториям, если надо: доки - отдельно, код - отдельно.
WASD1
24.09.2025 14:35цель - повысить уровень абстракции при работе ИИ-агента. Вообще с уровнями абстракции у современного ИИ не очень хорошо (в сравнении с человеком), но это очень длинная тема.
т.е. зафорсить его "скажи как надо сделать, оцени что оно делаемо вообще".
Ок, теперь реализуй это.flancer
24.09.2025 14:35Я в своих отношениях с ИИ тоже пришёл к выводу, что каждому сгенерированному файлу с исходным кодом должна соответствовать иерархия файлов документации (страничек, в вашей терминологии). Такое дерево документов, где уровень абстракции понижается от корня к листьям. Одни файлы документации (стволовые) используются для генерации практически каждого исходного файла проекта, другие (конечные ветки) - только для генерации конкретного исходника.
Но мой вопрос был именно про confluence. Мне кажется, что держать документацию в md-файлах раздельных репозиториев и комбинировать репозитории для конечных проектов - это гораздо удобнее, чем confluence.
fongostev
24.09.2025 14:35Вы по сути описали семантическую разметку кода, которая по современным практикам интегрируется напрямую в код, создавая для ИИ семантически богатый граф, по которому можно легко навигироваться и получать недостающий контекст, например цель кода, тестовые критерии и тд, напрямую из разметки, а не после анализа кода. Такой подход снижает потребление токенов, увеличивает надёжность разработки. ИИ уже не будет дропать код, так как он точно понимает его назначение и связи с другими частями приложения без дополнительного парсинга файлов проекта.
WASD1
24.09.2025 14:35Ответил выше про "зафорсить повышение уровня абстракции при работе ИИ-агентов".
FatherYan
24.09.2025 14:35С проблемой надежности сложно спорить. Только она присуща не только ИИ-агентам, но и людям. И большинство людей имеют "надежность" гораздо меньше 95%. Пообещать и не сделать вовремя? Да, легко. Или вообще "ой, я забыл"? Сплошь и рядом. Ошибаются вообще все. Контроль результата и корректировка являются неотъемлемой частью абсолютно любого workflow безо всяких ИИ-агентов.
SabMakc
24.09.2025 14:35А если каждое действие имеет 95% надежность? Жить прямо как в DnD? Взял ручку - бросок кубика. Не повезло - тут же уронил. Или сломал. Или потерял.
А если добавить не просто "неудачи" в действии, а галлюцинации (которыми славятся LLM)? "Не повезло" и ты не просто "забыл", а сделал неправильно, будучи на 100% уверенным что так и надо было. Например, вместо удаления файла - форматирование диска (файл же это тоже удалит).
А у LLM именно каждое действие может пойти наперекосяк. И хорошо, если просто закончится неудачей. Но LLM-ка может решить грохнуть БД на проде в любой момент (и такие случаи уже были) - и LLM даже не заметит что что-то пошло не так...
FatherYan
24.09.2025 14:35В массовом сознании, почему-то закрепилось мнение, что ИИ = "Компетентный и ответственный сотрудник senior-уровня с которым мы работаем >3 лет". Это не так. Гораздо ближе к реальности "мидл, вроде толковый, но мы его наняли всего 2 недели назад". Может быть мы неверно оценили скиллы, а может он вообще завтра в запой уйдет. Никто в здравом уме сразу не выдаст бесконтрольный доступ к критическим ресурсам такому человеку. И да, разумеется подавляющее большинство работников это именно мидлы и джуны. Синьеров на всех не напасешься. И да, многих наняли не так давно и в принципе непонятно чего от них ждать. Кто-то из них наверняка сотворит какую-нибудь фигню, и не факт что поймет что это фигня и своевременно предупредит/спросит у более опытных коллег. Но мы с этим работаем и никого такое положение вещей не удивляет. Се ля ви.
northrop
24.09.2025 14:35Синьеров на всех не напасешься.
С вкатыванием мира в рецессию, массовые увольнения и сокращения ФОТ вполне себе напасешься, даже еще с горкой будет.
SabMakc
24.09.2025 14:35Человек обучаем и способен развивать свои навыки.
А LLM - нет. Любая неожиданная ситуация и LLM встанет в ступор - просто потому что нет понимания что к чему. Да, LLM много знает, отлично справляется с типичными ситуациями. Отлично умеет действовать по шаблону. Но LLM не понимает что она делает, зачем она это делает и почему именно так она это делает.
А главное - человек понимает пределы своей компетентности и способен сам развивать эти пределы по мере необходимости. LLM же будет с абсолютной уверенностью катиться в пропасть.
Я бы LLM даже с джуном не сравнивал - просто потому что джун обучается.
P.S. да, LLM можно "обучить" - на куче примеров и за много-много денег. Но это далеко не тоже самое, что обучение человека. И доступно далеко не каждому.
P.P.S. Да, возможности LLM поражают, этого не отнять. Но на текущем уровне они еще очень далеки до полноценного ИИ.
Yrninibg
24.09.2025 14:35Дело не только в проценте надежности, но и в природе ошибок. Человек может забыть или сделать опечатку, а LLM-агент может уверенно сгаллюцинировать и решить, что лучший способ удалить временные файлы — это rm -rf /.
Уровень непредсказуемости и потенциального ущерба от ошибки ИИ несоизмеримо выше
FatherYan
24.09.2025 14:35Просто напомню, что "rm -rf /" появился и наносил ущерб сильно задолго до появления ИИ. Джуны находили такие злые шутки на форумах и уверенно запускали. Проблема настолько массовая, что в итоге пришлось даже менять стандартное поведение терминала, чтобы дополнительно запрашивал подтверждение.
rm: опасно рекурсивно обрабатывать '/' rm: используйте --no-preserve-root, чтобы отменить предупреждение об опасности
markedo
24.09.2025 14:35Ну так это как раз отличный пример. Человек увидит предупреждение в консоли и сможет понять, что его действия ошибочны. Напротив, ИИ в приципе не воспринимает концепцию "я могу ошибиться".
Однажды выполнивший "rm -rf /" скорее всего больше не повторит эту ошибку. ИИ может тут же её повторить, даже если прямо попросить это не делать.
murkin-kot
24.09.2025 14:35Проблема не в сложности, а в подходах к работе с ней. Подходы есть. И есть инерция. Точно так же множество эффективно используемых ныне инструментов нарождалось в муках, на бесплодные попытки использовать старый молоток для забивания шурупов уходили десятилетия, а в средние века и столетия. Но итог мы видим - стоило начать использовать правильный инструмент, как тут же всё резко изменилось.
Возьмём крестовую отвёртку. Она без индустрии по производству крестовых шурупов не нужна. А крестовые шурупы ещё нужно научиться клепать. И потом построить станки. И найти на это много-много денег. Да, станки дорогие, рядовой энтузиаст не потянет.
Короче - инерция. Вот и всё, что отделяет вас от пропасти, после которой вы станете не нужны. (с) чат-жпт.
Yrninibg
24.09.2025 14:35ИИ отлично справляется с рутинной и сложной частью - сгенерировать код по спеке, написать SQL-запрос, развернуть Terraform-конфиг, но финальное решение, проверка и ответственность - остаются за человеком. И это единственная рабочая схема на ближайшие годы
RepppINTim
24.09.2025 14:35Математику про накопление ошибок нужно показывать каждому менеджеру, который говорит "давайте сделаем полностью автономного ИИ агента"
95% надежности на шаг — это уже оптимистично, а на выходе пшик
Kahelman
24.09.2025 14:35«Друзья! Эту статью подготовила команда ТГК»
Если статью подготовили команда, то почему «у меня и Я» а не «у нас и мы»?Есть мнение что ИИ не и писал.
Вы недооцениваете способности ИИ.
Если он уже умеет решать геометрические задачи которые ему ввиде картинки закидывают, то время задуматься….Это не отменяет того факта что система может быть глюкавой. Вопрос как вы работу выстроите.
В приципе, любая достаточно сложная программма сегодня это вероятностная система: то-ли работает, то-ли нет.
Так что подход к написанию ее методом «Монте Карло» имеет место быть.
SkiffCMC
24.09.2025 14:35Самое интересное, что ИИшка реально очень удобна в быту или учебе личного характера, то есть физическому лицу прям очень хорошо может зайти, потому что цена галлюцинации не очень высокая(ну, главное, до жизненно важных вопросов допускайте с осторожностью). Мне очень понравилось её спрашивать в качестве ликбеза по незнакомой технологии - сначала "дай краткое описание, что и зачем", потом "составь айсберг возможностей" и в конце "сделай роадмап, как написать такую штуку с нуля" - сразу понимаешь общую картину и примерные границы применения, а по нюансам уже можно и вне ИИ читать. Ни учебник, ни форумы так не умеют. Мясной напарник умеет, но как-то неудобно человека от работы отрывать ради удовлетворения любопытства. А ИИшку - пожалуйста. И да, в деталях она может подвирать, это нужно учитывать, но общую картину даст неплохо, если технология не супер малоизвестная.
Но вот бизнес, где цена ошибки иная - это уже совсем другая история(с)
SabMakc
24.09.2025 14:35Да, для личного использования - LLM отлично подходят. Может ответить практически на что угодно - гораздо быстрее и проще, чем искать самому (*). А если тема малоизвестная - можно подключить поиск и тоже получить неплохие результаты.
Или для творческих задач - генерация текста / картинок / видео. Может в работу результат и не подойдет (зачастую сложно или даже невозможно заставить генерировать в точности то, что нужно), но как способ поиска идей для вдохновения - очень даже неплохо может получиться.
Но для бизнеса важен прогнозируемый и точный результат. И даже 95% точности - это очень мало. А правдоподобные галлюцинации добавляют еще один фактор негатива, даже более важный, чем просто некорректный результат.
* Впрочем, для сложных вопросов все равно лучше самому искать. Не зря говорят, что правильный вопрос содержит половину ответа. Но если в теме совсем не разбираешься, то и правильный вопрос невозможно задать. И самостоятельный поиск углубляет понимание.
BugM
24.09.2025 14:35Только вот вы никогда не узнаете правду вам сетка написала или сгалюцинировала на 100 процентов.
avdosev
24.09.2025 14:35верификация ответов нейросети не простая, но решаемая проблема, было бы желание
BugM
24.09.2025 14:35Там может сразу и начать с нормальных источников? Чтобы не делать двойную работу.
avdosev
24.09.2025 14:35За все хорошее и против всего плохого
Чтобы знать какой источник нормальный а какой нет нужно неплохо разбираться в теме, а в контексте этого диалога мы изходим из мысли, что пользователь таковым не является.
Вот чатгпт тут и помогает. Тк верификация это по сути поиск первоисточника по набору фактов, с таким современные поисковые системы неплохо справляются, а вот с запросами вида "дай краткое описание, что и зачем", потом "составь айсберг возможностей" и в конце "сделай роадмап, как написать такую штуку с нуля" они дать нормальный ответ не всегда могут.
Да, работы больше, но работа разная бывает, простая и сложная, тут она проще, что является значимым преимуществом.
BugM
24.09.2025 14:35Точно помогает? А не выдумывает источники случаем?
Нормальность источника оценить заметно проще чем разобраться галлюцинации это или нет. Тем более что Гугл уже прилично под завален статьями с этими галлюцинациями. И беглый Гуглеж не помогает.
avdosev
24.09.2025 14:35Точно помогает?
Да, мне помогает
Возможно это моя специфика, но сужу по своему опыту
Процесс с чатгпт ощущается быстрее и эффективнее чем без него.
А не выдумывает источники случаем?
На моей практике выдумывает где-то треть источников если явно попросить их перечислить
Обычно источник ищу сам либо самостоятельно верифицирую из тех что чатгпт написал.
Опять же, если точность не важна то можно верефикацией не заниматься, многим качества нейрохрючева - достаточно.
Нормальность источника оценить заметно проще чем разобраться галлюцинации это или нет. Тем более что Гугл уже прилично под завален статьями с этими галлюцинациями. И беглый Гуглеж не помогает.
Ну вот да, зачем мне читать статьи в интернете сомнительного качества от нейронок (самых дешевых обычно) если я могу почитать ответ от лучших нейронок которые реже галлюцинируют так ещё у них детали можно уточнить.
SkiffCMC
24.09.2025 14:35Это вероятностный вопрос - чем "известнее" инфа, которую спрашиваешь, тем больше шанс, что суждения нейронки будут правильными. И да, стопроцентные галлюцинации(прям все нафантазировано) - это сильно менее вероятно, чем "все верно", если тема популярная, ну а самый вероятный исход - в основном верно, но по каким-то пунктам будет враньё. Как инструкция или учебник - не годится, но как "взгляд с высоты птичьего полета" - вполне. Ну и что значит не узнаю - если я планирую дальше пользоваться тем, про что спрашивал, то крупные нестыковки вылезут очень быстро. Просто надо эти шансы ошибок учитывать и не верить на слово.
BugM
24.09.2025 14:35Вы же буквально описали источник которому в принципе нельзя доверять ни в чем. 90 процентов правды и 10 процентов вранья с виду похожего на правду это гораздо хуже чем 100 процентов вранья.
SkiffCMC
24.09.2025 14:35Ну, проведу аналогию. Есть фреймворк актуальной версии 2.0, в 10% контрактов отличающийся от 1.0. Так вышло, что доков по актуальной версии у вас нет, но есть по первой. Его точно нет смысла читать из-за 10% неверной инфы? Или после прочтения будет довольно неплохое представление, что к чему, а с расхождениями можно уже и на практике разобраться?
BugM
24.09.2025 14:35Да. Точно нет смысла обновляться. И даже разбираться более чем, интересно что там, нет смысла. Где там расхождения вообще не интересно.
Софт должен работать правильно или он не нужен. С гарантией в девятках.
Ллмки правильно работают в задачах без точного решения. Вроде придумай бла-бла-бла.
flancer
24.09.2025 14:35Вопрос не в том, обновляться или нет - по условиям задачи вы уже работаете со второй версией. Вопрос в том, читать или не читать доки, верные всего лишь на 90%.
Есть такое понятие "недокументированные возможности", которое наводит на мысль, что очень многие документы не отражают предмет с точностью в девятках.
Я очень долгое время имел дело с Magento, где софт работал правильно на наиболее популярных функциях и страшно глючил на редко-используемых. В своё время это была очень популярная платформа в е-коммерции. Так что, софт бывает всякий, но не все могут использовать всякий софт.
BugM
24.09.2025 14:35Вы неверно описываете природу ошибок. Неполная информации это одно неверная это другое.
Одно дело функция myGeatF не документирована. Тут все просто - не используем ее. И совсем другое дело если функция println с документацией "выводим строку в stdout" с вероятностью 0.1 процент делает rm -f / UB везде.
Нейросети ведут себя вторым образом.
Kodex_Faber
Мне кажется, что интеллект - это что-то иное, а не просто нечто наполненное данными. Также как и знание тоже не просто наличие данных по данному вопросу - это что-то большее. Именно поэтому нужно придумать белее точное название чем ИИ...
constXife
Ну из того что я помню из института (может другие поправят), ИИ это общее название раздела информатики, которая включает кучу подразделов, в которых даже нейросетями не пахнет, типа Байеса или Дейкстра. И в итоге, вместо ИИ агента будем писать что-то вроде "агент для коммуникации с генеративными ИИ на основе трансформеров с механизмом внимания"? Ну наверное это достаточно точно, но как-то длинновато.
Guid0Fawkes
На Хабре была статья с очень точным названием для нынешнего ИИ — мешок слов.
А все несогласные комментарии можно было бы обобщить до несколько более точного термина: продвинутый мешок слов.
Okeu
кожаный продвинутый мешок слов. ))
Zippy
так ИИ как междисциплинарное научное направление основаное в 1956 грду изначально и задумывался как имитация конгитивных способностей человека. Ну типа раз наблюдать напрямую работу мозга не можем то жавайте его имитировать. А неудачные названия в науке сплошь и рядом.
Естественно мозг не работает пожбирая вероятности каждого следующего слова в зависимсти от контекста и предыдущего текста.
мозг работает как аналоговый вычислитель а не дискретный (как бы ни ьыло огромно число текстовых токенов оно все равно конечно и его можно общитать).
мозг оперируетабстрактными идеями (знаменитый пример идеи ложки) непрерывными визуальными образами,. мозг понимает физический мир может планировать и имеет заложеные эволюцией императивы к действию.
Поэтому пока не существует даже теоретических наработок создания так называемого "сильного ИИ". да и зачем? искуственный мозг и работать будет как обычный человеческий.
dkeiz
Имитация Интеллекта.
SergeyVN94
Матрица вероятностей.
altbrace
Так оно есть - LLM. Искусственным интеллектом большие языковые модели называют маркетологи.