Искусственный интеллект

Недавно в нашу компанию ASRP обратился клиент, который за годы работы на немецком рынке разработал обширный набор внутренних инструментов — от библиотек для обработки PDF, изображений и данных до систем автоматизации и анализа. Сейчас его команда активно внедряет агентные технологии и стремится сделать эти инструменты доступными для агентов — чтобы те могли использовать их как модули, комбинировать между собой и самостоятельно строить новые цепочки действий без участия разработчиков.

Для оперативного старта клиент создал один большой монорепозиторий, в котором разместил и агентов, и инструменты. Такой подход позволял быстро развернуть среду, где агенты могли общаться между собой локально и использовать нужные тулзы прямо из соседних папок. При создании нового агента клиент просто копировал нужные инструменты в его директорию, адаптируя конфигурацию под задачу. Для партнёров компания устанавливала этот софт локально, но в планах была масштабная SaaS-платформа с кастомным интерфейсом и централизованным управлением агентами.

Со временем стало ясно, что такой подход не масштабируется.

Несмотря на растущую популярность платформы Langfuse для отладки и контроля LLM ориентированных приложений, на момент написания статьи экосистема .NET остается без официальной поддержки. На момент написания статьи готовые SDK доступны только разработчикам на Python и JavaScript/TypeScript. Однако есть возможность интеграции с помощью стандарта OpenTelemetry. И в данной статье будет приведен один из примеров как это сделать.

Когда агентов на базе LLM используют в реальных задачах, то ожидания сталкиваются с реальностью: вроде бы используется умная модель, но всё равно она путается в инструментах и не может довести простую задачу до конца.

Недавний бенчмарк показал интересную картину: оказывается, дело не только в размере модели или количестве параметров. Когда агенту приходится выбирать один инструмент из тысяч возможных, то даже самые умные агенты пасуют. Особенно если это приходится делать на лету.

Почему так происходит и что на самом деле мешает моделям успешно выполнять задачи в запутанных корпоративных сценариях? Разбираемся, как агенты учатся выбирать правильные инструменты и почему это станет ключевым навыком для будущих ИИ-систем.

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

Добро пожаловать в странный мир биовычислений. Среди лидеров в этой области — группа учёных из Швейцарии, с которыми я встретилась. Они надеются, что однажды мы увидим центры обработки данных, заполненные «живыми» серверами, которые будут копировать аспекты обучения искусственного интеллекта (ИИ) и потреблять лишь небольшую часть энергии, по сравнению с существующими сегодня.

Такова концепция доктора Фреда Джордана, соучредителя лаборатории FinalSpark, которую я посетила. Мы все привыкли к понятиям «аппаратное обеспечение» и «программное обеспечение» в компьютерах, которые мы используем в настоящее время. Доктор Джордан и другие специалисты в этой области используют для обозначения того, что они создают, несколько удивительный термин «wetware» («мокрое обеспечение»).

Общемировой объем научных статей, книг и профильной документации растет с каждым днем. Чтобы ориентироваться в интересующем корпусе знаний, находить инсайты и ответы на вопросы, специалисты все чаще используют ИИ-помощников. Мы в Beeline Cloud решили взглянуть на open source-проекты в данной области.

Я PHP-разработчик с многолетним стажем (от слова «много»). Привык, что мой мир — это веб‑приложения, серверный код и бесконечные «фичи» на Laravel или Yii (да... легаси — это мой конёк). В последние пару лет вокруг бушует AI‑бум: всюду слышно про нейронки, LLM, про каких‑то «агентов», которые сами решают задачи. И, признаться, временами у меня появлялась лёгкая тревога. Не отстану ли я от поезда, если не перейду полностью на Python/NodeJS или не выучу новый фреймворк? Ведь почти все примеры ИИ‑интеграций, что я видел, были на Python или JavaScript. PHP в этих разговорах фигурировал редко, если вообще упоминался.

Недавно я наткнулся на упоминание о Neuron — инструменте, который гордо назван «первым enterprise‑ready агентным фреймворком на PHP». Мой скептицизм сразу поднял голову: «Агентный фреймворк? На PHP? Серьёзно?» С другой стороны, это заинтриговало. Если всё правда, то вместо того чтобы судорожно перелистывать учебник по Python, возможно, я смогу внедрять ИИ прямо там, где мне комфортно — в PHP‑стеке. И вот я решил разобраться, что же такое этот Neuron и насколько он реален.

