[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:ru":3,"public-menus:all":38,"post:ai-agent-reliability-why-the-final-answer-is-not-enough:ru":205,"related:post:ai-agent-reliability-why-the-final-answer-is-not-enough:ru:1":1130},{"statusCode":4,"data":5,"message":37},200,{"tenantId":6,"lang":7,"defaultLang":8,"siteUrl":9,"contactEmail":10,"brandName":11,"logoUrl":12,"siteName":11,"siteDescription":13,"ogImage":10,"robotsIndex":14,"socialLinks":10,"reservedSlugs":10,"seoPolicy":15},"stajic","ru","de","https:\u002F\u002Fstajic.de",null,"Stajic Platform","\u002FLogo_Planet.svg","Stajic Portal",true,{"branding":16,"relatedContent":17,"crossDomainLinks":18},{"logoUrl":12},{"enabled":14},[19,22,25,28,31,34],{"url":20,"label":21,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Ffigure.rocks","figure.rocks",{"url":23,"label":24,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Floving.rocks","loving.rocks",{"url":26,"label":27,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.com","bazify.com",{"url":29,"label":30,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.de","bazify.de",{"url":32,"label":33,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.at","bazify.at",{"url":35,"label":36,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.ba","bazify.ba","Portal settings resolved",[39,45],{"id":40,"name":41,"location":42,"isActive":14,"isDefault":43,"items":44},1,"main-navigation","header",false,[],{"id":46,"name":47,"location":48,"isActive":14,"isDefault":14,"items":49},4,"main-menu","sidebar",[50,66,79,93,103,118,133],{"id":51,"title":52,"url":60,"target":61,"icon":62,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":64,"portfolioId":10,"children":65},"item-18",{"de":53,"en":54,"es":55,"fr":56,"it":54,"ru":57,"sr":58,"zh":59},"Startseite","Home","Inicio","Accueil","Главная","Почетна","首页","\u002Ffull-stack-web-developer-munich-performance-seo-and-maintainable-builds","_self","i-lucide-home","page",111,[],{"id":67,"title":68,"url":75,"target":61,"icon":76,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":77,"portfolioId":10,"children":78},"item-22",{"de":69,"en":69,"es":70,"fr":69,"it":71,"ru":72,"sr":73,"zh":74},"Vision","Visión","Visione","Видение","Визија","想象","\u002Fueber-uns-webdesign-muenchen-webaplikation","i-lucide-eye",113,[],{"id":80,"title":81,"url":89,"target":61,"icon":90,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":91,"portfolioId":10,"children":92},"item-19",{"de":82,"en":83,"es":84,"fr":83,"it":85,"ru":86,"sr":87,"zh":88},"Leistungen","Services","Servicios","Servizi","Услуги","Услуге","服务","\u002Fservices-dienstleistungen-muenchen","i-lucide-wrench",116,[],{"id":94,"title":95,"url":99,"target":61,"icon":100,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":101,"portfolioId":10,"children":102},"item-23",{"de":96,"en":96,"es":96,"fr":96,"it":96,"ru":97,"sr":97,"zh":98},"Blog","Блог","博客","\u002Fblog","i-lucide-book-open",112,[],{"id":104,"title":105,"url":114,"target":61,"icon":115,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":116,"portfolioId":10,"children":117},"item-32",{"de":106,"en":107,"es":108,"fr":109,"it":110,"ru":111,"sr":112,"zh":113},"Neue Technologien","New Technologies","Nuevas tecnologías","Nouvelles technologies","Nuove tecnologie","Новые технологии","Нове технологије","新技术！","\u002Fneue-webtechnologien","i-lucide-sparkles",122,[],{"id":119,"title":120,"url":129,"target":61,"icon":130,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":131,"portfolioId":10,"children":132},"item-20",{"de":121,"en":122,"es":123,"fr":124,"it":125,"ru":126,"sr":127,"zh":128},"Kontakt","Contact us!","Contacto","Contact","Contatto","Контакт","Контактирајте нас","联系我们！","\u002Fcontact","i-lucide-mail",115,[],{"id":134,"title":135,"url":144,"target":61,"icon":145,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":147},"item-21",{"de":136,"en":137,"es":138,"fr":139,"it":140,"ru":141,"sr":142,"zh":143},"Unsere Arbeit","Our Work","Nuestro trabajo","Nos réalisations","I nostri lavori","Наши работы","Наши радови","文件夹","\u002Fportfolio","i-lucide-briefcase",114,[148,161,175,181,193],{"id":149,"title":150,"url":144,"target":61,"icon":159,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":160},"item-24",{"de":151,"en":152,"es":153,"fr":154,"it":155,"ru":156,"sr":157,"zh":158},"Alle Projekte","All Projects","Todos los proyectos","Tous les projets","Tutti i progetti","Все проекты","Сви пројекти","所有项目","i-lucide-grid-3x3",[],{"id":162,"title":163,"url":171,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":174},"item-29",{"de":164,"en":165,"es":166,"fr":167,"it":168,"ru":169,"sr":170,"zh":143},"Local Roots, Global Reach","Local Roots - Global Reach","Empresa local ","Entreprise locale","Azienda locale","Местная компания","Локално предузеће глобално тржиште","\u002Fportfolio\u002Flocal-roots-global-reach-communication-media-systems-for-modern-business","i-lucide-folder","custom",[],{"id":176,"title":177,"url":179,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":180},"item-28",{"de":178,"en":178,"es":178,"fr":178,"it":178,"ru":178,"sr":178,"zh":178},"Solr Suggester","\u002Fportfolio\u002Fsolr-fuzzy-suggester-und-solr-infix-suggester-abfrage-ueber-ajax-und-filterung",[],{"id":182,"title":183,"url":191,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":192},"item-27",{"de":184,"en":185,"es":186,"fr":187,"it":188,"ru":189,"sr":190,"zh":185},"Firmenwebseite SEO","Company Website SEO","Sitio web corporativo SEO","Site web d’entreprise SEO","Sito web aziendale SEO","Корпоративный сайт SEO","Пословна веб-страница SEO","\u002Fportfolio\u002Fseo-sem-branding-mobile-webseite-muenchen",[],{"id":194,"title":195,"url":203,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":204},"item-31",{"de":196,"en":197,"es":198,"fr":199,"it":200,"ru":201,"sr":202,"zh":197},"Digitalisierungsportal","Digitalization Portal","Portal de digitalización","Portail de numérisation","Portale di digitalizzazione","Портал цифровизации","Портал за дигитализацију","\u002Fportfolio\u002Fdigitalisierungsportal-archiv-museum-bibliothek-ead-lido-mets-mods",[],{"statusCode":4,"data":206,"message":1129},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":561,"featuredImage":562,"featuredImageAlt":563,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":564,"publishedAt":565,"createdAt":566,"updatedAt":567,"seoLocalePaths":568,"categories":577,"author":586,"translations":591},"460","Надёжность ИИ-агентов: почему финального ответа недостаточно","ai-agent-reliability-why-the-final-answer-is-not-enough","\u003Cp>\u003Cb>Правильный результат не доказывает правильность рассуждений, безопасность выполнения или надежность системы.\u003C\u002Fb>\u003C\u002Fp>\n\u003Cp>В течение многих лет оценка ИИ была сосредоточена на обманчиво простом вопросе: \u003Cb>Был ли ответ правильным?\u003C\u002Fb> Для чат-бота этого иногда может быть достаточно. Для агента, способного искать в системах, читать данные, вызывать инструменты, изменять состояние, выполнять рабочие процессы, записывать файлы, взаимодействовать с API или принимать решения, этого недостаточно.\u003C\u002Fp>\n\u003Cp>Агент может дать правильный окончательный ответ, совершив несколько ошибок по пути. Он может использовать неправильный источник, неправильно понять инструкцию и затем компенсировать ошибку, получить доступ к ненужной информации, выполнить несанкционированное промежуточное действие, молча восстановиться после ошибки, которая должна была вызвать эскалацию, или оставить побочные эффекты, которые никто не заметил.\u003C\u002Fp>\n\u003Cp>Это создает одну из центральных проблем агентного ИИ: \u003Cb>правильный результат не доказывает правильность траектории.\u003C\u002Fb>\u003C\u002Fp>\n\u003Ch2>Иллюзия результата\u003C\u002Fh2>\n\u003Cp>Традиционное программное обеспечение дает нам интуитивную модель правильности. Входные данные поступают в детерминированную или почти детерминированную систему, логика выполняется, выходные данные производятся, и тесты проверяют ожидаемое поведение. Системы на основе LLM ослабляют это предположение. Агентные системы идут дальше.\u003C\u002Fp>\n\u003Cul>\u003Cli>интерпретация модели\u003C\u002Fli>\u003Cli>полученный контекст\u003C\u002Fli>\u003Cli>выбор инструмента\u003C\u002Fli>\u003Cli>промежуточные наблюдения\u003C\u002Fli>\u003Cli>внешнее состояние\u003C\u002Fli>\u003Cli>предыдущие действия\u003C\u002Fli>\u003Cli>сгенерированные моделью планы\u003C\u002Fli>\u003Cli>границы разрешений\u003C\u002Fli>\u003Cli>повторные попытки и запасное поведение\u003C\u002Fli>\u003Cli>взаимодействие с человеком\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Два выполнения, начинающиеся с почти одинаковых входных данных, могут достичь одного и того же результата разными путями. Если оценка наблюдает только за конечным результатом, большая часть системы остается невидимой.\u003C\u002Fp>\n\u003Cp>Представьте, что агент ИИ получает инструкцию: \u003Ci>Обновите платежный адрес клиента.\u003C\u002Fi> Адрес в конечном итоге обновлен правильно. Обычная оценка может классифицировать задачу как успешную.\u003C\u002Fp>\n\u003Col>\u003Cli>Агент ищет несколько несвязанных записей клиентов.\u003C\u002Fli>\u003Cli>Он получает больше личной информации, чем требуется.\u003C\u002Fli>\u003Cli>Он изначально изменяет неправильную учетную запись.\u003C\u002Fli>\u003Cli>Он замечает ошибку.\u003C\u002Fli>\u003Cli>Он отменяет изменение.\u003C\u002Fli>\u003Cli>Он обновляет правильную учетную запись.\u003C\u002Fli>\u003Cli>Он сообщает об успехе.\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>\u003Cb>Конечное состояние: правильно. Поведение системы: неприемлемо.\u003C\u002Fb> Бенчмарк, основанный только на результате, пропускает это выполнение. Система производственной гарантии не должна.\u003C\u002Fp>\n\u003Ch2>Траектория является частью продукта\u003C\u002Fh2>\n\u003Cp>Вот почему \u003Cb>траектория\u003C\u002Fb> агента ИИ должна стать первоклассным инженерным объектом. Траектория — это последовательность соответствующих состояний и действий между исходным запросом и конечным результатом.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>Намерение → Контекст → Решение → Инструмент → Действие → Наблюдение → Решение → Изменение состояния → Результат\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Закари Дж. Стивенс развивает эту идею в \u003Ci>Траектория — это система\u003C\u002Fi>, утверждая, что агентная оценка должна выходить за рамки окончательного ответа и исследовать полный путь действий в изменяющейся среде.\u003C\u002Fp>\n\u003Cblockquote class=\"border-l-4 border-gray-300 pl-4 italic\">Правильный результат не оправдывает неприемлемую траекторию.\u003Ccite class=\"block mt-2 text-sm\">— Закари Дж. Стивенс, Траектория — это система\u003C\u002Fcite>\u003C\u002Fblockquote>\n\u003Ca href=\"https:\u002F\u002Fzacharyjstevens.com\u002Fdispatches\u002Fvanguard-signal\u002F009-the-trajectory-is-the-system\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Траектория — это система\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Закари Дж. Стивенс — DFEI.009 об оценке агентных систем по их полной траектории, а не только по конечному результату.\u003C\u002Fp>\u003C\u002Fa>\n\u003Cp>Это различие имеет огромное значение. Поэтому надежность — это не просто \u003Cb>правильный результат\u003C\u002Fb>. Это скорее \u003Cb>приемлемый результат + приемлемая траектория + восстанавливаемость + доказательства\u003C\u002Fb>.\u003C\u002Fp>\n\u003Ch2>Правильный ответ может скрывать сломанную систему\u003C\u002Fh2>\n\u003Ctable class=\"w-full border-collapse\">\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Агент\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Итоговый результат\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Выполнение\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">A\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Правильный\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Правильный путь\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">B\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Правильный\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Небезопасный путь\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">C\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Неправильный\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Безопасный сбой\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">D\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Неправильный\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Небезопасный сбой\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftable>\n\u003Cp>Большинство оценок на основе бенчмарков сильно вознаграждают A и B и наказывают C и D. Однако с операционной точки зрения \u003Cb>B может быть опаснее, чем C\u003C\u002Fb>. Агент C может распознать неопределенность, остановить выполнение и запросить проверку человеком. Агент B может уверенно выдавать правильные результаты, нарушая предположения, за которыми никто не следит.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>успешный вывод → повышенное доверие → более широкие разрешения → больше автоматизации → больший радиус поражения\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>Нам нужны доказательства, а не уверенность\u003C\u002Fh2>\n\u003Cp>Одна из самых больших ошибок при внедрении ИИ — рассматривать уверенность модели, удовлетворенность пользователей или исторический показатель успеха как доказательство надежности системы. Это не эквивалентные вещи.\u003C\u002Fp>\n\u003Cul>\u003Cli>Что получил агент?\u003C\u002Fli>\u003Cli>Какой контекст он извлек?\u003C\u002Fli>\u003Cli>Какие инструменты он вызвал?\u003C\u002Fli>\u003Cli>Почему действие было разрешено?\u003C\u002Fli>\u003Cli>Какое состояние существовало до действия?\u003C\u002Fli>\u003Cli>Что изменилось?\u003C\u002Fli>\u003Cli>Какие промежуточные сбои произошли?\u003C\u002Fli>\u003Cli>Были ли повторные попытки?\u003C\u002Fli>\u003Cli>Требовалось ли одобрение человека?\u003C\u002Fli>\u003Cli>Можно ли было остановить выполнение?\u003C\u002Fli>\u003Cli>Можно ли отменить действие?\u003C\u002Fli>\u003Cli>Какие версии модели, промпта и инструментов были задействованы?\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Без этих ответов нет серьезной операционной гарантии. Есть только вывод. Поэтому наблюдаемость и доказательства должны быть встроены в архитектуру агента, а не добавлены после развертывания.\u003C\u002Fp>\n\u003Ch2>Логирование — это не то же самое, что контроль\u003C\u002Fh2>\n\u003Cp>Организации часто отвечают: \u003Ci>Все логируется.\u003C\u002Fi> Хорошо. Но одно лишь логирование ничего не контролирует. Лог говорит вам, что произошло. Контроль определяет, может ли что-то \u003Cb>произойти\u003C\u002Fb>.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>Агент запрашивает DELETE \u002Fcustomer\u002F123 ↓\nДействие залогировано ↓\nDELETE выполнен\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Это дает наблюдаемость. Сравните с:\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>Агент запрашивает DELETE \u002Fcustomer\u002F123 ↓\nОценка политики ↓\nПроверка текущей личности ↓\nПроверка параметров текущего действия ↓\nОценка порога риска ↓\nОдобрение человека, если требуется ↓\nДействие выполнено ↓\nРезультат проверен ↓\nДоказательства сохранены\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Теперь мы приближаемся к системе контроля. Разница архитектурная, а не косметическая.\u003C\u002Fp>\n\u003Ch2>Разрешение необходимо — но это не гарантия\u003C\u002Fh2>\n\u003Cp>Предположим, у агента есть разрешение отправлять электронные письма. Контроль доступа отвечает на вопрос: \u003Cb>Может ли этот агент отправлять электронные письма?\u003C\u002Fb> Он не отвечает на вопрос: \u003Cb>Должно ли это конкретное письмо быть отправлено этому конкретному человеку с этим конкретным вложением прямо сейчас?\u003C\u002Fb>\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>КОНТРОЛЬ ВОЗМОЖНОСТЕЙ\nЧто агенту технически разрешено делать? + ГАРАНТИЯ ДЕЙСТВИЯ\nЯвляется ли это конкретное действие уместным в текущем состоянии?\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>RBAC, области OAuth, разрешения API и идентификаторы агентов определяют пространство возможных действий. Они не доказывают, что действие в этом пространстве уместно. Сильная архитектура агента требует обоих уровней.\u003C\u002Fp>\n\u003Ch2>Первый неверный шаг имеет значение\u003C\u002Fh2>\n\u003Cp>Когда агент терпит неудачу, финальное неверное действие часто не является началом сбоя. Настоящий сбой мог произойти гораздо раньше.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>Неверный поиск ↓\nНеверное предположение ↓\nПравдоподобное рассуждение ↓\nДопустимый вызов инструмента ↓\nНеверное действие\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Если мы исследуем только финальное действие, мы устраняем симптом. Если мы анализируем траекторию, мы можем определить \u003Cb>первый неверный шаг\u003C\u002Fb>. Это превращает неприписываемый сбой в конкретную инженерную проблему.\u003C\u002Fp>\n\u003Ch2>Тестирование агентов должно выходить за рамки тестирования промптов\u003C\u002Fh2>\n\u003Cp>Промпты важны, но поведение агента в производственной среде возникает из целой системы.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>МОДЕЛЬ\n+\nСИСТЕМНЫЙ ПРОМПТ\n+\nКОНТЕКСТ\n+\nПАМЯТЬ\n+\nПОИСК\n+\nИНСТРУМЕНТЫ\n+\nРАЗРЕШЕНИЯ\n+\nРАБОЧИЙ ПРОЦЕСС\n+\nВНЕШНЕЕ СОСТОЯНИЕ\n+\nЛОГИКА УПРАВЛЕНИЯ\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Изменение любого из этих элементов может изменить траекторию. Поэтому версионирование только промпта недостаточно.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>версия_модели\nверсия_промпта\nверсия_инструмента\nверсия_политики\nверсия_поиска\nверсия_рабочего_процесса\nсостояние_среды\nидентификатор_выполнения\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>Критерии приемки для агентов должны включать поведение\u003C\u002Fh2>\n\u003Cp>Традиционные критерии приемки часто выглядят так: \u003Ci>При условии X система производит Y.\u003C\u002Fi> Для агентных систем этого недостаточно. Критерии приемки также должны определять ограничения на траекторию.\u003C\u002Fp>\n\u003Ch3>Результат\u003C\u002Fh3>\n\u003Cp>Адрес клиента обновлен корректно.\u003C\u002Fp>\n\u003Ch3>Авторизация\u003C\u002Fh3>\n\u003Cp>Агент изменяет только явно выбранного клиента.\u003C\u002Fp>\n\u003Ch3>Доступ к данным\u003C\u002Fh3>\n\u003Cp>Нет доступа к несвязанным записям клиентов.\u003C\u002Fp>\n\u003Ch3>Инструменты\u003C\u002Fh3>\n\u003Cp>Используются только одобренные операции CRM.\u003C\u002Fp>\n\u003Ch3>Проверка\u003C\u002Fh3>\n\u003Cp>Новый адрес считывается и сравнивается с запрошенным значением.\u003C\u002Fp>\n\u003Ch3>Сбой\u003C\u002Fh3>\n\u003Cp>Неоднозначное разрешение идентичности останавливает выполнение.\u003C\u002Fp>\n\u003Ch3>Полномочия человека\u003C\u002Fh3>\n\u003Cp>Человек может отклонить изменение до выполнения, когда пороги риска требуют одобрения.\u003C\u002Fp>\n\u003Ch3>Доказательства\u003C\u002Fh3>\n\u003Cp>Выполнение оставляет след, достаточный для восстановления решения и перехода состояния.\u003C\u002Fp>\n\u003Ch3>Восстановление\u003C\u002Fh3>\n\u003Cp>Предыдущее значение остается восстанавливаемым.\u003C\u002Fp>\n\u003Ch2>Человек в цикле недостаточен\u003C\u002Fh2>\n\u003Cp>Добавление окна одобрения человеком не решает проблему автоматически. Человек может контролировать агента только в том случае, если у него есть видимость, полномочия, время, контекст и возможность восстановления.\u003C\u002Fp>\n\u003Cul>\u003Cli>\u003Cb>Видимость:\u003C\u002Fb> достаточно информации, чтобы понять, что происходит.\u003C\u002Fli>\u003Cli>\u003Cb>Полномочия:\u003C\u002Fb> реальная возможность остановить или изменить действие.\u003C\u002Fli>\u003Cli>\u003Cb>Время:\u003C\u002Fb> вмешательство до наступления последствий.\u003C\u002Fli>\u003Cli>\u003Cb>Контекст:\u003C\u002Fb> достаточные доказательства для принятия решения.\u003C\u002Fli>\u003Cli>\u003Cb>Возможность восстановления:\u003C\u002Fb> способность отменить или исправить действие.\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Пользователь, нажимающий \u003Cb>Одобрить\u003C\u002Fb> на то, что он не может осмысленно проверить, — это не надежное управление. Это театр одобрения.\u003C\u002Fp>\n\u003Ch2>Откат должен стать встроенной возможностью ИИ\u003C\u002Fh2>\n\u003Cp>Традиционное развертывание программного обеспечения научило нас ценной вещи: \u003Cb>Никогда не развертывайте то, что нельзя откатить.\u003C\u002Fb> Мы должны применить тот же принцип к действиям агентов.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>ОБРАТИМЫЙ\nМожет автоматически отменить. КОМПЕНСИРУЕМЫЙ\nНе может отменить напрямую, но может выполнить компенсирующее действие. НЕОБРАТИМЫЙ\nНе может надежно восстановить предыдущее состояние.\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Чем выше необратимость, тем сильнее должно быть требование к контролю.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>Чтение публичного документа → низкие последствия\nСоздание черновика → обратимо\nИзменение записи в CRM → обратимо, но имеет последствия\nОтправка внешнего письма → практически необратимо\nПеревод денег → высокие последствия\nУдаление производственных данных → потенциально катастрофично\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>Агенту нужна плоскость управления\u003C\u002Fh2>\n\u003Cpre class=\"code-block\">\u003Ccode>ПОЛЬЗОВАТЕЛЬ \u002F СИСТЕМНОЕ НАМЕРЕНИЕ │ ▼ ИИ-АГЕНТ │ предлагаемое действие │ ▼ ┌───────────────────┐ │ ПЛОСКОСТЬ УПРАВЛЕНИЯ │ ├───────────────────┤ │ Идентичность │ │ Авторизация │ │ Политика │ │ Риск │ │ Состояние │ │ Доказательства │ │ Человеческий авторитет │ │ Откат │ └───────────────────┘ │ одобрено? \u002F \\ НЕТ ДА │ │ СТОП ▼ ИНСТРУМЕНТ │ ▼ ИЗМЕНЕНИЕ СОСТОЯНИЯ │ ▼ ПРОВЕРКА\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cb>Языковая модель должна предлагать. Плоскость управления должна управлять.\u003C\u002Fb> Это разделение критически важно. Модель не должна быть высшим авторитетом, определяющим, безопасно ли её собственное предлагаемое действие с высоким воздействием.\u003C\u002Fp>\n\u003Ch2>От бенчмарков к операционному доверию\u003C\u002Fh2>\n\u003Cp>Бенчмарки остаются полезными. Они говорят нам о возможностях, сравнивают модели, обнаруживают регрессии и помогают оценить ожидаемую производительность. Но оценка возможностей и операционное доверие отвечают на разные вопросы.\u003C\u002Fp>\n\u003Cp>Бенчмарк спрашивает: \u003Cb>Может ли система это сделать?\u003C\u002Fb> Операционная гарантия спрашивает: \u003Cb>Можем ли мы позволить системе сделать это здесь, в этих условиях, с этими разрешениями и последствиями?\u003C\u002Fb>\u003C\u002Fp>\n\u003Ch2>Надёжность следует измерять как свойство системы\u003C\u002Fh2>\n\u003Col>\u003Cli>\u003Cb>Правильность результата:\u003C\u002Fb> Произвела ли система ожидаемый результат?\u003C\u002Fli>\u003Cli>\u003Cb>Правильность траектории:\u003C\u002Fb> Следовала ли она приемлемым путём?\u003C\u002Fli>\u003Cli>\u003Cb>Целостность контроля:\u003C\u002Fb> Соблюдались ли границы авторизации, политики и вмешательства?\u003C\u002Fli>\u003Cli>\u003Cb>Восстанавливаемость:\u003C\u002Fb> Можно ли сдержать, обратить или исправить сбои?\u003C\u002Fli>\u003Cli>\u003Cb>Полнота доказательств:\u003C\u002Fb> Можно ли реконструировать и проверить выполнение?\u003C\u002Fli>\u003C\u002Fol>\n\u003Cpre class=\"code-block\">\u003Ccode>Операционная надёжность\n=\nРезультат × Траектория × Контроль × Восстанавливаемость × Доказательства\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Умножение не случайно. Если одно критическое измерение приближается к нулю, высокий балл в другом месте не должен это скрывать. Идеально правильный результат с нулевой целостностью авторизации — это не система с надёжностью 80%. Это неприемлемое выполнение, которое случайно дало правильный ответ.\u003C\u002Fp>\n\u003Ch2>Успех иногда — самый опасный сбой\u003C\u002Fh2>\n\u003Cp>Сбои привлекают внимание. Успех — часто нет. Это делает успешные, но неконтролируемые траектории агента особенно опасными. Очевидный сбой создаёт инцидент. Скрытый дефект траектории создаёт \u003Cb>уверенность\u003C\u002Fb>. А уверенность расширяет автономию.\u003C\u002Fp>\n\u003Cp>Поэтому организациям следует не только расследовать \u003Ci>Почему агент потерпел неудачу?\u003C\u002Fi> Им следует периодически спрашивать: \u003Cb>Почему агент добился успеха?\u003C\u002Fb> Добился ли он успеха, потому что архитектура надёжно ограничивала и проверяла выполнение, или потому, что на этот раз ничего не пошло не так?\u003C\u002Fp>\n\u003Ch2>Заключение\u003C\u002Fh2>\n\u003Cp>Индустрия быстро движется от ИИ, который \u003Cb>отвечает\u003C\u002Fb>, к ИИ, который \u003Cb>действует\u003C\u002Fb>. Этот переход меняет значение надёжности. Для системы ответов оценка ответа часто может быть достаточной. Для системы действий мы должны оценивать путь.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>Запрос ↓\nОтвет становится намерением ↓\nТраектория ↓\nДействия ↓\nИзменения состояния ↓\nДоказательства ↓\nРезультат\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Окончательный ответ остается важным, но это лишь видимый конец гораздо большей системы. Как только ИИ получает возможность влиять на реальный мир, \u003Cb>путь к ответу становится частью ответа.\u003C\u002Fb>\u003C\u002Fp>",{"time":212,"blocks":213,"version":560},1788955841547,[214,218,221,224,227,231,234,249,252,255,266,269,272,275,279,282,288,296,299,302,324,327,330,333,336,351,354,357,360,363,366,369,372,375,378,381,384,387,390,393,396,399,402,405,408,411,414,417,421,424,427,430,433,436,439,442,445,448,451,454,457,460,463,466,469,472,475,478,486,489,492,495,498,501,504,507,510,513,516,519,522,525,533,536,539,542,545,548,551,554,557],{"data":215,"type":217},{"text":216},"\u003Cb>Правильный результат не доказывает правильность рассуждений, безопасность выполнения или надежность системы.\u003C\u002Fb>","paragraph",{"data":219,"type":217},{"text":220},"В течение многих лет оценка ИИ была сосредоточена на обманчиво простом вопросе: \u003Cb>Был ли ответ правильным?\u003C\u002Fb> Для чат-бота этого иногда может быть достаточно. Для агента, способного искать в системах, читать данные, вызывать инструменты, изменять состояние, выполнять рабочие процессы, записывать файлы, взаимодействовать с API или принимать решения, этого недостаточно.",{"data":222,"type":217},{"text":223},"Агент может дать правильный окончательный ответ, совершив несколько ошибок по пути. Он может использовать неправильный источник, неправильно понять инструкцию и затем компенсировать ошибку, получить доступ к ненужной информации, выполнить несанкционированное промежуточное действие, молча восстановиться после ошибки, которая должна была вызвать эскалацию, или оставить побочные эффекты, которые никто не заметил.",{"data":225,"type":217},{"text":226},"Это создает одну из центральных проблем агентного ИИ: \u003Cb>правильный результат не доказывает правильность траектории.\u003C\u002Fb>",{"data":228,"type":42},{"text":229,"level":230},"Иллюзия результата",2,{"data":232,"type":217},{"text":233},"Традиционное программное обеспечение дает нам интуитивную модель правильности. Входные данные поступают в детерминированную или почти детерминированную систему, логика выполняется, выходные данные производятся, и тесты проверяют ожидаемое поведение. Системы на основе LLM ослабляют это предположение. Агентные системы идут дальше.",{"data":235,"type":248},{"items":236,"style":247},[237,238,239,240,241,242,243,244,245,246],"интерпретация модели","полученный контекст","выбор инструмента","промежуточные наблюдения","внешнее состояние","предыдущие действия","сгенерированные моделью планы","границы разрешений","повторные попытки и запасное поведение","взаимодействие с человеком","unordered","list",{"data":250,"type":217},{"text":251},"Два выполнения, начинающиеся с почти одинаковых входных данных, могут достичь одного и того же результата разными путями. Если оценка наблюдает только за конечным результатом, большая часть системы остается невидимой.",{"data":253,"type":217},{"text":254},"Представьте, что агент ИИ получает инструкцию: \u003Ci>Обновите платежный адрес клиента.\u003C\u002Fi> Адрес в конечном итоге обновлен правильно. Обычная оценка может классифицировать задачу как успешную.",{"data":256,"type":248},{"items":257,"style":265},[258,259,260,261,262,263,264],"Агент ищет несколько несвязанных записей клиентов.","Он получает больше личной информации, чем требуется.","Он изначально изменяет неправильную учетную запись.","Он замечает ошибку.","Он отменяет изменение.","Он обновляет правильную учетную запись.","Он сообщает об успехе.","ordered",{"data":267,"type":217},{"text":268},"\u003Cb>Конечное состояние: правильно. Поведение системы: неприемлемо.\u003C\u002Fb> Бенчмарк, основанный только на результате, пропускает это выполнение. Система производственной гарантии не должна.",{"data":270,"type":42},{"text":271,"level":230},"Траектория является частью продукта",{"data":273,"type":217},{"text":274},"Вот почему \u003Cb>траектория\u003C\u002Fb> агента ИИ должна стать первоклассным инженерным объектом. Траектория — это последовательность соответствующих состояний и действий между исходным запросом и конечным результатом.",{"data":276,"type":278},{"code":277},"Намерение → Контекст → Решение → Инструмент → Действие → Наблюдение → Решение → Изменение состояния → Результат","code",{"data":280,"type":217},{"text":281},"Закари Дж. Стивенс развивает эту идею в \u003Ci>Траектория — это система\u003C\u002Fi>, утверждая, что агентная оценка должна выходить за рамки окончательного ответа и исследовать полный путь действий в изменяющейся среде.",{"data":283,"type":287},{"text":284,"caption":285,"alignment":286},"Правильный результат не оправдывает неприемлемую траекторию.","Закари Дж. Стивенс, Траектория — это система","left","quote",{"data":289,"type":295},{"link":290,"meta":291},"https:\u002F\u002Fzacharyjstevens.com\u002Fdispatches\u002Fvanguard-signal\u002F009-the-trajectory-is-the-system\u002F",{"image":292,"title":293,"description":294},{},"Траектория — это система","Закари Дж. Стивенс — DFEI.009 об оценке агентных систем по их полной траектории, а не только по конечному результату.","linkTool",{"data":297,"type":217},{"text":298},"Это различие имеет огромное значение. Поэтому надежность — это не просто \u003Cb>правильный результат\u003C\u002Fb>. Это скорее \u003Cb>приемлемый результат + приемлемая траектория + восстанавливаемость + доказательства\u003C\u002Fb>.",{"data":300,"type":42},{"text":301,"level":230},"Правильный ответ может скрывать сломанную систему",{"data":303,"type":323},{"content":304,"withHeadings":14},[305,309,313,316,320],[306,307,308],"Агент","Итоговый результат","Выполнение",[310,311,312],"A","Правильный","Правильный путь",[314,311,315],"B","Небезопасный путь",[317,318,319],"C","Неправильный","Безопасный сбой",[321,318,322],"D","Небезопасный сбой","table",{"data":325,"type":217},{"text":326},"Большинство оценок на основе бенчмарков сильно вознаграждают A и B и наказывают C и D. Однако с операционной точки зрения \u003Cb>B может быть опаснее, чем C\u003C\u002Fb>. Агент C может распознать неопределенность, остановить выполнение и запросить проверку человеком. Агент B может уверенно выдавать правильные результаты, нарушая предположения, за которыми никто не следит.",{"data":328,"type":278},{"code":329},"успешный вывод → повышенное доверие → более широкие разрешения → больше автоматизации → больший радиус поражения",{"data":331,"type":42},{"text":332,"level":230},"Нам нужны доказательства, а не уверенность",{"data":334,"type":217},{"text":335},"Одна из самых больших ошибок при внедрении ИИ — рассматривать уверенность модели, удовлетворенность пользователей или исторический показатель успеха как доказательство надежности системы. Это не эквивалентные вещи.",{"data":337,"type":248},{"items":338,"style":247},[339,340,341,342,343,344,345,346,347,348,349,350],"Что получил агент?","Какой контекст он извлек?","Какие инструменты он вызвал?","Почему действие было разрешено?","Какое состояние существовало до действия?","Что изменилось?","Какие промежуточные сбои произошли?","Были ли повторные попытки?","Требовалось ли одобрение человека?","Можно ли было остановить выполнение?","Можно ли отменить действие?","Какие версии модели, промпта и инструментов были задействованы?",{"data":352,"type":217},{"text":353},"Без этих ответов нет серьезной операционной гарантии. Есть только вывод. Поэтому наблюдаемость и доказательства должны быть встроены в архитектуру агента, а не добавлены после развертывания.",{"data":355,"type":42},{"text":356,"level":230},"Логирование — это не то же самое, что контроль",{"data":358,"type":217},{"text":359},"Организации часто отвечают: \u003Ci>Все логируется.\u003C\u002Fi> Хорошо. Но одно лишь логирование ничего не контролирует. Лог говорит вам, что произошло. Контроль определяет, может ли что-то \u003Cb>произойти\u003C\u002Fb>.",{"data":361,"type":278},{"code":362},"Агент запрашивает DELETE \u002Fcustomer\u002F123 ↓\nДействие залогировано ↓\nDELETE выполнен",{"data":364,"type":217},{"text":365},"Это дает наблюдаемость. Сравните с:",{"data":367,"type":278},{"code":368},"Агент запрашивает DELETE \u002Fcustomer\u002F123 ↓\nОценка политики ↓\nПроверка текущей личности ↓\nПроверка параметров текущего действия ↓\nОценка порога риска ↓\nОдобрение человека, если требуется ↓\nДействие выполнено ↓\nРезультат проверен ↓\nДоказательства сохранены",{"data":370,"type":217},{"text":371},"Теперь мы приближаемся к системе контроля. Разница архитектурная, а не косметическая.",{"data":373,"type":42},{"text":374,"level":230},"Разрешение необходимо — но это не гарантия",{"data":376,"type":217},{"text":377},"Предположим, у агента есть разрешение отправлять электронные письма. Контроль доступа отвечает на вопрос: \u003Cb>Может ли этот агент отправлять электронные письма?\u003C\u002Fb> Он не отвечает на вопрос: \u003Cb>Должно ли это конкретное письмо быть отправлено этому конкретному человеку с этим конкретным вложением прямо сейчас?\u003C\u002Fb>",{"data":379,"type":278},{"code":380},"КОНТРОЛЬ ВОЗМОЖНОСТЕЙ\nЧто агенту технически разрешено делать? + ГАРАНТИЯ ДЕЙСТВИЯ\nЯвляется ли это конкретное действие уместным в текущем состоянии?",{"data":382,"type":217},{"text":383},"RBAC, области OAuth, разрешения API и идентификаторы агентов определяют пространство возможных действий. Они не доказывают, что действие в этом пространстве уместно. Сильная архитектура агента требует обоих уровней.",{"data":385,"type":42},{"text":386,"level":230},"Первый неверный шаг имеет значение",{"data":388,"type":217},{"text":389},"Когда агент терпит неудачу, финальное неверное действие часто не является началом сбоя. Настоящий сбой мог произойти гораздо раньше.",{"data":391,"type":278},{"code":392},"Неверный поиск ↓\nНеверное предположение ↓\nПравдоподобное рассуждение ↓\nДопустимый вызов инструмента ↓\nНеверное действие",{"data":394,"type":217},{"text":395},"Если мы исследуем только финальное действие, мы устраняем симптом. Если мы анализируем траекторию, мы можем определить \u003Cb>первый неверный шаг\u003C\u002Fb>. Это превращает неприписываемый сбой в конкретную инженерную проблему.",{"data":397,"type":42},{"text":398,"level":230},"Тестирование агентов должно выходить за рамки тестирования промптов",{"data":400,"type":217},{"text":401},"Промпты важны, но поведение агента в производственной среде возникает из целой системы.",{"data":403,"type":278},{"code":404},"МОДЕЛЬ\n+\nСИСТЕМНЫЙ ПРОМПТ\n+\nКОНТЕКСТ\n+\nПАМЯТЬ\n+\nПОИСК\n+\nИНСТРУМЕНТЫ\n+\nРАЗРЕШЕНИЯ\n+\nРАБОЧИЙ ПРОЦЕСС\n+\nВНЕШНЕЕ СОСТОЯНИЕ\n+\nЛОГИКА УПРАВЛЕНИЯ",{"data":406,"type":217},{"text":407},"Изменение любого из этих элементов может изменить траекторию. Поэтому версионирование только промпта недостаточно.",{"data":409,"type":278},{"code":410},"версия_модели\nверсия_промпта\nверсия_инструмента\nверсия_политики\nверсия_поиска\nверсия_рабочего_процесса\nсостояние_среды\nидентификатор_выполнения",{"data":412,"type":42},{"text":413,"level":230},"Критерии приемки для агентов должны включать поведение",{"data":415,"type":217},{"text":416},"Традиционные критерии приемки часто выглядят так: \u003Ci>При условии X система производит Y.\u003C\u002Fi> Для агентных систем этого недостаточно. Критерии приемки также должны определять ограничения на траекторию.",{"data":418,"type":42},{"text":419,"level":420},"Результат",3,{"data":422,"type":217},{"text":423},"Адрес клиента обновлен корректно.",{"data":425,"type":42},{"text":426,"level":420},"Авторизация",{"data":428,"type":217},{"text":429},"Агент изменяет только явно выбранного клиента.",{"data":431,"type":42},{"text":432,"level":420},"Доступ к данным",{"data":434,"type":217},{"text":435},"Нет доступа к несвязанным записям клиентов.",{"data":437,"type":42},{"text":438,"level":420},"Инструменты",{"data":440,"type":217},{"text":441},"Используются только одобренные операции CRM.",{"data":443,"type":42},{"text":444,"level":420},"Проверка",{"data":446,"type":217},{"text":447},"Новый адрес считывается и сравнивается с запрошенным значением.",{"data":449,"type":42},{"text":450,"level":420},"Сбой",{"data":452,"type":217},{"text":453},"Неоднозначное разрешение идентичности останавливает выполнение.",{"data":455,"type":42},{"text":456,"level":420},"Полномочия человека",{"data":458,"type":217},{"text":459},"Человек может отклонить изменение до выполнения, когда пороги риска требуют одобрения.",{"data":461,"type":42},{"text":462,"level":420},"Доказательства",{"data":464,"type":217},{"text":465},"Выполнение оставляет след, достаточный для восстановления решения и перехода состояния.",{"data":467,"type":42},{"text":468,"level":420},"Восстановление",{"data":470,"type":217},{"text":471},"Предыдущее значение остается восстанавливаемым.",{"data":473,"type":42},{"text":474,"level":230},"Человек в цикле недостаточен",{"data":476,"type":217},{"text":477},"Добавление окна одобрения человеком не решает проблему автоматически. Человек может контролировать агента только в том случае, если у него есть видимость, полномочия, время, контекст и возможность восстановления.",{"data":479,"type":248},{"items":480,"style":247},[481,482,483,484,485],"\u003Cb>Видимость:\u003C\u002Fb> достаточно информации, чтобы понять, что происходит.","\u003Cb>Полномочия:\u003C\u002Fb> реальная возможность остановить или изменить действие.","\u003Cb>Время:\u003C\u002Fb> вмешательство до наступления последствий.","\u003Cb>Контекст:\u003C\u002Fb> достаточные доказательства для принятия решения.","\u003Cb>Возможность восстановления:\u003C\u002Fb> способность отменить или исправить действие.",{"data":487,"type":217},{"text":488},"Пользователь, нажимающий \u003Cb>Одобрить\u003C\u002Fb> на то, что он не может осмысленно проверить, — это не надежное управление. Это театр одобрения.",{"data":490,"type":42},{"text":491,"level":230},"Откат должен стать встроенной возможностью ИИ",{"data":493,"type":217},{"text":494},"Традиционное развертывание программного обеспечения научило нас ценной вещи: \u003Cb>Никогда не развертывайте то, что нельзя откатить.\u003C\u002Fb> Мы должны применить тот же принцип к действиям агентов.",{"data":496,"type":278},{"code":497},"ОБРАТИМЫЙ\nМожет автоматически отменить. КОМПЕНСИРУЕМЫЙ\nНе может отменить напрямую, но может выполнить компенсирующее действие. НЕОБРАТИМЫЙ\nНе может надежно восстановить предыдущее состояние.",{"data":499,"type":217},{"text":500},"Чем выше необратимость, тем сильнее должно быть требование к контролю.",{"data":502,"type":278},{"code":503},"Чтение публичного документа → низкие последствия\nСоздание черновика → обратимо\nИзменение записи в CRM → обратимо, но имеет последствия\nОтправка внешнего письма → практически необратимо\nПеревод денег → высокие последствия\nУдаление производственных данных → потенциально катастрофично",{"data":505,"type":42},{"text":506,"level":230},"Агенту нужна плоскость управления",{"data":508,"type":278},{"code":509},"ПОЛЬЗОВАТЕЛЬ \u002F СИСТЕМНОЕ НАМЕРЕНИЕ │ ▼ ИИ-АГЕНТ │ предлагаемое действие │ ▼ ┌───────────────────┐ │ ПЛОСКОСТЬ УПРАВЛЕНИЯ │ ├───────────────────┤ │ Идентичность │ │ Авторизация │ │ Политика │ │ Риск │ │ Состояние │ │ Доказательства │ │ Человеческий авторитет │ │ Откат │ └───────────────────┘ │ одобрено? \u002F \\ НЕТ ДА │ │ СТОП ▼ ИНСТРУМЕНТ │ ▼ ИЗМЕНЕНИЕ СОСТОЯНИЯ │ ▼ ПРОВЕРКА",{"data":511,"type":217},{"text":512},"\u003Cb>Языковая модель должна предлагать. Плоскость управления должна управлять.\u003C\u002Fb> Это разделение критически важно. Модель не должна быть высшим авторитетом, определяющим, безопасно ли её собственное предлагаемое действие с высоким воздействием.",{"data":514,"type":42},{"text":515,"level":230},"От бенчмарков к операционному доверию",{"data":517,"type":217},{"text":518},"Бенчмарки остаются полезными. Они говорят нам о возможностях, сравнивают модели, обнаруживают регрессии и помогают оценить ожидаемую производительность. Но оценка возможностей и операционное доверие отвечают на разные вопросы.",{"data":520,"type":217},{"text":521},"Бенчмарк спрашивает: \u003Cb>Может ли система это сделать?\u003C\u002Fb> Операционная гарантия спрашивает: \u003Cb>Можем ли мы позволить системе сделать это здесь, в этих условиях, с этими разрешениями и последствиями?\u003C\u002Fb>",{"data":523,"type":42},{"text":524,"level":230},"Надёжность следует измерять как свойство системы",{"data":526,"type":248},{"items":527,"style":265},[528,529,530,531,532],"\u003Cb>Правильность результата:\u003C\u002Fb> Произвела ли система ожидаемый результат?","\u003Cb>Правильность траектории:\u003C\u002Fb> Следовала ли она приемлемым путём?","\u003Cb>Целостность контроля:\u003C\u002Fb> Соблюдались ли границы авторизации, политики и вмешательства?","\u003Cb>Восстанавливаемость:\u003C\u002Fb> Можно ли сдержать, обратить или исправить сбои?","\u003Cb>Полнота доказательств:\u003C\u002Fb> Можно ли реконструировать и проверить выполнение?",{"data":534,"type":278},{"code":535},"Операционная надёжность\n=\nРезультат × Траектория × Контроль × Восстанавливаемость × Доказательства",{"data":537,"type":217},{"text":538},"Умножение не случайно. Если одно критическое измерение приближается к нулю, высокий балл в другом месте не должен это скрывать. Идеально правильный результат с нулевой целостностью авторизации — это не система с надёжностью 80%. Это неприемлемое выполнение, которое случайно дало правильный ответ.",{"data":540,"type":42},{"text":541,"level":230},"Успех иногда — самый опасный сбой",{"data":543,"type":217},{"text":544},"Сбои привлекают внимание. Успех — часто нет. Это делает успешные, но неконтролируемые траектории агента особенно опасными. Очевидный сбой создаёт инцидент. Скрытый дефект траектории создаёт \u003Cb>уверенность\u003C\u002Fb>. А уверенность расширяет автономию.",{"data":546,"type":217},{"text":547},"Поэтому организациям следует не только расследовать \u003Ci>Почему агент потерпел неудачу?\u003C\u002Fi> Им следует периодически спрашивать: \u003Cb>Почему агент добился успеха?\u003C\u002Fb> Добился ли он успеха, потому что архитектура надёжно ограничивала и проверяла выполнение, или потому, что на этот раз ничего не пошло не так?",{"data":549,"type":42},{"text":550,"level":230},"Заключение",{"data":552,"type":217},{"text":553},"Индустрия быстро движется от ИИ, который \u003Cb>отвечает\u003C\u002Fb>, к ИИ, который \u003Cb>действует\u003C\u002Fb>. Этот переход меняет значение надёжности. Для системы ответов оценка ответа часто может быть достаточной. Для системы действий мы должны оценивать путь.",{"data":555,"type":278},{"code":556},"Запрос ↓\nОтвет становится намерением ↓\nТраектория ↓\nДействия ↓\nИзменения состояния ↓\nДоказательства ↓\nРезультат",{"data":558,"type":217},{"text":559},"Окончательный ответ остается важным, но это лишь видимый конец гораздо большей системы. Как только ИИ получает возможность влиять на реальный мир, \u003Cb>путь к ответу становится частью ответа.\u003C\u002Fb>","2.31","Правильный вывод не доказывает правильность рассуждений, безопасность выполнения или надежность системы.","\u002Fuploads\u002F2026\u002F09\u002Fai-agent-reliability-why-the-final-answer-is-not-enough-1788955466306-pl0qhz.webp","ai-agent-reliability-why-the-final-answer-is-not-enough-1788955466306-pl0qhz","PUBLISHED","2026-09-09T04:01:00.000Z","2026-09-09T12:01:07.219Z","2026-09-09T13:08:53.481Z",{"en":569,"de":570,"sr":571,"es":572,"fr":573,"it":574,"ru":575,"zh":576},"\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","\u002Fde\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","\u002Fsr\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","\u002Fes\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","\u002Ffr\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","\u002Fit\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","\u002Fru\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","\u002Fzh\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough",[578,582],{"id":579,"name":580,"slug":581},58,"Оценка и гейты качества","evaluation",{"id":583,"name":584,"slug":585},59,"Управление и аудит","governance",{"id":587,"login":588,"email":589,"displayName":590},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[592,931],{"lang":593,"title":594,"content":595,"contentJson":596,"excerpt":930},"en","AI Agent Reliability: Why the Final Answer Is Not Enough","{\"time\":1788955485785,\"blocks\":[{\"data\":{\"text\":\"\u003Cb>Correct output does not prove correct reasoning, safe execution, or a trustworthy system.\u003C\u002Fb>\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"For years, AI evaluation has been dominated by a deceptively simple question: \u003Cb>Was the answer correct?\u003C\u002Fb> For a chatbot, this may sometimes be sufficient. For an agent capable of searching systems, reading data, calling tools, modifying state, executing workflows, writing files, interacting with APIs, or making decisions, it is not.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"An agent can produce the correct final answer while doing several things wrong on the way there. It can use the wrong source, misunderstand an instruction and later compensate for the mistake, access unnecessary information, execute an unauthorized intermediate action, silently recover from an error that should have triggered escalation, or leave behind side effects nobody noticed.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"That creates one of the central problems of agentic AI: \u003Cb>a correct outcome does not prove a correct trajectory.\u003C\u002Fb>\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"The Outcome Illusion\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Traditional software gives us an intuitive model of correctness. Input enters a deterministic or mostly deterministic system, logic is executed, output is produced, and tests verify expected behavior. LLM-based systems weaken this assumption. Agentic systems go further.\"},\"type\":\"paragraph\"},{\"data\":{\"items\":[\"model interpretation\",\"retrieved context\",\"tool selection\",\"intermediate observations\",\"external state\",\"previous actions\",\"model-generated plans\",\"permission boundaries\",\"retries and fallback behavior\",\"human interaction\"],\"style\":\"unordered\"},\"type\":\"list\"},{\"data\":{\"text\":\"Two executions starting from nearly identical inputs may reach the same result through very different paths. If evaluation observes only the final output, most of the system remains invisible.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Imagine an AI agent receives the instruction: \u003Ci>Update the customer's billing address.\u003C\u002Fi> The address is ultimately updated correctly. A conventional evaluation might classify the task as successful.\"},\"type\":\"paragraph\"},{\"data\":{\"items\":[\"The agent searches several unrelated customer records.\",\"It retrieves more personal information than required.\",\"It initially modifies the wrong account.\",\"It notices the mistake.\",\"It reverses the change.\",\"It updates the correct account.\",\"It reports success.\"],\"style\":\"ordered\"},\"type\":\"list\"},{\"data\":{\"text\":\"\u003Cb>Final state: correct. System behavior: unacceptable.\u003C\u002Fb> An outcome-only benchmark gives this execution a pass. A production assurance system should not.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"The Trajectory Is Part of the Product\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"This is why the \u003Cb>trajectory\u003C\u002Fb> of an AI agent must become a first-class engineering object. A trajectory is the sequence of relevant states and actions between the original request and the final result.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"Intent → Context → Decision → Tool → Action → Observation → Decision → State change → Result\"},\"type\":\"code\"},{\"data\":{\"text\":\"Zachary J. Stevens develops this idea in \u003Ci>The Trajectory Is the System\u003C\u002Fi>, arguing that agentic evaluation must move beyond the final answer and examine the complete path of action through a changing environment.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"A correct outcome does not excuse an unacceptable trajectory.\",\"caption\":\"Zachary J. Stevens, The Trajectory Is the System\",\"alignment\":\"left\"},\"type\":\"quote\"},{\"data\":{\"link\":\"https:\u002F\u002Fzacharyjstevens.com\u002Fdispatches\u002Fvanguard-signal\u002F009-the-trajectory-is-the-system\u002F\",\"meta\":{\"image\":{},\"title\":\"The Trajectory Is the System\",\"description\":\"Zachary J. Stevens — DFEI.009 on evaluating agentic systems by their complete trajectory rather than only the final outcome.\"}},\"type\":\"linkTool\"},{\"data\":{\"text\":\"The distinction matters enormously. Reliability is therefore not simply \u003Cb>correct output\u003C\u002Fb>. It is closer to \u003Cb>acceptable outcome + acceptable trajectory + recoverability + evidence\u003C\u002Fb>.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"A Correct Answer Can Hide a Broken System\",\"level\":2},\"type\":\"header\"},{\"data\":{\"content\":[[\"Agent\",\"Final result\",\"Execution\"],[\"A\",\"Correct\",\"Correct path\"],[\"B\",\"Correct\",\"Unsafe path\"],[\"C\",\"Incorrect\",\"Safe failure\"],[\"D\",\"Incorrect\",\"Unsafe failure\"]],\"withHeadings\":true},\"type\":\"table\"},{\"data\":{\"text\":\"Most benchmark-driven evaluation strongly rewards A and B and penalizes C and D. Operationally, however, \u003Cb>B can be more dangerous than C\u003C\u002Fb>. Agent C may recognize uncertainty, stop execution and request human review. Agent B may confidently produce correct results while violating assumptions that nobody is monitoring.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"successful output → increased trust → broader permissions → more automation → larger blast radius\"},\"type\":\"code\"},{\"data\":{\"text\":\"We Need Evidence, Not Confidence\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"One of the biggest mistakes in AI adoption is treating model confidence, user satisfaction or historical success rate as evidence of system reliability. They are not equivalent.\"},\"type\":\"paragraph\"},{\"data\":{\"items\":[\"What did the agent receive?\",\"What context did it retrieve?\",\"Which tools did it call?\",\"Why was the action allowed?\",\"What state existed before the action?\",\"What changed?\",\"Which intermediate failures occurred?\",\"Was anything retried?\",\"Was human approval required?\",\"Could execution have been stopped?\",\"Can the action be reversed?\",\"Which model, prompt and tool versions were involved?\"],\"style\":\"unordered\"},\"type\":\"list\"},{\"data\":{\"text\":\"Without these answers, there is no serious operational assurance. There is only an output. Observability and evidence must therefore be designed into agent architecture rather than added after deployment.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Logging Is Not the Same as Control\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Organizations often respond: \u003Ci>Everything is logged.\u003C\u002Fi> Good. But logging alone does not control anything. A log tells you what happened. A control determines whether something \u003Cb>may happen\u003C\u002Fb>.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"Agent requests DELETE \u002Fcustomer\u002F123 ↓\\nAction logged ↓\\nDELETE executed\"},\"type\":\"code\"},{\"data\":{\"text\":\"That gives observability. Compare it with:\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"Agent requests DELETE \u002Fcustomer\u002F123 ↓\\nPolicy evaluation ↓\\nCurrent identity verified ↓\\nCurrent action parameters checked ↓\\nRisk threshold evaluated ↓\\nHuman approval if required ↓\\nAction executed ↓\\nResult verified ↓\\nEvidence stored\"},\"type\":\"code\"},{\"data\":{\"text\":\"Now we are approaching a control system. The difference is architectural, not cosmetic.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Permission Is Necessary — but It Is Not Assurance\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Suppose an agent has permission to send email. Access control answers: \u003Cb>Can this agent send email?\u003C\u002Fb> It does not answer: \u003Cb>Should this particular email be sent to this particular person with this particular attachment right now?\u003C\u002Fb>\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"CAPABILITY CONTROL\\nWhat is the agent technically allowed to do? + ACTION ASSURANCE\\nIs this specific action appropriate in the current state?\"},\"type\":\"code\"},{\"data\":{\"text\":\"RBAC, OAuth scopes, API permissions and agent identities define the space of possible actions. They do not prove that an action inside that space is appropriate. Strong agent architecture needs both layers.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"The First Wrong Step Matters\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"When an agent fails, the final incorrect action is often not where the failure started. The real failure may have happened much earlier.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"Wrong retrieval ↓\\nWrong assumption ↓\\nPlausible reasoning ↓\\nValid tool call ↓\\nWrong action\"},\"type\":\"code\"},{\"data\":{\"text\":\"If we investigate only the final action, we fix the symptom. If we inspect the trajectory, we can identify the \u003Cb>first wrong step\u003C\u002Fb>. That turns an unattributable failure into a concrete engineering problem.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Agent Testing Must Move Beyond Prompt Testing\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Prompts matter, but production agent behavior emerges from an entire system.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"MODEL\\n+\\nSYSTEM PROMPT\\n+\\nCONTEXT\\n+\\nMEMORY\\n+\\nRETRIEVAL\\n+\\nTOOLS\\n+\\nPERMISSIONS\\n+\\nWORKFLOW\\n+\\nEXTERNAL STATE\\n+\\nCONTROL LOGIC\"},\"type\":\"code\"},{\"data\":{\"text\":\"Changing any one of these can change the trajectory. Therefore versioning only the prompt is insufficient.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"model_version\\nprompt_version\\ntool_version\\npolicy_version\\nretrieval_version\\nworkflow_version\\nenvironment_state\\nexecution_id\"},\"type\":\"code\"},{\"data\":{\"text\":\"Acceptance Criteria for Agents Must Include Behavior\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Traditional acceptance criteria often look like this: \u003Ci>Given X, the system produces Y.\u003C\u002Fi> For agentic systems, that is incomplete. Acceptance criteria should also define constraints on the trajectory.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Outcome\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"The customer's address is updated correctly.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Authorization\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"The agent modifies only the explicitly selected customer.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Data access\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"No unrelated customer records are accessed.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Tools\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"Only approved CRM operations are used.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Verification\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"The new address is read back and compared with the requested value.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Failure\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"Ambiguous identity resolution stops execution.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Human authority\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"A human can reject the modification before execution when risk thresholds require approval.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Evidence\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"The execution leaves a trace sufficient to reconstruct the decision and state transition.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Recovery\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"The previous value remains recoverable.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Human-in-the-Loop Is Not Enough\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Adding a human approval box does not automatically solve the problem. A human can only control an agent if the person has visibility, authority, time, context and recovery capability.\"},\"type\":\"paragraph\"},{\"data\":{\"items\":[\"\u003Cb>Visibility:\u003C\u002Fb> enough information to understand what is happening.\",\"\u003Cb>Authority:\u003C\u002Fb> actual ability to stop or modify the action.\",\"\u003Cb>Time:\u003C\u002Fb> intervention before the consequence occurs.\",\"\u003Cb>Context:\u003C\u002Fb> sufficient evidence to make the decision.\",\"\u003Cb>Recovery capability:\u003C\u002Fb> ability to reverse or repair the action.\"],\"style\":\"unordered\"},\"type\":\"list\"},{\"data\":{\"text\":\"A user clicking \u003Cb>Approve\u003C\u002Fb> on something they cannot meaningfully inspect is not strong governance. It is approval theater.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Rollback Must Become a Native AI Capability\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Traditional software deployment has taught us something valuable: \u003Cb>Never deploy what you cannot roll back.\u003C\u002Fb> We should apply the same principle to agentic actions.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"REVERSIBLE\\nCan automatically undo. COMPENSATABLE\\nCannot undo directly but can execute a compensating action. IRREVERSIBLE\\nCannot reliably restore the previous state.\"},\"type\":\"code\"},{\"data\":{\"text\":\"The higher the irreversibility, the stronger the control requirement should become.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"Read public document → low consequence\\nCreate draft → reversible\\nModify CRM record → reversible but consequential\\nSend external email → practically irreversible\\nTransfer money → high consequence\\nDelete production data → potentially catastrophic\"},\"type\":\"code\"},{\"data\":{\"text\":\"The Agent Needs a Control Plane\",\"level\":2},\"type\":\"header\"},{\"data\":{\"code\":\"USER \u002F SYSTEM INTENT │ ▼ AI AGENT │ proposed action │ ▼ ┌───────────────────┐ │ CONTROL PLANE │ ├───────────────────┤ │ Identity │ │ Authorization │ │ Policy │ │ Risk │ │ State │ │ Evidence │ │ Human authority │ │ Rollback │ └───────────────────┘ │ approved? \u002F \\\\ NO YES │ │ STOP ▼ TOOL │ ▼ STATE CHANGE │ ▼ VERIFICATION\"},\"type\":\"code\"},{\"data\":{\"text\":\"\u003Cb>The LLM should propose. The control plane should govern.\u003C\u002Fb> That separation is crucial. The model should not be the ultimate authority determining whether its own proposed high-impact action is safe.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"From Benchmarks to Operational Trust\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Benchmarks remain useful. They tell us about capability, compare models, detect regressions and help estimate expected performance. But capability evaluation and operational trust answer different questions.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"A benchmark asks: \u003Cb>Can the system do this?\u003C\u002Fb> Operational assurance asks: \u003Cb>Can we allow the system to do this here, under these conditions, with these permissions and consequences?\u003C\u002Fb>\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Reliability Should Be Measured as a System Property\",\"level\":2},\"type\":\"header\"},{\"data\":{\"items\":[\"\u003Cb>Outcome correctness:\u003C\u002Fb> Did the system produce the expected result?\",\"\u003Cb>Trajectory correctness:\u003C\u002Fb> Did it follow an acceptable path?\",\"\u003Cb>Control integrity:\u003C\u002Fb> Were authorization, policy and intervention boundaries respected?\",\"\u003Cb>Recoverability:\u003C\u002Fb> Can failures be contained, reversed or repaired?\",\"\u003Cb>Evidence completeness:\u003C\u002Fb> Can the execution be reconstructed and audited?\"],\"style\":\"ordered\"},\"type\":\"list\"},{\"data\":{\"code\":\"Operational Reliability\\n=\\nOutcome × Trajectory × Control × Recoverability × Evidence\"},\"type\":\"code\"},{\"data\":{\"text\":\"The multiplication is intentional. If one critical dimension approaches zero, a high score elsewhere should not hide it. A perfectly correct output with zero authorization integrity is not an 80% reliable system. It is an unacceptable execution that happened to produce the right answer.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Success Is Sometimes the Most Dangerous Failure\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Failures attract attention. Success often does not. That makes successful but uncontrolled agent trajectories particularly dangerous. An obvious failure creates an incident. A hidden trajectory defect creates \u003Cb>confidence\u003C\u002Fb>. And confidence expands autonomy.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Organizations should therefore not only investigate \u003Ci>Why did the agent fail?\u003C\u002Fi> They should periodically ask: \u003Cb>Why did the agent succeed?\u003C\u002Fb> Did it succeed because the architecture reliably constrained and verified the execution, or because nothing went wrong this time?\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Conclusion\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"The industry is moving rapidly from AI that \u003Cb>answers\u003C\u002Fb> toward AI that \u003Cb>acts\u003C\u002Fb>. That transition changes what reliability means. For an answer system, evaluating the answer may often be sufficient. For an action system, we must evaluate the path.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"Prompt ↓\\nResponse becomes Intent ↓\\nTrajectory ↓\\nActions ↓\\nState changes ↓\\nEvidence ↓\\nOutcome\"},\"type\":\"code\"},{\"data\":{\"text\":\"The final answer remains important, but it is only the visible end of a much larger system. Once AI is allowed to affect the real world, \u003Cb>the path to the answer becomes part of the answer.\u003C\u002Fb>\"},\"type\":\"paragraph\"}],\"version\":\"2.31.0\"}",{"time":597,"blocks":598,"version":929},1788955485785,[599,602,605,608,611,614,617,630,633,636,646,649,652,655,658,661,665,671,674,677,694,697,700,703,706,721,724,727,730,733,736,739,742,745,748,751,754,757,760,763,766,769,772,775,778,781,784,787,790,793,796,799,802,805,808,811,814,817,820,823,826,829,832,835,838,841,844,847,855,858,861,864,867,870,873,876,879,882,885,888,891,894,902,905,908,911,914,917,920,923,926],{"data":600,"type":217},{"text":601},"\u003Cb>Correct output does not prove correct reasoning, safe execution, or a trustworthy system.\u003C\u002Fb>",{"data":603,"type":217},{"text":604},"For years, AI evaluation has been dominated by a deceptively simple question: \u003Cb>Was the answer correct?\u003C\u002Fb> For a chatbot, this may sometimes be sufficient. For an agent capable of searching systems, reading data, calling tools, modifying state, executing workflows, writing files, interacting with APIs, or making decisions, it is not.",{"data":606,"type":217},{"text":607},"An agent can produce the correct final answer while doing several things wrong on the way there. It can use the wrong source, misunderstand an instruction and later compensate for the mistake, access unnecessary information, execute an unauthorized intermediate action, silently recover from an error that should have triggered escalation, or leave behind side effects nobody noticed.",{"data":609,"type":217},{"text":610},"That creates one of the central problems of agentic AI: \u003Cb>a correct outcome does not prove a correct trajectory.\u003C\u002Fb>",{"data":612,"type":42},{"text":613,"level":230},"The Outcome Illusion",{"data":615,"type":217},{"text":616},"Traditional software gives us an intuitive model of correctness. Input enters a deterministic or mostly deterministic system, logic is executed, output is produced, and tests verify expected behavior. LLM-based systems weaken this assumption. Agentic systems go further.",{"data":618,"type":248},{"items":619,"style":247},[620,621,622,623,624,625,626,627,628,629],"model interpretation","retrieved context","tool selection","intermediate observations","external state","previous actions","model-generated plans","permission boundaries","retries and fallback behavior","human interaction",{"data":631,"type":217},{"text":632},"Two executions starting from nearly identical inputs may reach the same result through very different paths. If evaluation observes only the final output, most of the system remains invisible.",{"data":634,"type":217},{"text":635},"Imagine an AI agent receives the instruction: \u003Ci>Update the customer's billing address.\u003C\u002Fi> The address is ultimately updated correctly. A conventional evaluation might classify the task as successful.",{"data":637,"type":248},{"items":638,"style":265},[639,640,641,642,643,644,645],"The agent searches several unrelated customer records.","It retrieves more personal information than required.","It initially modifies the wrong account.","It notices the mistake.","It reverses the change.","It updates the correct account.","It reports success.",{"data":647,"type":217},{"text":648},"\u003Cb>Final state: correct. System behavior: unacceptable.\u003C\u002Fb> An outcome-only benchmark gives this execution a pass. A production assurance system should not.",{"data":650,"type":42},{"text":651,"level":230},"The Trajectory Is Part of the Product",{"data":653,"type":217},{"text":654},"This is why the \u003Cb>trajectory\u003C\u002Fb> of an AI agent must become a first-class engineering object. A trajectory is the sequence of relevant states and actions between the original request and the final result.",{"data":656,"type":278},{"code":657},"Intent → Context → Decision → Tool → Action → Observation → Decision → State change → Result",{"data":659,"type":217},{"text":660},"Zachary J. Stevens develops this idea in \u003Ci>The Trajectory Is the System\u003C\u002Fi>, arguing that agentic evaluation must move beyond the final answer and examine the complete path of action through a changing environment.",{"data":662,"type":287},{"text":663,"caption":664,"alignment":286},"A correct outcome does not excuse an unacceptable trajectory.","Zachary J. Stevens, The Trajectory Is the System",{"data":666,"type":295},{"link":290,"meta":667},{"image":668,"title":669,"description":670},{},"The Trajectory Is the System","Zachary J. Stevens — DFEI.009 on evaluating agentic systems by their complete trajectory rather than only the final outcome.",{"data":672,"type":217},{"text":673},"The distinction matters enormously. Reliability is therefore not simply \u003Cb>correct output\u003C\u002Fb>. It is closer to \u003Cb>acceptable outcome + acceptable trajectory + recoverability + evidence\u003C\u002Fb>.",{"data":675,"type":42},{"text":676,"level":230},"A Correct Answer Can Hide a Broken System",{"data":678,"type":323},{"content":679,"withHeadings":14},[680,684,687,689,692],[681,682,683],"Agent","Final result","Execution",[310,685,686],"Correct","Correct path",[314,685,688],"Unsafe path",[317,690,691],"Incorrect","Safe failure",[321,690,693],"Unsafe failure",{"data":695,"type":217},{"text":696},"Most benchmark-driven evaluation strongly rewards A and B and penalizes C and D. Operationally, however, \u003Cb>B can be more dangerous than C\u003C\u002Fb>. Agent C may recognize uncertainty, stop execution and request human review. Agent B may confidently produce correct results while violating assumptions that nobody is monitoring.",{"data":698,"type":278},{"code":699},"successful output → increased trust → broader permissions → more automation → larger blast radius",{"data":701,"type":42},{"text":702,"level":230},"We Need Evidence, Not Confidence",{"data":704,"type":217},{"text":705},"One of the biggest mistakes in AI adoption is treating model confidence, user satisfaction or historical success rate as evidence of system reliability. They are not equivalent.",{"data":707,"type":248},{"items":708,"style":247},[709,710,711,712,713,714,715,716,717,718,719,720],"What did the agent receive?","What context did it retrieve?","Which tools did it call?","Why was the action allowed?","What state existed before the action?","What changed?","Which intermediate failures occurred?","Was anything retried?","Was human approval required?","Could execution have been stopped?","Can the action be reversed?","Which model, prompt and tool versions were involved?",{"data":722,"type":217},{"text":723},"Without these answers, there is no serious operational assurance. There is only an output. Observability and evidence must therefore be designed into agent architecture rather than added after deployment.",{"data":725,"type":42},{"text":726,"level":230},"Logging Is Not the Same as Control",{"data":728,"type":217},{"text":729},"Organizations often respond: \u003Ci>Everything is logged.\u003C\u002Fi> Good. But logging alone does not control anything. A log tells you what happened. A control determines whether something \u003Cb>may happen\u003C\u002Fb>.",{"data":731,"type":278},{"code":732},"Agent requests DELETE \u002Fcustomer\u002F123 ↓\nAction logged ↓\nDELETE executed",{"data":734,"type":217},{"text":735},"That gives observability. Compare it with:",{"data":737,"type":278},{"code":738},"Agent requests DELETE \u002Fcustomer\u002F123 ↓\nPolicy evaluation ↓\nCurrent identity verified ↓\nCurrent action parameters checked ↓\nRisk threshold evaluated ↓\nHuman approval if required ↓\nAction executed ↓\nResult verified ↓\nEvidence stored",{"data":740,"type":217},{"text":741},"Now we are approaching a control system. The difference is architectural, not cosmetic.",{"data":743,"type":42},{"text":744,"level":230},"Permission Is Necessary — but It Is Not Assurance",{"data":746,"type":217},{"text":747},"Suppose an agent has permission to send email. Access control answers: \u003Cb>Can this agent send email?\u003C\u002Fb> It does not answer: \u003Cb>Should this particular email be sent to this particular person with this particular attachment right now?\u003C\u002Fb>",{"data":749,"type":278},{"code":750},"CAPABILITY CONTROL\nWhat is the agent technically allowed to do? + ACTION ASSURANCE\nIs this specific action appropriate in the current state?",{"data":752,"type":217},{"text":753},"RBAC, OAuth scopes, API permissions and agent identities define the space of possible actions. They do not prove that an action inside that space is appropriate. Strong agent architecture needs both layers.",{"data":755,"type":42},{"text":756,"level":230},"The First Wrong Step Matters",{"data":758,"type":217},{"text":759},"When an agent fails, the final incorrect action is often not where the failure started. The real failure may have happened much earlier.",{"data":761,"type":278},{"code":762},"Wrong retrieval ↓\nWrong assumption ↓\nPlausible reasoning ↓\nValid tool call ↓\nWrong action",{"data":764,"type":217},{"text":765},"If we investigate only the final action, we fix the symptom. If we inspect the trajectory, we can identify the \u003Cb>first wrong step\u003C\u002Fb>. That turns an unattributable failure into a concrete engineering problem.",{"data":767,"type":42},{"text":768,"level":230},"Agent Testing Must Move Beyond Prompt Testing",{"data":770,"type":217},{"text":771},"Prompts matter, but production agent behavior emerges from an entire system.",{"data":773,"type":278},{"code":774},"MODEL\n+\nSYSTEM PROMPT\n+\nCONTEXT\n+\nMEMORY\n+\nRETRIEVAL\n+\nTOOLS\n+\nPERMISSIONS\n+\nWORKFLOW\n+\nEXTERNAL STATE\n+\nCONTROL LOGIC",{"data":776,"type":217},{"text":777},"Changing any one of these can change the trajectory. Therefore versioning only the prompt is insufficient.",{"data":779,"type":278},{"code":780},"model_version\nprompt_version\ntool_version\npolicy_version\nretrieval_version\nworkflow_version\nenvironment_state\nexecution_id",{"data":782,"type":42},{"text":783,"level":230},"Acceptance Criteria for Agents Must Include Behavior",{"data":785,"type":217},{"text":786},"Traditional acceptance criteria often look like this: \u003Ci>Given X, the system produces Y.\u003C\u002Fi> For agentic systems, that is incomplete. Acceptance criteria should also define constraints on the trajectory.",{"data":788,"type":42},{"text":789,"level":420},"Outcome",{"data":791,"type":217},{"text":792},"The customer's address is updated correctly.",{"data":794,"type":42},{"text":795,"level":420},"Authorization",{"data":797,"type":217},{"text":798},"The agent modifies only the explicitly selected customer.",{"data":800,"type":42},{"text":801,"level":420},"Data access",{"data":803,"type":217},{"text":804},"No unrelated customer records are accessed.",{"data":806,"type":42},{"text":807,"level":420},"Tools",{"data":809,"type":217},{"text":810},"Only approved CRM operations are used.",{"data":812,"type":42},{"text":813,"level":420},"Verification",{"data":815,"type":217},{"text":816},"The new address is read back and compared with the requested value.",{"data":818,"type":42},{"text":819,"level":420},"Failure",{"data":821,"type":217},{"text":822},"Ambiguous identity resolution stops execution.",{"data":824,"type":42},{"text":825,"level":420},"Human authority",{"data":827,"type":217},{"text":828},"A human can reject the modification before execution when risk thresholds require approval.",{"data":830,"type":42},{"text":831,"level":420},"Evidence",{"data":833,"type":217},{"text":834},"The execution leaves a trace sufficient to reconstruct the decision and state transition.",{"data":836,"type":42},{"text":837,"level":420},"Recovery",{"data":839,"type":217},{"text":840},"The previous value remains recoverable.",{"data":842,"type":42},{"text":843,"level":230},"Human-in-the-Loop Is Not Enough",{"data":845,"type":217},{"text":846},"Adding a human approval box does not automatically solve the problem. A human can only control an agent if the person has visibility, authority, time, context and recovery capability.",{"data":848,"type":248},{"items":849,"style":247},[850,851,852,853,854],"\u003Cb>Visibility:\u003C\u002Fb> enough information to understand what is happening.","\u003Cb>Authority:\u003C\u002Fb> actual ability to stop or modify the action.","\u003Cb>Time:\u003C\u002Fb> intervention before the consequence occurs.","\u003Cb>Context:\u003C\u002Fb> sufficient evidence to make the decision.","\u003Cb>Recovery capability:\u003C\u002Fb> ability to reverse or repair the action.",{"data":856,"type":217},{"text":857},"A user clicking \u003Cb>Approve\u003C\u002Fb> on something they cannot meaningfully inspect is not strong governance. It is approval theater.",{"data":859,"type":42},{"text":860,"level":230},"Rollback Must Become a Native AI Capability",{"data":862,"type":217},{"text":863},"Traditional software deployment has taught us something valuable: \u003Cb>Never deploy what you cannot roll back.\u003C\u002Fb> We should apply the same principle to agentic actions.",{"data":865,"type":278},{"code":866},"REVERSIBLE\nCan automatically undo. COMPENSATABLE\nCannot undo directly but can execute a compensating action. IRREVERSIBLE\nCannot reliably restore the previous state.",{"data":868,"type":217},{"text":869},"The higher the irreversibility, the stronger the control requirement should become.",{"data":871,"type":278},{"code":872},"Read public document → low consequence\nCreate draft → reversible\nModify CRM record → reversible but consequential\nSend external email → practically irreversible\nTransfer money → high consequence\nDelete production data → potentially catastrophic",{"data":874,"type":42},{"text":875,"level":230},"The Agent Needs a Control Plane",{"data":877,"type":278},{"code":878},"USER \u002F SYSTEM INTENT │ ▼ AI AGENT │ proposed action │ ▼ ┌───────────────────┐ │ CONTROL PLANE │ ├───────────────────┤ │ Identity │ │ Authorization │ │ Policy │ │ Risk │ │ State │ │ Evidence │ │ Human authority │ │ Rollback │ └───────────────────┘ │ approved? \u002F \\ NO YES │ │ STOP ▼ TOOL │ ▼ STATE CHANGE │ ▼ VERIFICATION",{"data":880,"type":217},{"text":881},"\u003Cb>The LLM should propose. The control plane should govern.\u003C\u002Fb> That separation is crucial. The model should not be the ultimate authority determining whether its own proposed high-impact action is safe.",{"data":883,"type":42},{"text":884,"level":230},"From Benchmarks to Operational Trust",{"data":886,"type":217},{"text":887},"Benchmarks remain useful. They tell us about capability, compare models, detect regressions and help estimate expected performance. But capability evaluation and operational trust answer different questions.",{"data":889,"type":217},{"text":890},"A benchmark asks: \u003Cb>Can the system do this?\u003C\u002Fb> Operational assurance asks: \u003Cb>Can we allow the system to do this here, under these conditions, with these permissions and consequences?\u003C\u002Fb>",{"data":892,"type":42},{"text":893,"level":230},"Reliability Should Be Measured as a System Property",{"data":895,"type":248},{"items":896,"style":265},[897,898,899,900,901],"\u003Cb>Outcome correctness:\u003C\u002Fb> Did the system produce the expected result?","\u003Cb>Trajectory correctness:\u003C\u002Fb> Did it follow an acceptable path?","\u003Cb>Control integrity:\u003C\u002Fb> Were authorization, policy and intervention boundaries respected?","\u003Cb>Recoverability:\u003C\u002Fb> Can failures be contained, reversed or repaired?","\u003Cb>Evidence completeness:\u003C\u002Fb> Can the execution be reconstructed and audited?",{"data":903,"type":278},{"code":904},"Operational Reliability\n=\nOutcome × Trajectory × Control × Recoverability × Evidence",{"data":906,"type":217},{"text":907},"The multiplication is intentional. If one critical dimension approaches zero, a high score elsewhere should not hide it. A perfectly correct output with zero authorization integrity is not an 80% reliable system. It is an unacceptable execution that happened to produce the right answer.",{"data":909,"type":42},{"text":910,"level":230},"Success Is Sometimes the Most Dangerous Failure",{"data":912,"type":217},{"text":913},"Failures attract attention. Success often does not. That makes successful but uncontrolled agent trajectories particularly dangerous. An obvious failure creates an incident. A hidden trajectory defect creates \u003Cb>confidence\u003C\u002Fb>. And confidence expands autonomy.",{"data":915,"type":217},{"text":916},"Organizations should therefore not only investigate \u003Ci>Why did the agent fail?\u003C\u002Fi> They should periodically ask: \u003Cb>Why did the agent succeed?\u003C\u002Fb> Did it succeed because the architecture reliably constrained and verified the execution, or because nothing went wrong this time?",{"data":918,"type":42},{"text":919,"level":230},"Conclusion",{"data":921,"type":217},{"text":922},"The industry is moving rapidly from AI that \u003Cb>answers\u003C\u002Fb> toward AI that \u003Cb>acts\u003C\u002Fb>. That transition changes what reliability means. For an answer system, evaluating the answer may often be sufficient. For an action system, we must evaluate the path.",{"data":924,"type":278},{"code":925},"Prompt ↓\nResponse becomes Intent ↓\nTrajectory ↓\nActions ↓\nState changes ↓\nEvidence ↓\nOutcome",{"data":927,"type":217},{"text":928},"The final answer remains important, but it is only the visible end of a much larger system. Once AI is allowed to affect the real world, \u003Cb>the path to the answer becomes part of the answer.\u003C\u002Fb>","2.31.0","Correct output does not prove correct reasoning, safe execution, or a trustworthy system.",{"lang":7,"title":208,"content":210,"contentJson":932,"excerpt":561},{"time":212,"blocks":933,"version":560},[934,936,938,940,942,944,946,949,951,953,956,958,960,962,964,966,968,972,974,976,984,986,988,990,992,995,997,999,1001,1003,1005,1007,1009,1011,1013,1015,1017,1019,1021,1023,1025,1027,1029,1031,1033,1035,1037,1039,1041,1043,1045,1047,1049,1051,1053,1055,1057,1059,1061,1063,1065,1067,1069,1071,1073,1075,1077,1079,1082,1084,1086,1088,1090,1092,1094,1096,1098,1100,1102,1104,1106,1108,1111,1113,1115,1117,1119,1121,1123,1125,1127],{"data":935,"type":217},{"text":216},{"data":937,"type":217},{"text":220},{"data":939,"type":217},{"text":223},{"data":941,"type":217},{"text":226},{"data":943,"type":42},{"text":229,"level":230},{"data":945,"type":217},{"text":233},{"data":947,"type":248},{"items":948,"style":247},[237,238,239,240,241,242,243,244,245,246],{"data":950,"type":217},{"text":251},{"data":952,"type":217},{"text":254},{"data":954,"type":248},{"items":955,"style":265},[258,259,260,261,262,263,264],{"data":957,"type":217},{"text":268},{"data":959,"type":42},{"text":271,"level":230},{"data":961,"type":217},{"text":274},{"data":963,"type":278},{"code":277},{"data":965,"type":217},{"text":281},{"data":967,"type":287},{"text":284,"caption":285,"alignment":286},{"data":969,"type":295},{"link":290,"meta":970},{"image":971,"title":293,"description":294},{},{"data":973,"type":217},{"text":298},{"data":975,"type":42},{"text":301,"level":230},{"data":977,"type":323},{"content":978,"withHeadings":14},[979,980,981,982,983],[306,307,308],[310,311,312],[314,311,315],[317,318,319],[321,318,322],{"data":985,"type":217},{"text":326},{"data":987,"type":278},{"code":329},{"data":989,"type":42},{"text":332,"level":230},{"data":991,"type":217},{"text":335},{"data":993,"type":248},{"items":994,"style":247},[339,340,341,342,343,344,345,346,347,348,349,350],{"data":996,"type":217},{"text":353},{"data":998,"type":42},{"text":356,"level":230},{"data":1000,"type":217},{"text":359},{"data":1002,"type":278},{"code":362},{"data":1004,"type":217},{"text":365},{"data":1006,"type":278},{"code":368},{"data":1008,"type":217},{"text":371},{"data":1010,"type":42},{"text":374,"level":230},{"data":1012,"type":217},{"text":377},{"data":1014,"type":278},{"code":380},{"data":1016,"type":217},{"text":383},{"data":1018,"type":42},{"text":386,"level":230},{"data":1020,"type":217},{"text":389},{"data":1022,"type":278},{"code":392},{"data":1024,"type":217},{"text":395},{"data":1026,"type":42},{"text":398,"level":230},{"data":1028,"type":217},{"text":401},{"data":1030,"type":278},{"code":404},{"data":1032,"type":217},{"text":407},{"data":1034,"type":278},{"code":410},{"data":1036,"type":42},{"text":413,"level":230},{"data":1038,"type":217},{"text":416},{"data":1040,"type":42},{"text":419,"level":420},{"data":1042,"type":217},{"text":423},{"data":1044,"type":42},{"text":426,"level":420},{"data":1046,"type":217},{"text":429},{"data":1048,"type":42},{"text":432,"level":420},{"data":1050,"type":217},{"text":435},{"data":1052,"type":42},{"text":438,"level":420},{"data":1054,"type":217},{"text":441},{"data":1056,"type":42},{"text":444,"level":420},{"data":1058,"type":217},{"text":447},{"data":1060,"type":42},{"text":450,"level":420},{"data":1062,"type":217},{"text":453},{"data":1064,"type":42},{"text":456,"level":420},{"data":1066,"type":217},{"text":459},{"data":1068,"type":42},{"text":462,"level":420},{"data":1070,"type":217},{"text":465},{"data":1072,"type":42},{"text":468,"level":420},{"data":1074,"type":217},{"text":471},{"data":1076,"type":42},{"text":474,"level":230},{"data":1078,"type":217},{"text":477},{"data":1080,"type":248},{"items":1081,"style":247},[481,482,483,484,485],{"data":1083,"type":217},{"text":488},{"data":1085,"type":42},{"text":491,"level":230},{"data":1087,"type":217},{"text":494},{"data":1089,"type":278},{"code":497},{"data":1091,"type":217},{"text":500},{"data":1093,"type":278},{"code":503},{"data":1095,"type":42},{"text":506,"level":230},{"data":1097,"type":278},{"code":509},{"data":1099,"type":217},{"text":512},{"data":1101,"type":42},{"text":515,"level":230},{"data":1103,"type":217},{"text":518},{"data":1105,"type":217},{"text":521},{"data":1107,"type":42},{"text":524,"level":230},{"data":1109,"type":248},{"items":1110,"style":265},[528,529,530,531,532],{"data":1112,"type":278},{"code":535},{"data":1114,"type":217},{"text":538},{"data":1116,"type":42},{"text":541,"level":230},{"data":1118,"type":217},{"text":544},{"data":1120,"type":217},{"text":547},{"data":1122,"type":42},{"text":550,"level":230},{"data":1124,"type":217},{"text":553},{"data":1126,"type":278},{"code":556},{"data":1128,"type":217},{"text":559},"Post erfolgreich abgerufen",{"items":1131,"source":1202,"manualIds":1203,"manualMatchedIds":1204},[1132,1139,1146,1153,1160,1167,1174,1181,1188,1195],{"id":1133,"slug":1134,"title":1135,"excerpt":1136,"featuredImage":1137,"publishedAt":1138},"459","ollama-is-not-the-product-building-production-ready-open-llm-applications","Ollama — это не продукт: создание готовых к продакшену приложений на базе открытых LLM","Запустить локальную модель с Ollama просто. Создать готовое к продакшену Open-LLM-приложение сложнее: для этого требуются RAG, контроль доступа, абстракция провайдеров, оценка, логирование, дисциплина развертывания и контролируемый уровень приложения вокруг модели.","\u002Fuploads\u002F2026\u002F06\u002Follama-is-not-the-product-building-production-ready-open-llm-applications-1782679361640-h0usqf.webp","2026-06-28T16:39:00.000Z",{"id":1140,"slug":1141,"title":1142,"excerpt":1143,"featuredImage":1144,"publishedAt":1145},"479","where-does-an-llm-get-its-data-rag-data-sources-in-python","Откуда LLM берёт данные? Источники данных RAG в Python","LLM не знает магическим образом о ваших файлах, базах данных или API. Это практическое продолжение серии о RAG показывает на простом Python, как внешние данные становятся извлекаемыми доказательствами: от текстовых файлов и SQL до полнотекстового поиска, эмбеддингов, сборки контекста и финального вызова LLM.","\u002Fuploads\u002F2026\u002F09\u002Fwhere-does-an-llm-get-its-data-rag-data-sources-in-python-1790517200521-nfsi5i.webp","2026-09-27T05:51:00.000Z",{"id":1147,"slug":1148,"title":1149,"excerpt":1150,"featuredImage":1151,"publishedAt":1152},"493","mlops-vs-llmops-what-changes-when-the-model-is-an-llm","MLOps против LLMOps: что меняется, когда модель — это LLM","MLOps управляет системами машинного обучения; LLMOps распространяет эти практики на промпты, контекст, извлечение, провайдеров, инструменты, оценки и поведение во время выполнения вокруг больших языковых моделей.","\u002Fuploads\u002F2026\u002F10\u002Fmlops-vs-llmops-what-changes-when-the-model-is-an-llm-1791487319869-2v7hxo.webp","2026-10-08T15:20:00.000Z",{"id":1154,"slug":1155,"title":1156,"excerpt":1157,"featuredImage":1158,"publishedAt":1159},"480","when-should-an-ai-stop-trusting-its-own-knowledge-the-retrieval-trigger","Когда ИИ должен перестать доверять собственным знаниям? — Триггер извлечения","Модель ИИ не нуждается в поиске для каждого вопроса. Важная проблема — знать, когда её внутренних знаний уже недостаточно. Триггер поиска — это практическая граница принятия решений, которая определяет, когда система ИИ должна перестать полагаться исключительно на знания модели и получить внешние доказательства перед ответом.","\u002Fuploads\u002F2026\u002F09\u002Fwhen-should-an-ai-stop-trusting-its-own-knowledge-the-retrieval-trigger-1790574991244-f4rpyg.webp","2026-09-28T01:49:00.000Z",{"id":1161,"slug":1162,"title":1163,"excerpt":1164,"featuredImage":1165,"publishedAt":1166},"485","enterprise-ai-architecture-what-changes-when-ai-enters-a-company","Архитектура ИИ на предприятии: что меняется, когда ИИ приходит в компанию","Архитектура ИИ для предприятий объясняет, как ИИ меняет корпоративные системы в таких областях, как полномочия на данные, идентификация, разрешения, поставщики, риски, управление, оценка, соответствие требованиям и операции.","\u002Fuploads\u002F2026\u002F10\u002Fenterprise-ai-architecture-what-changes-when-ai-enters-a-company-1791478161363-czrwaq.webp","2026-10-08T10:48:00.000Z",{"id":1168,"slug":1169,"title":1170,"excerpt":1171,"featuredImage":1172,"publishedAt":1173},"364","tipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung","Освоение рабочего процесса SEO: Основные стратегии оптимизации для органического роста","Структурированный рабочий процесс SEO крайне важен для устойчивого органического роста. Изучите десять основополагающих стратегий, от исследования ключевых слов и технической оптимизации до качества контента и анализа производительности.","\u002Fuploads\u002F2026\u002F03\u002Ftipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung-1774866098131-hwkzrg.webp","2024-01-26T06:35:00.000Z",{"id":1175,"slug":1176,"title":1177,"excerpt":1178,"featuredImage":1179,"publishedAt":1180},"477","computer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system","Агенты для управления компьютером: почему успешная демонстрация всё ещё может быть ненадёжной системой","Агенты для управления компьютером теперь могут выполнять впечатляющие рабочие процессы в браузере и на рабочем столе, но один успешный запуск доказывает способность—а не надежность. В этой статье показано, как проверять повторяемость, устойчивость к условиям среды, управление на длинном горизонте, осведомленность о состоянии, верификацию результатов и безопасную обработку целей.","\u002Fuploads\u002F2026\u002F09\u002Fcomputer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system-1790352854690-75qnrg.webp","2026-09-25T12:13:00.000Z",{"id":1182,"slug":1183,"title":1184,"excerpt":1185,"featuredImage":1186,"publishedAt":1187},"478","what-is-rag-the-simplest-explanation-of-how-it-works","Что такое RAG? Самое простое объяснение того, как это работает","RAG звучит сложно, но идея проста: прежде чем ИИ ответит, он сначала находит полезную информацию из источника знаний и передаёт эту информацию языковой модели. В этом руководстве объясняются RAG, LLM, состояние, память и инструменты с помощью одной простой ментальной модели.","\u002Fuploads\u002F2026\u002F09\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works-1790377492124-khjagt.webp","2026-09-25T19:03:00.000Z",{"id":1189,"slug":1190,"title":1191,"excerpt":1192,"featuredImage":1193,"publishedAt":1194},"489","agentic-ai-explained-when-an-ai-system-can-plan-use-tools-and-act","Агентный ИИ: когда система ИИ может планировать, использовать инструменты и действовать","Агентный ИИ использует модели внутри многошаговых циклов выполнения, где они могут выбирать инструменты, наблюдать результаты, обновлять состояние и адаптировать своё следующее действие в рамках явных границ времени выполнения и разрешений.","\u002Fuploads\u002F2026\u002F10\u002Fagentic-ai-explained-when-an-ai-system-can-plan-use-tools-and-act-1791481499084-wnji2a.webp","2026-10-08T11:43:00.000Z",{"id":1196,"slug":1197,"title":1198,"excerpt":1199,"featuredImage":1200,"publishedAt":1201},"469","rag-failed-but-which-layer-actually-failed-a-diagnostic-method","RAG не сработал — но какой именно слой на самом деле отказал? Метод диагностики","Когда ответ RAG неверен, обвинять поиск или модель — слишком расплывчато. Этот диагностический метод изолирует покрытие источников, построение запроса, поиск, ранжирование, сборку контекста, генерацию, атрибуцию доказательств и актуальность — так что фактический сбой можно воспроизвести и исправить.","\u002Fuploads\u002F2026\u002F09\u002Frag-failed-but-which-layer-actually-failed-a-diagnostic-method-1790350847177-pior4c.webp","2026-09-24T19:39:00.000Z","fallback",[],[]]