[Часть 1]
С помощью чего можно тестировать мобильные приложения: 4 основных способа

Когда мы говорим о мобильном тестировании, большинство сразу думает про «запустил приложение на телефоне — проверяешь».
Но на деле способов гораздо больше. И у каждого есть свои плюсы, минусы и нюансы, которые важно учитывать.

Существует 4 основных способа:

1. Нативное тестирование
Это когда вы тестируете реальное приложение на реальном устройстве (iOS или Android).
💡 Плюсы: максимальная точность, поведение как у пользователя.
⚠️ Минусы: нужны устройства, время на установку и поддержку окружения.

2. Симулятор (Simulator)
Применяется в iOS. Это программная имитация работы устройства. Симулятор копирует поведение iPhone/iPad, но работает в среде компьютера.
💡 Плюсы: быстро запускается, удобен для проверки UI.
⚠️ Минусы: не эмулирует реальные датчики, производительность и железо (Например, камера, блютуз, faceId/TouchId), для запуска необходим MacBook.

3. Эмулятор (Emulator)
Чаще встречается в Android. Он эмулирует не только интерфейс, но и процессор, что делает его ближе к реальному устройству.
💡 Плюсы: можно тестировать производительность, работу с разными версиями Android.
⚠️ Минусы: работает медленнее симулятора, производительность зависит от железа ПК, нельзя проверить различные физические условия (Например, перегрев, камеру)

4. PWA (Progressive Web App)
Это веб-приложение, которое можно «установить» на телефон и использовать как обычное.
💡 Плюсы: не требует отдельной установки через App Store или Google Play, работает кроссплатформенно.
⚠️ Минусы: ограничен доступ к функциям устройства, зависит от браузера.

🎯 Итог
В тестировании часто комбинируют эти подходы:
– что-то проверяют в симуляторе/эмуляторе,
– что-то на реальных устройствах,
– Если в компании PWA приложением, то тестируют его + не забывая про нативные

В следующих постах я расскажу про каждый способ подробнее

Баг у Яндекса.
Показывают старую дату в инаппе, но при нажатии переход на слайды с рекламным предложением

#баг_в_проде

[Часть 2]
PWA в мобильном тестировании

PWA (Progressive Web App) — это веб-приложение, которое можно установить на телефон и использовать почти как нативное.
Оно открывается в отдельном окне без адресной строки, имеет иконку на рабочем столе и может работать даже без постоянного интернета.

💡 Ключевые особенности PWA:

1️⃣ Работает оффлайн и быстро загружается
При первом запуске PWA сохраняет нужные файлы (страницы, картинки, стили) на телефон.
За это отвечает Service Worker — скрипт, который перехватывает запросы и может отдавать данные из локального кэша.
Благодаря этому приложение:

открывается быстрее, чем обычный сайт;

может работать без интернета или с медленным соединением (например, показывать последнюю загруженную версию данных).

2️⃣ Запускается как приложение
В PWA есть файл manifest.json — в нём задаются название, иконка, цвет фона и режим отображения.
Поэтому оно выглядит как «настоящее» приложение, а не просто сайт в браузере.

3️⃣ Push-уведомления

Android: работают почти так же, как в нативных приложениях.

iOS: поддержка появилась с iOS 16.4, через Safari и только для установленных PWA.

Примеры PWA - аэрофлот, СберДиск

➕ Плюсы PWA:
- Быстрая установка без App Store / Google Play
- Одновременное тестирование на iOS и Android
- Мгновенные обновления — без долгих релизов
- Частичная оффлайн-работа

➖ Минусы PWA(условные):
- Нет доступа к некоторым функциям устройства (Bluetooth, датчики смартофана (Например, shake))
- Различия в поведении между браузерами (Chrome, Firefox, Safari, Samsung Internet)
- Ограниченные пуши в iOS и очистка кэша системой при нехватке памяти

🔍 Что тестировать в PWA обязательно:
- Поведение при отсутствии или слабом интернете
- Корректность обновления данных (нет ли устаревшего кэша)
- Реакцию на очистку кэша/хранилища системой (особенно на iOS)
- Отображение и функциональность в разных браузерах и на разных устройствах
- Установку, удаление и обновление приложения
- Push-уведомления

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