Я не злопамятный. Просто то, что 7-го января этого года на Хабре сняли мою публикацию, текст которой был полностью создан языковой моделью, очень сильно деформировало мою душевную организацию своей, на мой взгляд, несправедливостью. Нет, я понимаю, что никто не хочет читать генерированные моделями "портянки" текста, но... а какая, по-большому счёту, разница, кто написал эту "портянку" - человек или алгоритм?

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

Команда AI for Devs подготовила перевод исследования о парадоксе безопасности локальных LLM. Если вы запускаете модели на своём сервере ради приватности, эту статью стоит прочитать. Эксперименты показывают: локальные модели вроде gpt-oss-20b куда легче обмануть, чем облачные аналоги. Они чаще вставляют вредоносный код, не замечая подвоха, и превращаются в идеальную цель для атак.

Материал из «Википедии» — свободной энциклопедии

Это список прогнозов относительно автономных автомобилей Tesla, сделанных Илоном Маском, генеральным директором Tesla, Inc. Прогнозы касаются набора функций усовершенстованной системы помощи водителю (advanced driver assistance system, ADAS) компании Tesla, в настоящее время продвигаемой как Full Self‑Driving (Supervised) («Полное автономное вождение (под присмотром)», FSD), и содержат оценки того, когда Tesla достигнет полностью автономного вождения, не требующего вмешательства человека, что, согласно «Обществу автомобильных инженеров» (SAE, Society of Automotive Engineers), соответствует пятому уровню автоматизации. Tesla не привязывает FSD к уровням SAE, но признаёт, что полная автономность «зависит от достижения надёжности, в разы превышающей показатели человеческих водителей и подтверждённой миллиардами миль опыта, а также от регуляторного одобрения, которое в некоторых юрисдикциях может занять больше времени».^[1]

Маск публично озвучивает ориентировочные сроки и предполагаемые возможности системы как минимум с 2013 года.^[2] По состоянию на январь 2024 года FSD и Tesla Autopilot в классификации SAE считается системой помощи водителю (ADAS) уровня 2.^[1][3] В феврале 2023 года инвесторы Tesla подали иск, который утверждает, что Маск совершил мошенничество с ценными бумагами, вводя в заблуждение относительно сроков разработки автономных автомобилей Tesla^[4]. В сентябре 2024 года этот иск был отклонён без права повторного предъявления иска (without prejudice); судья признал, что юристы Tesla успешно доказали, что заявления Илона Маска были «корпоративной бравадой», то есть расплывчатым корпоративным оптимизмом.^[5]

Сегодня многие разработчики различного уровня знают n8n как гибкий инструмент для автоматизации. В нем можно собрать почти любой сценарий - от простейшего Telegram-бота до сложных бизнес-процессов, используя множество готовых нод (узлов) для работы с популярными сервисами.

Но что делать, если в это множество не входит один из используемых вами сервисов, а через ноду HTTP Requests работать крайне сложно и неудобно? Или, может, хочется подключить собственный API и работать с ним по собственной логике?

Здесь напрашивается довольно простой ответ: написать свою ноду на n8n. Изначально это кажется сложным, однако, прочитав эту статью, вы сможете буквально за 1 вечер собрать минимально-рабочую ноду под ваши "хотелки".

Классический Early Stopping часто преждевременно завершает обучение, путая шум с ухудшением качества. В этой статье я покажу, как добавить анализ тренда чтобы модель останавливалась не по случайным колебаниям, а по тенденции метрики.

С появлением всё большего количества сервисов/агентов/платформ/llm-юзеров встал вопрос о встроенной и универсальной оплате. Одним из самых лучших ответов на этот вопрос становится протокол x402.

x402 - это протокол от Coinbase, продолжение инициативы от Google с их AP2.

x402 позволяет делать нативные платежи для http-интерфейсов. Запрос->Заголовок->Оплата->Результат. Без карт, лишних кабинетов с балансами, и прочей мороки. Любой веб-ресурс или API может запрашивать оплату, а клиент (человек/агент/бот) могут оплачивать с помощью блокчейн транзакций.

