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

В командной работе есть парадокс, который раздражает сильнее, чем чужие ошибки. Ты объясняешь, и объясняешь все верно, но твой собеседник тебя не понимает, хоть ты тресни. Не его, разумеется. По столу например :)

Эта ситуация, в общем-то, не редкая и встречается почти повсеместно. Я собрала небольшой гайд по ясной коммуникации в работе про то, как этого избежать.

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

Что если переход на локальную инфраструктуру (вроде Ollama) это решение, которое не просто поможет сэкономить, но изменит саму динамику разработки?

Если вы попробуете загуглить, кто такой продакт-менеджер, вы получите красивую, но неоднозначную картинку. Стратег, лидер, аналитик, мини-сео. А еще, если открыть 10 вакансий от 10 разных компаний, то вы увидите 10 разных ролей.

Так кто же это такой? Давайте разберемся в этом вопросе подробнее.

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

Всем привет, меня зовут Настя, и мне НЕ нравится, когда наши компании требуют от нас повсеместное внедрение искусственного интеллекта во все процессы.

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

Эти же механизмы лежат в основе галлюцинаций, ложной уверенности и ошибок LLM в обычных бизнес-процессах. Даже без атак и при «хороших» промптах.

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

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

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

Большие языковые модели, типа GPT, Claude, Gemini и другие ИИ-системы, поразили разработчиков своей способностью генерировать тексты, звучащие как человеческие. Однако, если вы когда-либо использовали ChatGPT или подобные инструменты, вероятно, они не раз уверенно говорили вам что-то совершенно неверное. Эти ошибки ИИ, часто называемые «галлюцинациями», варьируются от незначительных фактических ошибок до полных выдумок. Они могут быть забавными (например, ИИ изобретает вымышленный исторический факт) или представлять серьезную проблему (представьте, что ИИ-ассистент предлагает несуществующую функцию или чат-бот выдает медицинский совет, которого не существует).

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

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

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

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

Сегодня поговорим о проблеме, которая возникает при общении с заказчиками. Как правило для них термин «атрибуты качества» звучит абстрактно и не воспринимаются, как нечто, имеющее прямую ценность для бизнеса. Однако же этот разрыв стоит устранять.

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

Wireshark прост в использовании и является отличным вариантом для новичков, но при этом достаточно мощный для профессионалов, которым нужны детализированные данные о сетевом трафике.

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

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

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

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

Всем привет! Заключительная часть о требованиях, которые вспоминают в последний день перед релизом.

В первой части мы говорили о производительности и масштабируемости, во второй — о сопровождаемости, надёжности и безопасности.

Сегодня в повестке требования, которые влияют на пользовательский опыт и ощущение качества продукта. Да, вы верно догадались, речь про юзабилити, совместимость и переносимость.

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

Привет! Сегодня мы продолжаем разбирать требования, которые вспоминаются нам за день перед релизом.

Если функциональные требования отвечают на вопрос «что система делает?», то эти — на вопрос «насколько хорошо она это делает и сколько это стоит бизнесу». И именно их качество больше всего влияет на архитектуру и стоимость разработки.

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

Не переключайтесь!

Если вы задаётесь вопросом, что лучше — Apache Kafka или RabbitMQ, или думаете, что RabbitMQ надёжнее Apache Kafka, хочу сразу остановить вас. Эта статья рассматривает обе системы с более широкой точки зрения и сосредоточится на функциональности, которую они предоставляют. Это поможет вам принять обоснованное решение о том, какую систему использовать и в каких случаях.

Справедливость — ключевой элемент игр. Кто захочет играть в игру, которая явно подстроена в чью‑то пользу? Сбалансированная игра гарантирует, что у всех игроков есть равные шансы на победу, без нечестных преимуществ для отдельных участников. Однако достичь баланса в играх — задача далеко не простая.

В этой статье мы рассмотрим стратегии балансировки игр и дадим советы геймдизайнерам, как создать более сбалансированный игровой процесс. Независимо от того, разрабатываете ли вы ролевую игру, стратегию в реальном времени или соревновательный многопользовательский проект, эти советы будут полезны.

Для чего существуют принципы ACID? Можно ответить по бумажке, сказать, что это нужно для того, чтобы каждая транзакция обрабатывалась надежно, данные оставались в безопасности и системы работали предсказуемо.

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

В этой статье вы узнаете, почему так важны принципы ACID и что это за принципы. Оставайтесь со мной, если интересно!

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

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