[Часть 3]
Симулятор и эмулятор в мобильном тестировании — в чём разница?

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

🖥 Где запускаются

iOS Simulator — только на Mac через Xcode (нужен MacBook/iMac).
Android Emulator — через Android Studio на Windows/macOS/Linux.

🧠 Что под капотом

Симулятор (iOS) — имитирует только программную среду устройства, но не его аппаратную часть. Запускается на процессоре вашего Mac.
Эмулятор (Android) — создаёт виртуальную среду, которая близко повторяет реальное устройство, включая его аппаратное и программное обеспечение + в эмуляторе можно настроить версию операционной системы.

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

❔Когда что выбирать

Симулятор: быстрая проверка вёрстки, навигации, локализации, диплинков, базовой логики iOS.
Эмулятор: совместимость версий Android, разрешения, гео/датчики, сценарии со звонками/SMS, динамики, микрофоны, складные экраны, базовая производительность.

➕Плюсы

Симулятор: стартует мгновенно, удобен для быстрых UI-итераций.
Эмулятор: гибкие профили устройств/ОС, больше возможностей для проверки

➖Минусы

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

🎯 Итог
Симулятор и эмулятор — отличные инструменты для быстрого тестирования или когда нет реальных девайсов с нужным разрешением/версией


👉 P.S. Если остались вопросы или что-то непонятно, то смело пишите в комментарии.

Нужно нажать «Регистрация» или «Зарегистрироваться» ?🧐

Да и в целом очень много вопросов к этой форме…

Сайт - https://pitergsm.ru/auth/?register=yes

#баги_в_проде

После длительной тишины возвращаюсь с новым фокусом

Старые форматы — разборы собесов, теория, общие советы — не находил, что добавить от себя. Этого и так хватает в QA-блогах.

Чем я занимался всё это время: продолжал работать и менторить, плюс плотно погрузился в AI — встраивал LLM в рабочие инструменты (боты для анализа тест-кейсов, инструменты ускорения локализации, разбора логов). Параллельно смотрел доклады, читал, что происходит вокруг, и пробовал автоматизировать рутину разными моделями. Сравнивал, под какие задачи какая лучше подходит. И понимал: недетерминированность — когда один и тот же запрос даёт разные ответы — это тоже зона, которую надо проверять и тестировать. Мне нравится QA, AI всё активнее изучаю и применяю — вот и подумал: почему бы не объединить и не углубиться в то, как всё это тестировать?

Поэтому решил, что буду писать — про тестирование AI-систем. LLM, RAG, AI-агенты. Буду делиться тем, что изучил, показывать эксперименты с метриками/цифрами и обзоры инструментов, которые сам пощупал.

На экспертность в сфере тестирование AI не претендую (пока что 😁)

Сейчас почти везде слышим про AI, ML, LLM, GenAI. Часто эти слова идут как взаимозаменяемые, хотя означают разное. Давайте разберёмся в определениях и нюансах.

✦ AI (Artificial Intelligence, искусственный интеллект) — самое общее из этих слов. К нему относят любые системы, решающие интеллектуальные задачи человека: распознавание речи, поиск лица на фото, перевод текста, ответ на вопрос, подбор фильмов.

✦ ML (Machine Learning, машинное обучение) — подход к созданию AI через обучение на примерах, а не через правила, написанные вручную.
Например, у нас есть задача «определить компонент по тексту бага» (auth / payments / UI / API). Подаём модели 500 уже разобранных багов из истории — пары «текст бага → правильный компонент». Модель сама находит закономерности: «не приходит SMS» → auth, «не списываются деньги» → payments. На новом баге она предсказывает компонент по тексту.

Алгоритмы под капотом могут быть разные — от простых статистических методов до нейросетей. Но принцип общий: правила не пишутся вручную, модель выводит их сама из данных.