Для тех, кто создаёт MCP, это колоссальный буст: наконец-то появляется монетизация. Каждый вызов вашего API, может быть платным, или только методы подписки или pro-функций, могут быть платными.

Возможность монетизации выведет на рынок большое количество платных MCP, а вслед за ними начнётся настоящий бум всевозможных бесплатных MCP (запись в салон красоты/спа/итд).

Протокол работает на HTTP 402 ответе. В связи с тем, что никто его толком не использует, и он десятки лет остался свободным, сейчас наконец появляется применение.

Человечество тысячелетиями рассказывало истории, а теперь на этих историях учатся LLM.

Что такое нарратив? Это история с сюжетом, помните? — Город, герои и возвращение. Но мы не будем углубляться в философскую глубину, где люди создают историю, чтобы осмыслить себя и свой опыт (желающие могут почитать Karl E. Weick), а рассмотрим, как можно применить нарративы в понимании работы LLM.

Когда люди начали собираться для обсуждения — будь то советы, кружки, комитеты — кого-то назначали фиксировать, «протоколировать». Чаще всего это была простая запись вручную: кто присутствовал, что обсуждали, какие решения приняты. Такой подход живёт даже сегодня в небольших организациях.

Писец или секретарь сидит, слушает, старается ухватить суть — и записывает тезисами. Часто ему приходится буквально читать между строк: что важно — что нет.

Позже, в XIX–XX веках, появились стенографические методы: сокращения, скоропись — чтобы не упускать ход речи. Но даже стенографист не успевал за несколькими говорящими подряд.

ИИ с каждым годом становится умнее — на тестах и демонстрациях модели поражают логикой и ловкостью, но стоит выпустить их в реальный интернет или мобильное приложение, как начинается череда странных ошибок. Почему даже продвинутые агенты испытывают сложности на обычных сайтах и кнопках, хотя под капотом у них миллиарды параметров?

Новое исследование показывает, что дело вовсе не в дефиците данных. Оказывается, гораздо эффективнее обучать ИИ на сгенерированных симуляциях интерфейсов, а не на живых задачах из реального мира — и на выходе агенты становятся не только умнее, но и куда более стойкими к любым неожиданностям.

Разбираемся, как современные подходы меняют понимание того, что значит "обучить ИИ действовать по-человечески" — и почему выигрывает не тот, кто учится в реальности, а тот, кто научился играть с фантазией.

На просторах интернета можно найти множество интерфейсов для LLM. Все они довольно разношерстные и обладают разным функционалом: от простых чатов до почти энтерпрайз-приложений.

Я установил и опробовал 10 них (на самом деле больше, но нормальных только 10 :) В этой статье найдете их краткий обзор.

Мои курсы: Разработка LLM с нуля | Алгоритмы Машинного обучения с нуля

По-моему, вайб-кодинг — полезная фича, но я знаю, что многие его недолюбливают и считают, что AI генерит чушь, а не нормальный код. Ну тут я могу сказать как в той рекламе с гепардом: «Ты просто не умеешь их готовить».

Я начал заниматься вайб-кодингом 2 года назад (привет первая версия GPT Engineer), то есть еще до того, как ввели сам термин (он появился только в этом году). За это время у меня накопился опыт, который я переложил в небольшие рекомендации, возможно они помогут начинающим вайб-кодерам.

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

Уже год назад вышла новая книжка Юваль Ноя Харари "Нексус. Краткая история информационных сетей от каменного века до искусственного интеллекта".
Предыдущие его книги (особенно "Sapiens") были настоящими хитами. Но Nexus, к сожалению, не переведён на русский. Есть опасения, что перевода и не появится в обозримом будущем.

Книга посвящена истории и будущему информационных сетей человечества, с особым акцентом на искусственный интеллект.

Предлагаю читателю мой краткий пересказ.

Продолжаю рассказывать, как я в одного делаю проект - сайт, радио и медиаплатформу для своей музыки. В первой части был фронт и админка, теперь - как я встроил мастеринг аудио через Python сервис, чтобы не бегать по разным сайтам и не возиться с Audacity. Ну и немного про вайбкодинг - куда ж без него.

Статья про неконтролируемый рост сжигания токенов и как это угрожает юнит-экономике вашего стартапа. Делюсь ключевыми уроками, позволившими мне сократить расходы. Эти шаги стали критически важны при масштабировании до 30 000 пользователей.