LLM агенты всё ещё не подходят для реальных задач

На этой неделе протестил LLM на реальных задачах из своего программирования. Опять.

Далее

Хотите крутой open source проект себе в портфолио?

Как промежуточный итог моих мытарств с OAuth2/OIDC могу сказать, что столько текущих абстракций и частичных реализаций, как в современных open source аутентификационных прокси, я не встречал, как-минимум, давно. Может быть даже никогда не встречал.

И вот, конечно, хорошо, что они хотя бы есть и есть из чего выбрать. И ясно, что их делали энтерпрайзные разработчики для закрытия своих очень специфических энтерпрайзных болей, скорее всего, как параллельные проекты к основным продуктам. Но, всё-таки, её-моё…

Если вы вдруг хотите получить крутой open source проект в портфолио, то берите Rust или Go, пилите с нуля небольшой auth proxy с поддержкой OIDC и OAuth2, который тупо работает. Чтобы он был ориентирован не на корпорации с кубернетисами, а на небольшие компании и инди-разработчиков, которым нужно быстро закрыть пробел в фунцкиональности не изменяя код своих приложений. Ситуация когда вы правите код бэкенда, чтобы прокси заработал, — это дичь какая-то.

Вам в ноги кланяться будут :-) тем более, что сейчас OAuth2 резко всем стал нужен ещё больше, так как требуется в Model Context Protocol.

Далее

Стрёмная архитектура аутентификации Ory

Пожалуюсь вам, так как либо сюда писать, либо в спортлото.

Я тут погружаюсь в тему аутентификации чуть глубже, чем мне хотелось бы, и столкнулся с тем, что сейчас чуть ли не best-practice это со своего auth проксика делать запросы в сторонние сервисы, чтобы наполнить запрос дополнительной инфой для бэкенда.

Например, если есть API, которое доступно одновременно для аутентифицированных и анонимных пользователей, то Ory Oathkeeper (auth proxy) не может добавить заголовок с id пользователя: либо надо закрыть api от анонимных пользователей либо не добавлять заголовок.

Решать советуют через создание своего микросервиса (!): проксик обращется к микросервису (на каждый запрос!) микросервис обращается к Ory Kratos (!) — это хранилка сессий (среди прочего), получает сессию и возвращает инфу для проксика. Т.е. чтобы добавить 1 заголовок, надо делать цепочку из двух запросов по инфре на каждый запрос к api. (или из трёх, в теории Kratos может в базу или кэш сходить).

Это нонсенс какой-то.

Далее

Reasoning LLMs are Wandering Solution Explorers

На arXiv появилась интересная статья в пользу того, что современные Reasoning LLM занимаются скорее «случайным блужданием в пространстве решений», чем «систематическим поиском решений».

Основной текст статьи — около 10 страниц довольно простого текста, рекомендую почитать.

Что сделали авторы:

1. Формализовали понятия «систематического исследования пространства решений» и «случайного блуждания в пространстве решений».
2. Построили очень простую и показательную модель как эти штуки работают.
3. На основе этой модели показали, что случайное блуждание можно легко перепутать с систематическим исследованием, если у вас много вычислительных мощностей.
4. Также показали, что эффективность случайного блуждания очень быстро деградирует, если сложность задачи выходит за рамки доступных ресурсов.
5. Формализовали проблемы из реального мира в строго определённые задачи со структурированной областью решений.
6. Протестировали на этих задачах современные LLM и показали, что их поведение скорее напоминает случайное блуждание.

Я скорее согласен с идеей авторов, но не могу утверждать, что статья безупречна. Есть вероятность, что LLM они используют не совсем корректно и задачи формализованы неудобным для них образом.

Однако основная ценность статьи не в финальных выводах, а в отличной формализации процесса поиска решений, концепциях «случайного блуждания» и «систематического поиска», и особенно в упрощённой модели их поведения.

Если вам интересен вопрос «мыслит ли LLM» (и шире — методики поиска решений), рекомендую изучить подход этой статьи, как перспективный угол атаки на проблему.

Взгляд на управление: Инженерия — это наука — это инженерия

В предыдущем посте мы обсудили, что инженерия — это творческая деятельность, которая не сводится к исполнению инструкций. Поэтому для управления инженерными коллективами необходимо использовать практики, созданные для творческих коллективов.

А что может быть более творческим, чем вокально-инструментальный ансамбль наука?

Поэтому в этом посте я попытаюсь показать, что инженерия концептуально значительно ближе к науке, чем может показаться на первый взгляд. А также, что в современном мире эти дисциплины всё больше сближаются. Я бы даже поставил на то, что граница между ними сотрётся.

Далее