✦ LLM (Large Language Model, большая языковая модель) — это ML-модель, обученная на гигантском объёме текста (статьи, книги, форумы, документация). Модель не «понимает» текст как человек — она статистически выучила, какие слова и идеи следуют за какими. На основе этого она отвечает на вопросы, продолжает текст, переводит, пишет код, объясняет идеи, делает выжимку.

На вход — текст, на выход — текст (современные модели принимают и изображения, аудио, файлы — но языковая часть остаётся ядром).
ChatGPT, Claude, Llama — это всё LLM (одновременно они и ML, и AI: категории не взаимоисключают, LLM — просто самое точное название).

В QA можно применять для генерации тест-кейсов по требованиям, анализа ТЗ на противоречия, разбора логов на аномалии и написания автотестов.

✦ GenAI (Generative AI, генеративный AI) — это не отдельная модель, а направление AI: системы, создающие новый контент (текст, картинка, код, аудио).
LLM — часто используют как GenAI для текста.
Midjourney, Stable Diffusion — GenAI для картинок.

Подводя итог:
AI — общее понятие
ML — подход
LLM — класс моделей
GenAI — направление AI.

Всё ли понятно по определениям? Если что-то нужно уточнить — смело пишите в комменты. И если хочется углубиться в какой-то из этих терминов — скажите, разберу отдельным постом.

LLM — это просто два файла

Первый файл — веса модели. Миллиарды чисел, которые получились при обучении. Каждое число — крошечная настройка, влияющая на то, как модель связывает слова. Когда говорят «модель на 70 миллиардов параметров» — это про них. Llama 70B весит ~140 ГБ, у Claude и GPT — больше, намного больше.

Откуда эти числа берутся? Модель «читает» весь интернет — книги, статьи, форумы, документацию, код. И в процессе обучения веса настраиваются так, чтобы модель умела предсказывать следующее слово в любом тексте. Не дословное запоминание, а впечатление от прочитанного: какие слова идут рядом, какие идеи связаны, как устроен язык. Само обучение идёт месяцами на тысячах GPU и стоит десятки–сотни миллионов долларов. После этого модель дообучают на инструкциях и обратной связи людей — чтобы она отвечала как ассистент, а не продолжала случайную интернет-страницу. Но это отдельная большая тема.

Второй файл — программа, которая эти веса использует. Берёт то, что написали, прогоняет через веса и считает, какое слово вероятнее всего идёт дальше. Не всегда выбирает самое вероятное — поэтому один и тот же запрос даёт разные ответы. Дописывает. Повторяет. Так слово за словом складывается ответ, который читается как речь человека. Несколько сотен строк кода. Всё. (Технически модель работает не со словами, а с токенами — кусочками слов или отдельными символами. Но об этом отдельный пост)

Отсюда — ключевое. Генерация ответа — не «вспомнить факт», а составить правдоподобное продолжение по статистике. Каждый раз заново. И главное — модель не знает, что составляет. У неё нет внутреннего флага «я не уверена» или «этого я не знаю». Она просто подбирает следующее слово по вероятности и выдаёт одинаково уверенно — попало в правду или нет.

Поэтому когда возникают галлюцинации — это не баг, а природа модели: обучение дало ей понимание языка, а не базу фактов.

А как дать модели факты, чтобы не выдумывала? Подкладывать нужный контекст прямо в запрос. Это называется RAG. В дальнейшем буду разбирать и показывать примеры работы.

В общем, LLM: не понимает текст как человек. Не помнит, на чём её учили, а составляет каждый ответ заново. И всё равно отвечает что-то осмысленное 😅

Базовые метрики для оценки ML-моделей

Мы уже разбирали в канале, что такое AI, ML, LLM и GenAI, и как LLM устроена «под капотом». Следующий вопрос — как оценить, насколько модель действительно работает и выполняет то, что нами задумано.

Простой оценки «правильно/неправильно» здесь не хватает — одна и та же модель может ошибаться/отвечать по-разному. Поэтому давайте разберём базовые метрики: precision, recall, F1, accuracy. Что они означают, как их считать и как читать вместе.

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

