DZone.com Feed на русском Заметка

DZone.com Feed на русском

DZone - это комплексная онлайн-платформа, посвященная различным аспектам технологий и программирования. Сайт предоставляет обширную информацию о различных языках программирования, технологиях, фреймворках и инструментах. Среди основных возможностей и ресурсов сайта - новости и статьи о последних тенденциях и обновлениях в технологическом секторе, различные ресурсы и учебники для обучения различным навыкам программирования, а также сообщество, где пользователи могут общаться друг с другом и делиться своим опытом и знаниями. Кроме того, DZone предлагает объявления о вакансиях для технических специалистов, являясь полезным ресурсом для тех, кто интересуется технологиями и программированием.

Трэд заметок

TL;DR: Решение о том, что строить, — это новая работа, поскольку код больше не является ограничением.Агентное кодирование устранило барьер затрат, который раньше мешал продуктовым командам одновременно реализовывать все идеи, и ограничение сместилось на продуктовое суждение: способность определить, что стоит строить. Продуктовое исследование с помощью ИИ может подготовить это суждение, анализируя гораздо больше клиентских данных, чем любой продакт-менеджер. Такой агент исследования анализирует три группы источников, проверяет восемь паттернов и аргументирует как против, так и за ваше текущее направление.Фреймворк A3 называет эту работу: Помощь (Assist) — агент анализирует и подготавливает, а люди решают. Фреймворк также помогает определить границы агента с помощью холста передачи A3 (A3 Handoff Canvas) — что делает агент, что делает человек, какие данные мы используем и т. д. — и определения готовности ИИ (AI Definition of Done) — как выглядит качественный вывод ИИ — до первого запуска.
Точность — это то, что многие новички ищут при создании модели машинного обучения. Представьте, что у вас есть модель, которая обнаруживает кожные заболевания. Ваш тестовый набор данных состоит из 10 000 пациентов, из которых только 100 больны, а остальные здоровы. Модель в итоге предсказывает, что все здоровы. Это даст 99% точности, что звучит впечатляюще, но модель не смогла выявить ни одного больного пациента.Теперь подумайте о развертывании ее в реальном мире, слепо доверяя ее точности. Это было бы катастрофой, поскольку она не смогла выявить ни одного больного человека во время тестирования. Вот почему модели могут потерпеть неудачу в реальном мире, даже если они показали впечатляющую точность на этапе тестирования. Чтобы по-настоящему понять поведение модели в реальной жизни, нам нужно рассмотреть метрики, выходящие за рамки точности.
Распределенные системы обычно распределяют данные путем хэширования ключей по узлам, чтобы ни один узел не нес всю нагрузку. "Горячий" ключ нарушает это предположение. Это ключ, объем доступа к которому значительно превышает объем доступа к другим ключам за определенный период. Глобальный счетчик просмотров или идентификатор популярного элемента может получать миллионы чтений или записей в секунду. Каждый запрос направляется в один и тот же раздел, даже когда остальная часть кластера имеет свободные мощности.Результатом является неравномерная нагрузка. Один узел достигает пределов своего процессора, сети, потоков или соединений, в то время как другие узлы остаются недоиспользованными. Добавление узлов не решает проблему, поскольку трафик продолжает разрешаться в тот же раздел. Перегруженный раздел становится узким местом для системы, которая предназначалась для распределения работы.
ИИ значительно снизил стоимость генерации кода. Но разработка программного обеспечения — это не только генерация кода. Поскольку реализация ускоряется, реальные узкие места перемещаются в планирование, архитектуру, ревью, тестирование, развертывание и долгосрочное обслуживание. Команды, которые продолжают оптимизировать только скорость написания кода, обнаружат, что тратят больше времени на исправление проблем, которых можно было бы избежать. Скорость меняет распределение времени инженеровИсторически затраты, связанные с изменениями и перестройкой программного обеспечения, были огромными. Однако ИИ позволяет организациям двигаться невероятно быстро. На порядки раньше разработка требовала больше усилий, чем любой другой этап жизненного цикла разработки программного обеспечения. Тем не менее, ИИ создал реальность, в которой инженеры могут быстро создавать, снижая некоторые из этих затрат на изменения.
Чем больше данных компании собирают о своих клиентах, продуктах и коде, тем больше накапливается дублирующейся информации, что сбивает с толку команды, которые на нее полагаются. Миллионы записей вручную не переберешь. Поэтому дедупликация теперь стала проблемой машинного обучения. В этой статье рассматривается текущее состояние обнаружения дубликатов в системах машинного обучения, где старые методы все еще работают, а также то, что привнесли в эту область эмбеддинги и большие языковые модели. Как системы машинного обучения обнаруживают дубликаты?Человек может посмотреть на две картинки или две строки и понять, одинаковые ли они. Обучение машины тому же самому поднимает сложные вопросы. Что такое «похожее»? Существуют степени сходства. Является ли «Джон Смит, ул. Дуб, 12» тем же клиентом, что и «Джонатан Смит, ул. Оук, 12»?
АннотацияПубличные статистические наборы данных редко выдают ошибку. Когда что-то идет не так, они возвращают правдоподобное число, HTML-страницу со статусом успеха или серию данных, которая тихо перестала обновляться. В этой статье описывается конвейер приема данных для оценщика стоимости жилого бетона, который объединяет четыре общедоступных набора данных: ежегодный обзор заработной платы по профессиям, ежемесячный индекс цен производителей, отраслевой эталон цен на материалы за 2022 год и перекрестную таблицу почтовых индексов и метрополий.Для каждого набора данных я документирую режим сбоя, который мы фактически наблюдали, доказательства его наличия и код TypeScript, который преобразует его в явное состояние. Основное утверждение заключается в том, что каждый тихий сбой должен стать типизированным значением, которое сопровождает число до самого пользовательского интерфейса. Конвейер работает на локальном CLI и запланированном Cloudflare Worker, записывает данные в Cloudflare D1 и обслуживает статический сайт.
Почему "Поиск" больше не достаточенПростой RAG-пайплайн — встраивание запроса, обращение к векторному индексу, помещение топ-k фрагментов в промпт — отлично подходит для одноразового FAQ-бота. Он разваливается в тот момент, когда вам нужно:Многоходовая память ("а что насчет прошлого квартала?" требует понимания, к чему относится "прошлый квартал") Решение о том, нужно ли вообще искать (некоторые вопросы требуют структурированного поиска, а не извлечения документов) Ссылки, которые вызывающий абонент может проверитьВ этой статье мы создадим небольшой, но полноценный агент с обоснованным поиском: Azure OpenAI (через Microsoft Foundry) решает, когда использовать инструмент поиска, а когда — инструмент структурированных данных, Azure AI Search обрабатывает извлечение и семантическое ранжирование по неструктурированным документам, а Azure Cosmos DB хранит состояние разговора и структурированные метаданные заказов/клиентов. Агент использует функцию вызова OpenAI для маршрутизации между двумя источниками данных и всегда возвращает ссылки.
Аутентификация в корпоративных приложениях, особенно с использованием таких фреймворков, как Angular и Spring Boot, является не просто дополнительной функцией, а фундаментальным архитектурным аспектом. Реализация таких функций, как единый вход (SSO) и многофакторная аутентификация, существенно влияет на функционирование всего приложения. SSO, хотя и кажется простым, требует адаптации фронтенда к новому процессу аутентификации. Приложения должны включать маршрутные защитники, чтобы гарантировать авторизацию пользователей перед загрузкой компонентов. Обработка перенаправлений к поставщикам удостоверений и от них требует сохранения предполагаемого состояния приложения. Кроме того, фронтенд должен корректно обрабатывать истечение срока действия токенов, рассматривая это как стандартное и ожидаемое событие, а не как аномалию. Эти сложности подчеркивают, что аутентификация определяет основную архитектуру фронтенда, влияя на управление маршрутами и обработку состояния. Она коренным образом меняет внутреннюю работу приложения, выходя за рамки простого экрана входа. Поэтому аутентификация должна быть интегрирована с самых ранних этапов разработки, а не как запоздалая мысль.
Резюме: Где это уместноЧасть 1 этой серии была посвящена кэшированию точных совпадений, а Часть 2 — семантическому кэшированию. Оба располагаются перед моделью и могут полностью пропустить вызов при совпадении. Эта статья охватывает то, что происходит с запросами, которые все же достигают модели: повторное использование вычисленного состояния модели, либо внутри вашего собственного механизма вывода, либо внутри системы поставщика API, а также производственные детали, которые превращают план кэширования в то, что команда может реально выполнить и чему доверять.Уровни 3 и 4 представляют собой две версии одной и той же основной идеи — повторное использование вычисленного состояния модели, разделенные по тому, кто управляет сервером модели. Если вы управляете собственными графическими процессорами, применяется уровень 3. Если вы вызываете размещенный API, применяется уровень 4. Вам редко требуется оба одновременно для одного и того же вызова модели.
Агент, созданный в Microsoft Foundry, принимает множество решений за один прогон. Он вызывает модель, выбирает инструмент, считывает результат инструмента и снова вызывает модель. Когда ответ медленный или неправильный, причина кроется где-то в этой последовательности, а окончательный ответ не дает никаких подсказок о том, какой шаг вышел из строя.Foundry записывает эту последовательность как трассировки OpenTelemetry. По умолчанию размещенный агент отправляет их в Application Insights, что является хорошим местом для начала. Для команды, которая ежедневно создает агентов, остаются два пробела. Первый пробел возникает во время разработки. Разработчик, который изменяет подсказку или инструмент, хочет видеть промежутки этого одного прогона в течение нескольких секунд на ноутбуке, без развернутого проекта. Второй пробел возникает после развертывания. Владельцы агентов хотят иметь общую панель мониторинга с количеством прогонов, перцентилями задержки, использованием токенов, задержкой инструмента и ошибками, и они хотят запрашивать необработанные промежутки на том же языке, который они используют для остальных своих данных.
Большинство команд воспринимают поломку веб-скрапера как рутину. Кто-то замечает некорректные данные, открывает страницу в браузере, исправляет селектор и перезапускает. Это работает, когда у вас один скрапер и кто-то ежедневно просматривает его вывод. Это перестает работать, когда у вас их дюжина, и поломка проявляется через неделю в виде странной цифры в отчете ниже по цепочке. В этой статье я расскажу, как я построил скраперы, которые каталогизируются, проверяются на работоспособность, отслеживаются и ремонтируются, как и любая другая продакшн-служба, при этом LLM предлагает исправления, а обычный Python решает, будут ли эти исправления внедрены.Проект возник на хакатоне WeMakeDevs, где он занял первое место. Сам продукт невелик: он извлекает данные телегида за примерно двенадцать дней от трех стриминговых провайдеров, ранжирует десять лучших предстоящих фильмов и десять лучших предстоящих шоу и позволяет записать любое из них на Philo одним кликом. Я опущу описание продукта и сосредоточусь на технической части: правилах отклонения, модели состояния, верификаторе и коде, стоящем за каждым из них. Эти компоненты применимы к любой команде, которая использует скраперы, или к любой команде, которая позволяет LLM изменять рабочую систему.
Введение: От прототипа голосового ИИ до оператора производственного телефонаДемо голосового ИИ — это модель, микрофон и колонка. Телефонный агент — это распределённая система. Аудио поступает от оператора по SIP-магистрали, звонящие прерывают на плохих линиях, бэкенды перерываются, у операторов моделей плохие рабочие минуты, и звонящие ищут человека в тот момент, когда что-то идёт не так. В этой статье показано, как создать ИИ-ресепшиониста для стоматологической клиники. Он отвечает на звонки на номер клиники, ищет пациентов по идентификатору звонящего, ищет и записывается на приёмы через бэкенд-API, а также передаёт звонки на ресепшн, когда требуется человек. Он работает на LiveKit Agents — открытом фреймворке для Python и Node.js. Логи выделяют, какие функции требуют LiveKit Cloud. Каждый фрагмент взят из одного рабочего проекта, и каждый вывод показывает, что он напечатал.
Хранилища признаков решают критическую проблему несогласованности признаков между обучением и обслуживанием моделей машинного обучения. Feast — это решение с открытым исходным кодом, предназначенное для устранения этого разрыва путем управления реестрами признаков, материализацией и онлайн-извлечением. Это гарантирует, что модели последовательно получают доступ к тем же данным в производственной среде, что и во время обучения. Хотя часто демонстрируется с использованием реляционных баз данных или облачных хранилищ данных, в этой статье исследуется альтернативный подход. В ней используется Neo4j Desktop в качестве движка для вычисления признаков. Пять признаков включают простые агрегации, которые легко обрабатываются запросами Cypher. Шестой признак, идентификатор сообщества клиентов, получается с использованием графовых алгоритмов. Эти алгоритмы идентифицируют клиентов со схожими моделями покупок с помощью сходства узлов Graph Data Science. Затем обнаружение сообществ Louvain группирует этих похожих клиентов. Затем Feast поглощает все шесть признаков. Он материализует их в автономное хранилище SQLite для эффективного обслуживания во время вывода. Этот процесс также обеспечивает построение корректных с точки зрения времени обучающих данных.
Команды разработчиков программного обеспечения внедряют ИИ-агентов для написания, запуска и исправления тестов быстрее, чем когда-либо прежде. Прорыв обычно заключается не только в самой модели. ChatGPT и Cursor могут использовать один и тот же базовый интеллект, но один ощущается как помощник по копированию и вставке, в то время как другой ощущается как член команды, который может редактировать файлы, выполнять команды и итерировать до завершения задачи. Разница заключается в "упряжи" агента: уровне оркестрации, который оборачивает модель инструкциями, инструментами, контекстом и ограничениями, чтобы сырое рассуждение стало надежным действием.В автоматизации тестирования этот разрыв имеет еще большее значение. Неудачный сценарий может привести к тысячам строк вывода Playwright, охватывать объектные модели страниц, определения шагов, тестовые данные и несколько сред. Если все это свалить в один длинный чат, модель замедлится, расходы возрастут, а решения станут менее четкими. Хорошо спроектированная "упряжь" рассматривает модель как планировщика, а не как самосвал. Она индексирует кодовую базу, чтобы агент мог задавать структурные вопросы вместо чтения целых файлов. Она делегирует выполнение тестов и генерацию файлов небольшим, изолированным рабочим процессам, которые возвращают компактные сводки. Она проверяет учетные данные, профили сред и эталонные фикстуры перед запуском, чтобы сбои были обнаружены на ранней стадии, а не ошибочно помечены как "сломанные локаторы". И когда что-то ломается, она направляет сбой по управляемому пути: диагностика, исправление, аудит исправления, повторный запуск только измененного, отчет о результатах в форме, с которой люди могут работать.
Почему кэширование промптов важно для LLM-приложений?Современные LLM-приложения часто получают один и тот же или почти один и тот же промпт более одного раза. Это происходит при отправке форм, распространенных вопросах в FAQ, вызовах инструментов агента или когда пользователь задает один и тот же вопрос разными словами. Без кэширования каждый из этих повторяющихся запросов влечет за собой полную стоимость токенов, полную задержку и создает ненужную нагрузку на ваши лимиты запросов.Сегодня на практике используются четыре метода кэширования. Эта статья, Часть 1 из 3-серийного цикла, охватывает первый и самый базовый: кэширование по точному совпадению. Часть 2 охватывает семантическое кэширование для запросов, которые означают одно и то же, но сформулированы по-разному. Часть 3 охватывает то, что происходит на уровне самого обслуживания модели: повторное использование KV-кэша при самостоятельном размещении и кэширование префиксов поставщика, а также производственные детали, которые в конечном итоге нужны каждой команде: отслеживание метрик, расчет затрат и полный контрольный список.
Подготовка к сессиям уточнения бэклога может быть трудоемкой и повторяющейся задачей. Искусственный интеллект отлично справляется с такими утомительными задачами, как просмотр всех элементов бэклога и комментариев команды. Однако возникает значительный риск, когда ИИ-агенту поручается "помощь в уточнении". Такой агент может непреднамеренно увести разговор от команды. Даже не написав критерии приемки, агент может предлагать действия, такие как закрытие, объединение, разделение или создание элементов бэклога. Это заранее отвечает на вопросы, которые команда должна была исследовать во время уточнения. Чтобы смягчить это, необходимо установить четкие границы, прежде чем использовать агента. Роль агента должна заключаться в выявлении доказательств и формулировании вопросов. Затем владелец продукта отвечает за рассмотрение этих вопросов и определение повестки дня для фактической сессии уточнения. Затем команда проводит процесс уточнения на основе этой повестки дня. Документирование этих границ в A3 Handoff Canvas закрепляет обязанности агента и позволяет владельцу продукта обеспечить их соблюдение.
ИИ-агенты и агентные системы стремительно внедряются в долгосрочные системы и рабочие процессы. Они развиваются, чтобы обеспечивать поддержку, выходящую за рамки коротких взаимодействий "запрос-ответ", и переходят к непрерывным процессам, которые извлекают информацию, вызывают инструменты, координируются с другими агентами, ожидают внешних событий и, в конечном итоге, выполняют действия в реальных системах.Это расширение ставит новую задачу: надежное принятие решений на основе изменяющихся входных данных. Когда агенты принимают решения на основе состояния системы или компонента, они могут наблюдать, рассуждать и принимать обоснованные решения. Однако в быстро меняющихся средах причины определенных решений могут измениться до момента их выполнения. В результате возникает кажущееся противоречие: система может иметь актуальное состояние, но выполнять устаревшее решение.
В списке LinkedIn самых быстрорастущих профессий в США в этом году произошло нечто странное. Первое место заняла не медсестра-практик или техник по возобновляемым источникам энергии. Его заняла должность, которая практически не существовала до 2023 года: инженер по искусственному интеллекту, занявший первое место второй год подряд. Наиболее распространенными навыками, указанными рядом с этой должностью, были LangChain, генерация с дополненной выборкой и PyTorch, ни один из которых не встречается в типичной учебной программе по информатике.Я более 20 лет занимался созданием систем, которые не могли ошибаться, включая платформу учета кредитов, выходные данные которой напрямую поступали в отчетность SEC для крупных банков США, и платформы на базе Kafka, управляемые событиями, обрабатывающие данные о продуктах на 29 языках. Инженеры, которых я наставляю и которые преуспевают в качестве инженеров по искусственному интеллекту, редко имеют глубокие математические знания. Они понимают правильный порядок изучения вещей и почему этот порядок важен.
Периодические сбои тестов в распределенной среде CI/CD могут замедлять разработку и затруднять расследование причин сбоев. Когда автоматизированный набор тестов завершается с ошибкой на локальной машине разработчика или на staging-сервере, инженер может просмотреть локальные журналы, подключить отладчик или вручную отследить изменения состояния. Но когда тесты выполняются во временном контейнере, AWS Lambda или агенте без агента, постмортем-отладка становится значительно сложнее.В традиционной конфигурации неудавшийся сбор показывает только общую ошибку утверждения (504, ElementNotFoundException и т. д.). Инженеру может потребоваться вручную просмотреть группы журналов CloudWatch за примерное время, выполнить запрос к Splunk или проанализировать изменения состояния в нижестоящих микросервисах, чтобы понять, почему тест завершился с ошибкой. Как только срок хранения журналов истекает или если у выполнения не было общего, идентифицируемого идентификатора корреляции, у инженера нет дальнейшей информации о причине сбоя.