Чтобы оценить его работу, берём срез из 500 комментариев из реального потока, заранее размеченных вручную:
- 200 нарушают правила
- 300 нормальные

Запустили модератор на этих 500. Он отметил как нарушения 75 комментариев. Сверяем с разметкой:
- 60 из них реально плохие
- 15 нормальные сообщения, ошибочно заблокированные

Что в итоге:
- из 200 нарушений модель поймала 60, остальные 140 пропустила
- из 300 нормальных верно одобрила 285 (а 15 ошибочно заблокировала — это те же самые из блока выше)

Дальше считаем метрики.

Продолжение ниже ↓

✦ Precision — доля верных срабатываний среди всех срабатываний модели. У модератора это 60 верных из 75 отмеченных
Precision = 60/75 = 0.80 — достаточно высокий
4 из 5 блокировок обоснованы. Но 1 из 5 — нормальное сообщение, заблокированное ошибочно, что бьёт по доверию пользователей

✦ Recall — доля пойманных нарушений среди всех реальных нарушений в выборке. У модератора это 60 пойманных из 200 реальных.
Recall = 60/200 = 0.30 — низкий
Ловится только треть нарушений, остальные две трети уходят в публикацию или идут на ручную модерацию

✦ F1 = 2 × P × R / (P + R) — гармоническое среднее precision и recall
У нашего LLM-модератора F1 ≈ 0.44 — меньше, чем простое среднее precision и recall: (0.80 + 0.30) / 2 = 0.55
Гармоническое всегда тянется к меньшему числу — поэтому F1 сразу подсвечивает провал по одной из метрик и не позволяет компенсировать его успехом по другой

✦ Accuracy — доля верных решений среди всех решений модели. У модератора это 60 верно отмеченных нарушений + 285 верно одобренных нормальных = 345 правильных решений из 500
Accuracy = 345/500 = 0.69. Метрика самая простая в подсчёте, но когда классы в данных распределены неравномерно, она перестаёт отражать реальное качество модели

Главное — смотреть метрики вместе.

Accuracy 0.69 на нашей выборке выглядит нормально, но F1 ≈ 0.44 уже подсвечивает дисбаланс.
Precision 0.80 даёт 15 ошибочно заблокированных нормальных сообщений
Recall 0.30 пропускает 140 нарушений из 200
Такой LLM-модератор не готов к автономной работе — пропускает 70% нарушений и заодно блокирует часть нормальных

И это только одна из возможных конфигураций. Модель может ловить почти всё, но блокировать невинных. Может быть осторожной — почти не ошибаться на блокировках, но пропускать половину нарушений. А может вообще ничего не ловить — и при этом показать accuracy 95%

В следующем посте разберу какие бывают сочетания этих метрик и что они говорят о работе модели

Если что-то непонятно и нужно уточнить — смело пишите в комментариях ✍️

Сочетания precision и recall — и когда даже этих метрик мало

Возвращаемся к LLM-модератору из прошлого поста. Выборка та же: 500 комментариев, 200 нарушений и 300 нормальных.
Давайте посмотрим, какие бывают сочетания precision и recall, что они говорят о модели и какие метрики нам ещё могут помочь.

✦ Высокий precision, низкий recall — P = 0.80, R = 0.30, F1 = 0.44

Это и есть наш модератор из прошлого поста. Из его блокировок 4 из 5 обоснованы. Но 70% нарушений уходят в публикацию.

Очередь на ручную проверку небольшая — модераторам почти не прилетают ложные срабатывания. Зато реальные нарушения остаются на виду, и через неделю — волна жалоб от пользователей: «почему это до сих пор не удалили?»

✦ Низкий precision, высокий recall — P = 0.51, R = 0.90, F1 = 0.65

Зеркальная ситуация. Модель ловит почти все нарушения, но только половина её блокировок обоснована — ложные срабатывания на нормальных комментариях

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

✦ Высокий precision, высокий recall — P = 0.80, R = 0.80, F1 = 0.80, accuracy = 0.84

Ловит большинство нарушений и почти не ошибается в блокировках.

Без перекоса в одну из сторон. В ручную модерацию идут только реально сомнительные случаи. Но даже здесь каждое пятое нарушение проходит мимо человека — это плата за автомодерацию вместо ручного ревью всех комментариев

✦ Особый случай — модель «всё одобрить»

Не блокирует ничего: одобряет все 300 нормальных и пропускает все 200 нарушений.
Recall = 0/200 = 0 — нарушений модель не ловит вообще. Precision не определён: срабатываний ноль, делить не на что. F1, соответственно, тоже 0. А вот
accuracy = 0.60 — выглядит не катастрофично

И в реальной модерации нормальных обычно на порядок больше: при 9500 нормальных и 500 нарушений тот же подход даёт accuracy = 0.95

Метрика говорит «всё отлично», а модель не ловит ничего

Тут на помощь приходит ещё одна метрика в копилку — balanced accuracy
Это среднее двух долей: пойманных нарушений и верно одобренных нормальных
В нашем случае: (0 + 1) / 2 = 0.50, повезет не повезет. В отличие от accuracy, она не обманывается дисбалансом классов

Таким образом, чтобы прочитать модель, смотрим всё вместе:
• precision и recall — где модель ошибается и какими
• F1 — нет ли провала по одной из шкал
• accuracy — общая доля верных решений
• balanced accuracy - не врёт ли accuracy из-за неравных классов

А к нашему LLM-модератору вопрос. Какие precision и recall вы бы посчитали достаточными, чтобы выкатить его в прод?
Пишите числа в комментарии, обсудим)

На каком языке писать системный промпт API

На английском. Английский — это база. Всё.

А если серьёзно — перевод системного промпта на английский режет 10–25% токенов на одной и той же задаче.
Сколько это в долларах — зависит от модели. Считаем

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

Чтобы понять почему, важно знать — модель считает деньги не в символах, а в токенах

Простой пример — cat модель видит как один токен, кошка — как два-три. Один и тот же смысл, разное число токенов

У западных моделей русский даёт в 1.4–1.8× больше токенов на тот же текст — токенизаторы обучали в основном на английском

Чтобы подтвердить свои слова, я решил провести эксперимент и сравнить модели. Прогнал системный промпт LLM-модератора (~150 слов, 5 правил) на 8 актуальных API. 100k запросов в день × 30 дней. Вот экономия от перевода системного промпта на английский

✦ DeepSeek V4 Flash — 25%
✦ DeepSeek V4 Pro — 25%
✦ Claude Sonnet 4.6 — 24%
✦ Claude Opus 4.7 — 16%
✦ GPT-5-mini — 12%
✦ GPT-5 — 12%
✦ GigaChat 2 Pro — 10%
✦ GigaChat 2 Max — 10%

Полные расчёты, токены RU/EN и ссылки на прайсы — в комментарии под постом.

Разница в токенах между RU и EN системным промптом раскладывается на две категории:

Первый — сам язык. Русский физически на 17% длиннее английского по символам на тот же смысл. Это базовая плата, её не убрать никаким токенизатором
Второй — токенизатор модели. У GigaChat он симметричный (нулевая добавка). У западных моделей токенизатор обучен в основном на английском и режет английский экономнее — добавляет +20–55% сверх языковой базы

Что в итоге:
✦ Топовые западные API (Opus, GPT-5, Sonnet) — системный промпт на английском, экономия серьёзная
✦ GigaChat и российские модели — как удобнее, перевод на английский выигрыша почти не дает
✦ Mini и дешёвые модели (GPT-5-mini, DeepSeek Flash) — можно не возиться, разница минимальная
✦ Локальная модель (Llama, Qwen, Gemma) — без разницы, нет цены за токен

Важно ещё упомнуть — английский системный промпт ≠ перевод всего на английский. Русские примеры, сленг и паттерны нарушений держим на русском прямо внутри английской инструкции, так как в таком случае мы можем потерять контекст. То же касается пользовательского контента — оставляем на русском. Перевод комментариев на ходу удваивает счёт (модель работает дважды) и снижает точность модерации — теряются сленг, мат с обходами, реалии.

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

LLM в проде. Что есть, кроме API

Хочу рассказать про две концепции, которые есть в проде сверх обычного вызова API

✦ Prompt caching — повторяющийся системный промпт читается из кэша дешевле обычного input. У OpenAI, Anthropic и DeepSeek фича включается одним флагом или работает автоматически

Главное — кэш работает только на длинном входе (от 1024 токенов). На длинных промптах с примерами и контекстом экономия по input может доходить до 90%. Короткие системные промпты, как, например, у нашего модератора (~200 токенов), под кэш просто не попадают. И ещё тонкость — кэш чувствителен к префиксу. Любая правка в начале системного промпта (даже добавление переменной с датой) — и кэш промахивается на следующем запросе. Счёт может начать увеличиваться незаметно

✦ Проксирование — в проде запрос редко идёт напрямую в OpenAI или Anthropic. Между приложением и моделью обычно стоит свой слой — внутренний gateway компании. Через него команда может:

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

Что в этом важно для QA

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

✦ Golden set по cost — небольшая база эталонных примеров (~20-50 кейсов), на которой промпт прогоняется перед выкаткой. После правки на тех же входах смотрим, не сломалось ли качество и не подскочило ли число токенов
✦ Прогон на нескольких моделях — токенайзеры у разных моделей режут текст по-разному. В эксперименте к прошлому посту Opus 4.7 на одном и том же тексте дал +49% токенов по сравнению с GPT-5. Если в системе предусмотрена смена модели или провайдера, регрессию снимаем отдельно по каждой модели/провайдеру
✦ Регрессия по стоимости — на каждом релизе снимаем количество токенов на эталонном наборе. Заметный рост — нужно разобраться до релиза и понять причину, оценить рост стоимости

Интересная новость про то, как крупные компании Microsoft, Uber, Meta столкнулись с проблемой, что корпоративный AI оказался дорогим и стали отменять лицензии на Claude code

Рекомендую к прочтению)

https://fortune.com/2026/05/22/microsoft-ai-cost-problem-tokens-agents/

Что такое temperature и на что она влияет

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

Temperature отвечает за случайность. Одна и та же модель на один и тот же промпт может отвечать «слово в слово» — а может каждый раз по-новому. Сколько случайности в ответе — решает это число. У OpenAI — от 0 до 2, у Anthropic — от 0 до 1. У локальных моделей через Ollama (Llama, Qwen) параметр тоже есть — жёсткого потолка в доке нет, по умолчанию в Ollama стоит 0.8

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

Допустим, модель дописывает фразу «Тест получился…» — и следующие слова предполагает такие (числа условные)

✦ «зелёный» — 50%
✦ «красный» — 30%
✦ «жёлтый» — 15%
✦ что-то странное — 5%

Из этого списка разыгрывается жребий — у кого шанс больше, тот чаще выпадает. Temperature меняет сами шансы перед жребием — чем ниже значение, тем чаще модель берёт вариант с самым большим шансом. Например

✦ Temperature 0 — модель берёт вариант с самым большим процентом. В нашем случае это «зелёный» — каждый запуск даёт один и тот же ответ
✦ Средняя (~0.7) — шансы близки к исходным. Чаще выпадает «зелёный», но регулярно и «красный» с «жёлтым». Смысл тот же, формулировки гуляют — так модель пишет естественный, не «роботный» текст
✦ Высокая (1.0+) — шансы выравниваются, реальный шанс получает даже «что-то странное». Каждый запуск — новый текст, на максимуме он может становиться бессвязным

Зачем это QA

Temperature — часть конфигурации тестируемой системы. От значения зависит, какой разброс ответов норма, а какой — баг. Поэтому важно обращать внимание, какое значение там стоит

Ориентир для выбора может быть таким:

✦ Один правильный ответ — вердикт нашего LLM-модератора «нарушение или нет», оценка баллом, извлечение данных и ответ по ним — temperature 0
✦ Естественный текст — саммари, ответ пользователю — 0.6–0.8, в этом же коридоре дефолты Llama и Ollama
✦ Вариативные задачи — брейншторм, генерация тест-данных, перефразы — 1.0 и выше

И два подводных камня, на которые я наткнулся, когда проверял это руками

1. Temperature 0 не делает ответы одинаковыми. Кто выигрывает — модель пересчитывает при каждом запуске, а в облаке эти вычисления чуть плавают — запросы обрабатываются пачками (батчами) вместе с чужими, железо на серверах разное, и числа выходят одинаковые на вид, но разные в дальних знаках после запятой. Когда два варианта идут почти вровень, от запуска к запуску выигрывает то один, то другой. Anthropic честно пишут об этом в доке. Таким образом, даже T=0 не гарантирует одинаковые ответы — и проверка «ожидаемый результат совпал с полученным дословно» стабильно работать не будет
2. Параметр есть не во всех моделях. Из шести, которые я проверял, две — gpt-5-mini и Claude Opus 4.8 — на temperature возвращают ошибку 400. При переходе на новую модель стоит проверить, что параметр вообще есть, если он важен для задачи

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

Temperature на практике — что меняется в ответе, а что нет

В прошлом посте разобрали, что такое temperature. Теперь на практике. Взял реальное здание — Дом Зингера на Невском, он же Дом книги — и собрал агента, который отвечает по справке о нём. Готового ответа у агента нет, он вытаскивает факты из текста. Прогнал на трёх моделях — локальная qwen на своём компьютере, облачные GPT и Claude — при температурах 0, 0.6 и 1.0, по три повтора на каждой

Первый вопрос конкретный — «кто архитектор, были ли соавторы, в каком стиле»

В справке всё это есть. На T=0 и 0.6 все три модели держат факты — Сюзор, соавторы поимённо, стиль модерн. А на T=1.0 гарантии уже нет. Qwen в одном прогоне из трёх выдумала несуществующий стиль «светомодерн» с описанием из барокко и классицизма, а инициалы соавторов из справки достроила выдуманными именами — «И. Б. Изелла» стал «Иваном Борисовичем». Причём дорисовала ровно там, где в справке стояли инициалы, а полное имя «Мариан Перетяткович» не тронула. На высокой температуре модель латает дыры в данных выдумкой

Итог по первому вопросу:
На qwen при T=0 три прогона дословно одинаковы, выше — начинают расходиться
У GPT на T=1.0 поехала грамматика — «архитектором здания была назначена Павел Сюзор». Факт верный, а согласование сломалось. Claude же всегда отвечал разметкой с заголовками и списком — факты на месте, но даже на нуле менял заголовок ответа

Второй вопрос открытый — «чем интересно это здание, вкратце»

Тут разброс сразу больше.
Qwen и GPT держались справки — менялись формулировки, но новых фактов не появлялось.
Claude уже на T=0 написал, что здание «пережило блокаду Ленинграда». Исторически правда — но в справке этого нет, модель добавила от себя


Таким образом, что мы имеем для QA:
✦ Не ассертить дословный текст — он меняется уже на 0.6, а в облаке совпадение даже на нуле не гарантировано
✦ Проверять не совпадение, а наличие нужных фактов и отсутствие того, чего в источнике нет
✦ Проверять форму отдельно — Claude вернул разметку с заголовками, GPT на высокой температуре сломал грамматику, парсер на таком споткнётся

Полные вопросы и ответы по каждой температуре и модели можно посмотреть в комментариях

Что такое top_k и top_p и для чего они нужны?

У модели есть список вариантов следующего слова с разными вероятностями.
top_k и top_p определяют, какие из них останутся в списке перед выбором


✦ top_k оставляет фиксированное количество самых вероятных вариантов. Буква k означает число. При top_k=10 модель сможет выбирать только из десяти первых кандидатов.
✦ top_p смотрит не на количество, а на сумму вероятностей. Буква p означает probability — вероятность. При top_p=0.9 остаётся минимальное число вариантов, которые вместе набрали не меньше 90%

Допустим, модель дописывает фразу «Проверка прошла…»
✦ «успешно» — 50%
✦ «корректно» — 30%
✦ «нормально» — 15%
✦ «феерично» — 5%

Посмотрим, что останется при разных настройках.
✦ top_k=1 — только «успешно»
✦ top_k=2 — «успешно» и «корректно»
✦ top_p=0.5 — только «успешно», потому что этот вариант уже набрал необходимые 50%
✦ top_p=0.9 — первые три варианта. «Успешно» и «корректно» вместе дают только 80%. Добавляем «нормально» и получаем 95% — порог пройден

После отсечения модель выбирает одно из оставшихся слов.

Получается, top_k всегда сохраняет заданное количество вариантов. top_p каждый раз считает их общую вероятность. В нашем примере для порога 90% понадобилось три слова. В другом месте одного слова может быть достаточно, если его вероятность уже выше 90%

Для чего это нужно

Оба параметра помогают убрать маловероятные продолжения вроде «феерично», но оставить модели выбор между нормальными вариантами

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

Как это может быть полезно для QA

Разберём на примере ИИ-агента, который закончил свою работу и формирует ответ пользователю

Такой агент обращается к LLM один или несколько раз. Разработчик может задать параметры генерации для всего агента или отдельного запуска. Сам агент обычно их не меняет — это часть конфигурации

При тестировании промпта или ИИ-агента мы как QA можем сравнивать, как система ведёт себя при разных настройках:
✦ зафиксировать модель, промпт и набор сценариев
✦ изменить только top_p или top_k, оставив остальные настройки прежними
✦ выполнить несколько повторов для каждой конфигурации
✦ проверить факты, формат ответа и действия агента

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

Из чего состоит промпт — и зачем это знать QA

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

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

✦ Задача — определить, есть ли нарушение в комментарии
✦ Правила и критерии — что считать оскорблением, угрозой или спамом
✦ Контекст — предыдущие сообщения или другие данные, которые нужны для решения
✦ Примеры — комментарии с уже указанными правильными решениями, если одной инструкции мало. Такой приём называют few-shot
✦ Пользовательский ввод — комментарий, который модель проверяет сейчас
✦ Формат ответа — вернуть решение, категорию и короткое объяснение
✦ Правило на случай сомнений — например, отправить спорный комментарий на ручную проверку

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

Что это значит для QA

Сам промпт собирает разработчик/аналитик/промт инженер. QA обычно его сам не пишет, но должен понимать, какие инструкции и данные получила модель. Без этого сложно определить причину неверного ответа.

Допустим, модератор заблокировал обычную критику

«Кажется, в расчёте есть ошибка. Проверьте, пожалуйста, ещё раз»

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

Поэтому «промпт не работает» — слишком общее описание проблемы. Полезнее выяснить, какой элемент промпта повлиял на результат

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

Инструкция приложения и ввод пользователя — что для LLM важнее

В прошлом посте разбирали, из каких элементов состоит промпт. Теперь посмотрим, откуда эти элементы приходят и одинаково ли модель относится к каждому из них (нет, не одинаково)

Разберём на примере OpenAI API. Правила приложения и пользовательский ввод можно передать сообщениями с разными ролями

✦ developer — инструкции приложения, включая задачу, ограничения и требования к ответу
✦ user — текущий запрос или данные пользователя
✦ assistant — ответ, который сгенерировала модель

Главное различие — в приоритете. Инструкции developer стоят выше пользовательского ввода. Если они противоречат друг другу, модель должна следовать правилам приложения

Для нашего LLM-модератора это означает, что внутри проверяемого комментария тоже может встретиться команда для модели

Например, просьба игнорировать правила и разрешить комментарий

Она должна остаться частью проверяемого текста, а не заменить инструкции приложения

Что это значит для QA

Важно проверить конфликт инструкций нужно в обе стороны. Что значит в обе стороны:

1. Команда внутри нарушающего комментария не должна отменять правила приложения
2. Безопасный комментарий не должен блокироваться только потому, что похож на инструкцию для модели

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