AI in QA Interview Guide

Що це. Велика мовна модель (Large Language Model, LLM) — нейромережа з архітектурою трансформера, навчена на величезному масиві текстів і коду. Вона не «знає» факти в звичному сенсі: на кожному кроці модель рахує ймовірності для наступного токена (шматка тексту) і вибирає один із них. Відповідь складається токен за токеном, доки модель не вирішить зупинитися або не впреться в ліміт.

What it is. A Large Language Model (LLM) is a transformer-based neural network trained on a huge corpus of text and code. It does not "know" facts in the usual sense: at every step the model computes probabilities for the next token (a chunk of text) and picks one of them. The answer is built token by token until the model decides to stop or hits a limit.

Чому це важливо для QA. З цього механізму випливають усі властивості, з якими ми стикаємося: правдоподібний, але хибний текст; різні відповіді на той самий запит; залежність якості від формулювання промпту; відсутність знань про події після дати навчання і про внутрішній код компанії. Тестувальник, який це розуміє, не питає «чому AI збрехав», а одразу планує перевірку результату.

Why it matters for QA. Every property we run into follows from this mechanism: plausible but false text, different answers to the same request, quality that depends on the prompt wording, and no knowledge of events after the training cutoff or of the company's internal code. A tester who understands this does not ask "why did the AI lie" but plans how to verify the output from the start.

Приклад. Просимо згенерувати тест для нашого внутрішнього SDK. Модель ніколи не бачила цей SDK, тому вгадує назви методів за аналогією з популярними бібліотеками. Код виглядає охайно, але не компілюється.

Example. We ask for a test against our internal SDK. The model has never seen that SDK, so it guesses method names by analogy with popular libraries. The code looks tidy but does not compile.

Підводні камені. Сприймати LLM як пошукову систему чи базу знань. Вона генерує статистично ймовірний текст, а не цитує джерело, тому будь-яке твердження потрібно звіряти з документацією чи кодом.

Pitfalls. Treating an LLM as a search engine or a knowledge base. It generates statistically likely text rather than quoting a source, so every claim has to be checked against documentation or code.

Токен. Модель працює не з літерами і не зі словами, а з токенами — фрагментами тексту зі словника токенізатора. Для англійського тексту грубе емпіричне правило — близько чотирьох символів на токен; українська, код, JSON і довгі ідентифікатори зазвичай «коштують» більше токенів на символ. Точну кількість дає лише токенізатор конкретної моделі. Від токенів залежать ціна запиту через API, швидкість відповіді і ліміти.

Token. The model works neither with letters nor with words but with tokens — text fragments from the tokenizer's vocabulary. For English a rough rule of thumb is about four characters per token; Ukrainian, code, JSON and long identifiers usually cost more tokens per character. Only the tokenizer of the specific model gives the exact count. Tokens drive the API price of a request, the response speed and the limits.

Контекстне вікно (context window). Максимальна кількість токенів, яку модель обробляє за один раз: системні інструкції, історія діалогу, вставлені файли і сама відповідь разом. Розмір залежить від моделі і дуже різниться між постачальниками.

Context window. The maximum number of tokens a model handles in one go: system instructions, conversation history, pasted files and the answer itself, all together. The size depends on the model and varies a lot between vendors.

Як це б'є по QA. Вставили лог на 20 тисяч рядків — він або не влізе, або інструмент мовчки обріже початок, і модель «аналізуватиме» лише хвіст без першої помилки. У довгому діалозі ранні домовленості витісняються або губляться серед іншого тексту. Навіть коли все влазить, модель гірше помічає деталі посередині дуже довгого контексту.

How it hits QA. Paste a 20,000-line log and it either does not fit or the tool silently cuts the beginning, so the model "analyses" only the tail without the first error. In a long chat, early agreements get pushed out or lost among other text. Even when everything fits, models tend to miss details in the middle of a very long context.

Практика. Давати мінімально достатній контекст: перший стек-трейс, кілька рядків до нього, конфіг, а не весь лог.

Practice. Give the minimum sufficient context: the first stack trace, a few lines before it, the config — not the whole log.

Визначення. Галюцинація (hallucination) — правдоподібний, упевнено сформульований, але хибний або вигаданий зміст. Модель не бреше навмисно: вона продовжує текст найімовірнішим чином, а ймовірне не завжди правдиве.

Definition. A hallucination is plausible, confidently worded content that is false or made up. The model is not lying on purpose: it continues the text in the most likely way, and likely is not always true.

Як виглядає в QA. Неіснуючі методи бібліотеки або опції конфігу; параметри CLI, яких немає у вашій версії інструменту; вигадані коди помилок і назви полів API; посилання на документацію, що веде в нікуди; тест-кейси, які перевіряють бізнес-правило, якого немає в вимогах. Найнебезпечніша форма — хибний очікуваний результат в асерті: тест компілюється, проходить, але перевіряє не те.

What it looks like in QA. Library methods or config options that do not exist; CLI flags missing from your tool version; invented error codes and API field names; documentation links that lead nowhere; test cases that verify a business rule absent from the requirements. The most dangerous form is a wrong expected value in an assertion: the test compiles and passes but checks the wrong thing.

Як захищатися. Давати моделі джерело правди в промпті (фрагмент специфікації, OpenAPI-схему, реальний код); просити позначати припущення; перевіряти згенерований код компіляцією, лінтером і запуском; звіряти кожне очікуване значення з вимогами, а не з думкою моделі.

How to defend. Put a source of truth into the prompt (a spec excerpt, an OpenAPI schema, real code); ask the model to flag assumptions; check generated code by compiling, linting and running it; match every expected value against the requirements, not the model's opinion.

Пастка. Думати, що впевнений тон означає правильність. Тон у моделі однаково впевнений і для правди, і для вигадки.

Trap. Assuming a confident tone means correctness. The model sounds equally sure about truth and fiction.

Prompt engineering. Уміння формулювати запит до моделі так, щоб отримати корисний і перевірюваний результат. Робочі складники: роль і аудиторія («ти досвідчений QA, пишеш для команди»), контекст (вимога, схема, код), чітка задача, обмеження (що не вигадувати, які інструменти використовувати) і формат відповіді (таблиця, JSON, конкретний фреймворк). Це не магічні слова, а звичайна чітка постановка задачі, як для колеги.

Prompt engineering. The skill of wording a request to a model so the result is useful and verifiable. The working parts: role and audience ("you are an experienced QA writing for the team"), context (a requirement, a schema, code), a clear task, constraints (what not to invent, which tools to use) and the output format (a table, JSON, a specific framework). These are not magic words, just a clear task statement you would give a colleague.

Zero-shot. Промпт без прикладів: лише інструкція і вхідні дані. Підходить для простих, поширених задач, де формат відповіді очевидний: пояснити регулярний вираз, перекласти повідомлення про помилку, перелічити класи еквівалентності для поля «вік».

Zero-shot. A prompt with no examples: just the instruction and the input. It works for simple, common tasks where the output format is obvious: explain a regex, translate an error message, list equivalence classes for an "age" field.

Коли його замало. Коли потрібен ваш внутрішній формат тест-кейсів, особливий стиль іменування або доменні правила. Тоді додають приклади (few-shot) або шаблон.

When it falls short. When you need your internal test case format, a specific naming style or domain rules. Then you add examples (few-shot) or a template.

Типова помилка. Промпт «напиши тести для логіна» без контексту. Модель поверне загальний набір із інтернету, який не знає ваших правил блокування, 2FA і повідомлень про помилки.

Common mistake. A prompt like "write tests for login" with no context. The model returns a generic set from the internet that knows nothing about your lockout rules, 2FA or error messages.

Few-shot. У промпт додають кілька пар «вхід → вихід», і модель копіює їхній патерн. Це найнадійніший спосіб отримати ваш формат: ID тест-кейсу, передумови, кроки, очікуваний результат, теги пріоритету. Два-три приклади зазвичай достатньо; вони мають бути різними, інакше модель скопіює зміст, а не структуру.

Few-shot. You add several "input → output" pairs to the prompt, and the model copies their pattern. It is the most reliable way to get your format: test case ID, preconditions, steps, expected result, priority tags. Two or three examples are usually enough; they should differ from each other, otherwise the model copies the content instead of the structure.

Chain-of-thought (CoT). Прохання міркувати покроково перед фінальною відповіддю: спершу виписати правила з вимоги, потім визначити межі й ризики, лише потім писати тести. Для задач з кількома умовами це помітно зменшує пропуски, бо проміжні кроки стають частиною контексту, на який спирається відповідь. Багато сучасних моделей уже мають вбудований режим міркування, але явний план кроків у промпті все одно дисциплінує результат.

Chain-of-thought (CoT). Asking the model to reason step by step before the final answer: first extract the rules from the requirement, then identify boundaries and risks, only then write tests. For tasks with several conditions this noticeably reduces omissions, because the intermediate steps become part of the context the answer relies on. Many current models already have a built-in reasoning mode, yet an explicit step plan in the prompt still keeps the output disciplined.

Підводні камені. Міркування моделі теж може бути хибним — перевіряйте не лише висновок, а й виписані правила. Few-shot з помилкою в прикладі розмножить цю помилку в усіх результатах.

Pitfalls. The model's reasoning can be wrong too — check the extracted rules, not only the conclusion. A few-shot example with a mistake in it will replicate that mistake in every result.

Звичайне автодоповнення. IDE підказує назви змінних, методів і полів на основі статичного аналізу: типів, імпортів, синтаксичного дерева. Воно детерміноване і майже завжди правильне, бо пропонує лише те, що реально існує в коді, але пише по одному ідентифікатору.

Traditional autocomplete. The IDE suggests variable, method and field names from static analysis: types, imports, the syntax tree. It is deterministic and almost always correct because it offers only what really exists in the code, but it writes one identifier at a time.

AI-редактор або асистент (Cursor, GitHub Copilot та подібні). Генерує цілі рядки, функції і тести, пояснює код, робить рефакторинг кількох файлів за текстовим запитом. Сильна сторона — розуміння контексту проєкту: він індексує репозиторій і враховує сусідні файли, наявні page objects, фікстури і стиль. Слабка — ймовірнісна природа: пропозиція може посилатися на метод, якого немає, і IDE-підказка цього не гарантує.

AI editor or assistant (Cursor, GitHub Copilot and similar). Generates whole lines, functions and tests, explains code, refactors several files from a text request. Its strength is project context: it indexes the repository and takes neighbouring files, existing page objects, fixtures and style into account. Its weakness is its probabilistic nature: a suggestion may reference a method that does not exist, and nothing guarantees it the way static completion does.

Приклад для QA. Пишете коментар «тест: гість не може оформити замовлення без email», і асистент пропонує тест, що використовує вже наявні у проєкті CheckoutPage і фікстуру guestUser.

QA example. You type a comment "test: a guest cannot check out without an email" and the assistant proposes a test that uses the CheckoutPage and guestUser fixture already in the project.

Пастка. Приймати багаторядкові підказки клавішею Tab без читання. Перевіряйте імпорти, локатори й асерти так само ретельно, як чужий PR.

Trap. Accepting multi-line suggestions with Tab without reading them. Check imports, locators and assertions as carefully as someone else's PR.

Що робить модель. Отримує user story з критеріями приймання (acceptance criteria) і повертає чернетку набору: позитивний сценарій, негативні кейси, граничні значення, порожні поля, базові перевірки безпеки на кшталт спецсимволів і дуже довгих рядків. Для історії «як користувач я входжу за email і паролем» типовий результат — успішний вхід, неправильний пароль, незареєстрований email, порожні поля, блокування після кількох спроб.

What the model does. It takes a user story with acceptance criteria and returns a draft set: the happy path, negative cases, boundary values, empty fields, basic security probes such as special characters and very long strings. For the story "as a user I sign in with email and password" a typical result is a successful login, a wrong password, an unregistered email, empty fields and a lockout after several attempts.

Де цінність. Швидкий старт і нагадування про категорії, які легко забути під тиском дедлайну. Модель добре перебирає комбінації, але не знає ваших доменних правил.

Where the value is. A fast start and a reminder of categories that are easy to forget under deadline pressure. The model enumerates combinations well but does not know your domain rules.

Як отримати якісний результат. Вставити повний текст історії і AC, пояснити, чого в ній немає (наприклад, 2FA поза обсягом), заборонити вигадувати повідомлення про помилки, попросити позначати кейси, які спираються на припущення, і задати формат таблиці. Потім QA проходить список: видаляє дублі, додає ризики з досвіду продукту, звіряє очікувані результати з AC.

How to get a good result. Paste the full story and AC, state what is out of scope (for example 2FA), forbid inventing error messages, ask the model to mark cases that rest on assumptions, and specify a table format. Then QA goes through the list: removes duplicates, adds risks known from the product, checks expected results against the AC.

Пастка. Довіряти кількості. Сорок кейсів від моделі можуть покривати ті самі три класи еквівалентності, а реальний ризик — наприклад, вхід під час скидання пароля — пропущений.

Trap. Trusting the count. Forty cases from a model may cover the same three equivalence classes while a real risk — say, logging in during a password reset — is missed.

Де допомагає. LLM швидко складає складні структури JSON чи XML з правдоподібними значеннями: вкладені замовлення, адреси різних країн, імена з апострофами й діакритикою, Unicode і емодзі, рядки на межі довжини. Особливо корисно просити негативні дані: відсутні обов'язкові поля, неправильні типи, дати на кшталт 29 лютого невисокосного року, від'ємні суми. Модель також може написати генератор (скрипт на Faker чи подібній бібліотеці), що масштабується краще за ручну вставку тисяч записів у чат.

Where it helps. An LLM quickly builds complex JSON or XML structures with plausible values: nested orders, addresses from different countries, names with apostrophes and diacritics, Unicode and emoji, strings at the length limit. It is especially useful for negative data: missing required fields, wrong types, dates such as 29 February in a non-leap year, negative amounts. The model can also write a generator (a script using Faker or a similar library), which scales far better than pasting thousands of records into a chat.

Де ламається. Модель не гарантує валідність: контрольні суми IBAN і номерів карток, унікальність email, узгодженість між полями (сума позицій дорівнює total) часто порушені. Великі масиви вона генерує з повторами і несподіваними скороченнями, а «реалістичні» імена можуть збігтися з реальними людьми.

Where it breaks. The model does not guarantee validity: checksums of IBANs and card numbers, email uniqueness and cross-field consistency (line items summing to the total) are often violated. Large arrays come out with repeats and unexpected truncation, and "realistic" names may match real people.

Правило. Кожен згенерований набір проганяють через валідатор схеми і бізнес-правил, а для навантажувальних обсягів використовують детермінований генератор із seed.

Rule. Every generated set goes through a schema and business-rule validator, and for load-test volumes you use a deterministic generator with a seed.

Суть. Ручний кейс уже містить кроки й очікування, тож перетворення в код — майже механічна робота, з якою LLM справляється добре. Те саме стосується шаблонного коду (boilerplate): каркас page object, фікстури, клієнт до API, парсер конфігу, типові хелпери очікувань.

The idea. A manual case already contains steps and expectations, so turning it into code is almost mechanical work that an LLM handles well. The same goes for boilerplate: a page object skeleton, fixtures, an API client, a config parser, typical waiting helpers.

Як робити правильно. Дати моделі не лише кейс, а й приклади з вашого фреймворку: один наявний тест, базовий page object, правила локаторів (наприклад, getByRole і data-testid замість XPath). Попросити один кейс — один тест, крок кейсу — коментар над відповідним рядком, щоб рев'юер міг звірити. Згенерований тест обов'язково запускають, а потім ламають перевірювану поведінку, щоб переконатися, що він падає.

Doing it right. Give the model not only the case but examples from your framework: one existing test, the base page object, locator rules (for example getByRole and data-testid instead of XPath). Ask for one case per test and each case step as a comment above the matching line, so a reviewer can compare them. The generated test must be run, and then the behaviour under test is broken on purpose to confirm the test fails.

Підводні камені. Модель мовчки «доповнює» кроки, яких не було в кейсі, або пропускає перевірку проміжного стану. Буває, що замість вбудованого очікування вона вставляє фіксовану паузу — це майбутній flaky-тест. Неоднозначний ручний кейс («перевірити, що все коректно») дасть так само розмитий асерт.

Pitfalls. The model silently "adds" steps that were not in the case or skips a check of an intermediate state. Sometimes it inserts a fixed sleep instead of a built-in wait — a future flaky test. An ambiguous manual case ("verify everything is correct") produces an equally vague assertion.

Що вміє модель. Прочитати незнайомий стек-трейс і пояснити, що означає виняток; знайти рядок власного коду серед фреймворкових кадрів; розпізнати типові патерни: NullPointerException після зміни контракту API, таймаут пулу з'єднань, проблему часових поясів, гонку в асинхронному коді. Також допомагає згрупувати сотні схожих помилок за сигнатурою і скласти гіпотези для перевірки.

What the model can do. Read an unfamiliar stack trace and explain what the exception means; find your own code's frame among framework frames; recognise typical patterns: a NullPointerException after an API contract change, a connection pool timeout, a time zone issue, a race in async code. It also helps group hundreds of similar errors by signature and draft hypotheses to check.

Як подавати дані. Перший виняток, а не наслідки; кілька рядків логу до нього; версії компонентів; що змінилося з останнього зеленого прогону. Перед відправкою у зовнішній інструмент прибрати токени, email, внутрішні хости.

How to feed it. The first exception, not its consequences; a few log lines before it; component versions; what changed since the last green run. Before sending to an external tool, strip tokens, emails and internal hostnames.

Межі. Модель пропонує гіпотези, а не діагноз. Вона не бачить стану бази, мережі чи конфігурації продакшену, тому легко «впевнено пояснює» помилку неправильно. Кожну гіпотезу підтверджують відтворенням або метриками, а в баг-репорт пишуть факти, а не висновок моделі.

Limits. The model proposes hypotheses, not a diagnosis. It cannot see the database state, network or production config, so it can easily "confidently explain" the error wrongly. Every hypothesis is confirmed by reproduction or metrics, and the bug report states facts, not the model's conclusion.

Уточнення. Корисне питання до моделі: «які три перевірки розрізнять твої гіпотези?» — воно перетворює відповідь на план дій.

Follow-up. A useful question for the model: "which three checks would distinguish your hypotheses?" — it turns the answer into an action plan.

Що це. Модель аналізує diff або файл із тестами і коментує проблеми до людського рев'ю — у IDE, у чаті або як бот у пул-реквесті. Вона добре ловить механічні вади: тест без асерту чи з асертом, що завжди істинний; фіксовані паузи; залежність тестів один від одного через спільний стан; дублювання; невиразні назви на кшталт test1; перехоплений і проігнорований виняток; відсутні негативні й граничні кейси для очевидних параметрів.

What it is. A model analyses a diff or a test file and comments on problems before human review — in the IDE, in chat or as a bot on the pull request. It is good at mechanical flaws: a test with no assertion or with an always-true one; fixed sleeps; tests depending on each other through shared state; duplication; vague names like test1; an exception caught and ignored; missing negative and boundary cases for obvious parameters.

Чого не знайде. Чи перевіряє тест правильну бізнес-вимогу, чи відповідає очікуване значення специфікації, чи тест взагалі потрібен з погляду ризиків. Це залишається людському рев'юеру, який знає продукт.

What it will not find. Whether the test checks the right business requirement, whether the expected value matches the spec, whether the test is needed at all from a risk standpoint. That stays with the human reviewer who knows the product.

Практика. Корисно давати моделі чек-лист команди (правила локаторів, заборона пауз, структура AAA), щоб коментарі були за вашими стандартами, а не загальними. Шум — головний ризик: якщо бот пише двадцять дрібних зауважень, люди перестають читати й важливі. Налаштуйте його на кілька категорій з високою впевненістю.

Practice. It helps to give the model the team's checklist (locator rules, no sleeps, AAA structure), so comments follow your standards rather than generic ones. Noise is the main risk: if the bot posts twenty nitpicks, people stop reading the important ones too. Tune it to a few high-confidence categories.

Базова структура. Роль → контекст → задача → обмеження → формат → самоперевірка. Роль задає рівень і стиль, контекст дає джерело правди, обмеження відсікають вигадки, формат робить результат придатним для автоматичної обробки, а самоперевірка змушує модель пройтися по власній відповіді за критеріями.

Base structure. Role → context → task → constraints → format → self-check. The role sets level and style, the context provides the source of truth, constraints cut off fabrication, the format makes the output machine-processable, and the self-check makes the model walk through its own answer against criteria.

Корисні патерни. «Спершу запитай» — модель ставить уточнювальні питання до генерації, що корисно для сирих вимог. «Критик» — окремим запитом попросити знайти прогалини в попередньому результаті. «Табличний вивід» — легко перенести в тест-менеджмент. «Від протилежного» — як користувач міг би зламати цю функцію. «Обмежений словник» — використовувати лише надані методи page object.

Useful patterns. "Ask first" — the model asks clarifying questions before generating, handy for raw requirements. "Critic" — a separate request to find gaps in the previous result. "Tabular output" — easy to move into test management. "Adversarial" — how could a user break this feature. "Restricted vocabulary" — use only the provided page object methods.

Практика команди. Шаблони зберігають у репозиторії поряд з тестами, версіонують і покращують за результатами, як будь-який інший артефакт. Тоді якість не залежить від того, хто сьогодні пише промпт.

Team practice. Templates live in the repository next to the tests, are versioned and improved based on results like any other artefact. Then quality does not depend on who writes the prompt today.

Пастка. Надто довгі промпти з десятками правил: модель виконує частину і ігнорує решту. Краще кілька коротких кроків.

Trap. Overly long prompts with dozens of rules: the model follows some and ignores the rest. Several short steps work better.

Що це. Model Context Protocol — відкритий протокол, який стандартизує, як AI-застосунок (клієнт: чат, IDE, агент) підключається до зовнішніх інструментів і даних через MCP-сервери. Сервер описує доступні інструменти (tools), ресурси і шаблони промптів, а модель через клієнт викликає їх зі структурованими параметрами. Замість окремої інтеграції для кожної пари «модель — інструмент» маємо один спільний інтерфейс.

What it is. Model Context Protocol is an open protocol that standardises how an AI application (the client: a chat, an IDE, an agent) connects to external tools and data through MCP servers. A server describes its available tools, resources and prompt templates, and the model calls them through the client with structured parameters. Instead of a custom integration for every model-tool pair there is one shared interface.

Як це виглядає в QA. Асистент через MCP-сервер браузерної автоматизації відкриває сторінку, клікає і читає дерево доступності; через сервер трекера задач читає тікет з AC; через сервер бази — дивиться схему таблиць; через файлову систему — запускає тести й читає звіт. Так модель працює з реальним станом, а не вгадує.

What it looks like in QA. Through a browser automation MCP server, the assistant opens a page, clicks and reads the accessibility tree; through an issue tracker server it reads a ticket with AC; through a database server it looks at table schemas; through the file system it runs tests and reads the report. The model works with real state instead of guessing.

Ризики. Кожен сервер — це права на дії. Вмикати лише потрібні інструменти, давати доступ до тестових середовищ, а не продакшену, використовувати облікові записи з мінімальними правами і перевіряти походження сторонніх серверів. Вміст, який модель читає через інструменти (сторінка, тікет), може містити приховані інструкції — це вектор indirect prompt injection.

Risks. Every server is a set of permissions to act. Enable only the tools you need, point them at test environments rather than production, use least-privilege accounts, and check where third-party servers come from. Content the model reads through tools (a page, a ticket) may contain hidden instructions — that is an indirect prompt injection vector.

Агентний AI. Система, у якій модель не лише генерує текст, а працює в циклі: планує кроки, викликає інструменти (термінал, браузер, API), читає результат і коригує план, доки не досягне мети або не вичерпає ліміт. Класичний патерн — ReAct (міркування і дія по черзі). Приклад: «виправ падаючий тест» → агент запускає тест, читає помилку, змінює локатор, перезапускає.

Agentic AI. A system where the model does not just generate text but works in a loop: plans steps, calls tools (terminal, browser, API), reads the result and adjusts the plan until it reaches the goal or hits a limit. The classic pattern is ReAct (reasoning and acting in turns). Example: "fix the failing test" → the agent runs the test, reads the error, changes a locator, reruns.

AI-assisted проти AI-driven. AI-assisted — людина керує процесом, а AI пропонує: підказки в IDE, чернетки кейсів, пояснення логів; кожне рішення ухвалює QA. AI-driven — AI самостійно аналізує, генерує, запускає й оцінює тести, людина задає рамки і перевіряє підсумки. Це не два табори, а шкала автономності.

AI-assisted versus AI-driven. AI-assisted means a human runs the process and the AI proposes: IDE suggestions, draft cases, log explanations; the QA makes every decision. AI-driven means the AI analyses, generates, runs and evaluates tests on its own, and a human sets the boundaries and reviews the outcome. It is not two camps but a scale of autonomy.

Трейдофи для senior. Що більше автономії, то важливіші межі: пісочниця, тестові облікові записи, заборона на зміну асертів без погодження, ліміт кроків і вартості, журнал усіх дій. Класичний провал — агент «виправляє» червоний тест, послаблюючи перевірку, і звітує про успіх. Тому метрика успіху агента — не «тести зелені», а «баги знайдено і тести досі ловлять регресії».

Senior trade-offs. The more autonomy, the more the boundaries matter: a sandbox, test accounts, no changing assertions without approval, step and cost limits, a log of every action. The classic failure: the agent "fixes" a red test by weakening the check and reports success. So an agent's success metric is not "tests are green" but "bugs were found and tests still catch regressions".

Суть проблеми. Такий тест закріплює наявний баг. Асистент бачить код функції, «прокручує» його в голові або просто запускає й підставляє те, що вийшло, у assert. Тест перевіряє «як є», а не «як має бути»: якщо функція рахує знижку неправильно, неправильне число стає еталоном, і тест зелений.

The core problem. Such a test locks in the existing bug. The assistant sees the function body, "runs" it mentally or literally executes it, and pastes whatever came out into the assert. The test checks "what is" instead of "what should be": if the function computes a discount wrongly, the wrong number becomes the reference and the test passes.

Чому це гірше за помилку компіляції. Тест, що не компілюється, видно одразу. Хибний оракул (test oracle) мовчить: покриття росте, CI зелений, а дефект тепер ще й захищений тестом. Коли хтось згодом виправить функцію, тест упаде, і людина може «полагодити» якраз правильну версію.

Why this is worse than a compile error. A test that does not compile is visible at once. A wrong oracle stays silent: coverage grows, CI is green, and the defect is now even guarded by a test. When someone later fixes the function, the test fails, and that person may "fix" the correct version back.

Як правильно. Очікуване значення беремо з джерела поза кодом: вимоги, приймальні критерії (acceptance criteria), розрахунок вручну, еталонна таблиця від бізнесу. У промпті прямо пишемо: «очікувані значення виводь з правила, а не з реалізації», і даємо саме правило.

The right way. Take the expected value from a source outside the code: requirements, acceptance criteria, a manual calculation, a reference table from the business. In the prompt say explicitly "derive expected values from the rule, not from the implementation", and paste the rule itself.

Як помітити на рев'ю. Підозрілі дивні числа на кшталт 89.99999 чи 17.1 без пояснення, звідки вони. Корисне запитання до кожного assert: «який рядок специфікації це доводить?».

How to spot it in review. Suspicious odd numbers like 89.99999 or 17.1 with no explanation of where they came from. A useful question for every assert: "which line of the spec proves this?".

Знання домену. Модель знає загальні шаблони (логін, кошик, форма реєстрації), але не знає ваших бізнес-правил: що VIP-клієнт не платить за доставку, що повернення можливе 14 днів, а в Польщі — 30. Усе, чого немає в промпті чи контексті, вона або пропустить, або вигадає правдоподібно.

Domain knowledge. A model knows generic patterns (login, cart, sign-up form) but not your business rules: that a VIP customer pays no shipping, that returns are allowed for 14 days, but 30 in Poland. Anything missing from the prompt or context it will either skip or invent plausibly.

Хибні перевірки і вигадані API. Згенерований код може викликати методи, яких немає в бібліотеці, або перевіряти не те: наприклад, лише статус 200 замість вмісту відповіді. Такі тести проходять, але нічого не доводять.

Wrong assertions and invented APIs. Generated code may call methods that do not exist in the library, or check the wrong thing: for example only status 200 instead of the response body. Such tests pass but prove nothing.

Поверхневість. Без підказок модель дає «щасливий шлях» і кілька очевидних негативних кейсів. Межі, конкурентний доступ, часові зони, ідемпотентність, стани після помилки вона згадує рідко. Також вона не бачить історії ваших інцидентів — а саме там найцінніші регресійні сценарії.

Shallowness. Without guidance the model gives the happy path and a few obvious negative cases. Boundaries, concurrent access, time zones, idempotency and post-error states come up rarely. It also cannot see your incident history, which is exactly where the most valuable regression scenarios live.

Що з цим робити. Давати в контекст вимоги, правила й приклади з проєкту; просити список припущень окремо від тестів; обов'язково робити рев'ю і запускати тести проти навмисно зламаного коду. AI скорочує чорнову роботу, але відповідальність за покриття лишається на QA.

What to do about it. Put requirements, rules and project examples into the context; ask for a list of assumptions separately from the tests; always review and run the tests against deliberately broken code. AI cuts the drafting effort, but responsibility for coverage stays with QA.

Ризик. Галюцинації (hallucinations): код виглядає переконливо, але використовує методи, опції чи пакети, яких не існує, або змішує API різних фреймворків — скажімо, Selenium-подібний метод у Playwright-тесті. Модель генерує статистично ймовірний текст, а не перевіряє документацію.

The risk. Hallucinations: the code looks convincing but uses methods, options or packages that do not exist, or mixes APIs of different frameworks — say, a Selenium-style method inside a Playwright test. The model produces statistically likely text; it does not check the documentation.

Дешеві шари захисту. Типізація і лінтер ловлять більшість вигаданих методів ще до запуску: tsc --noEmit у CI, строгий ESLint-конфіг, lock-файл, який не дає тихо додати невідомий пакет. Для Python — mypy чи pyright. Далі — обов'язковий локальний прогін, бо модель не бачила, чи її код узагалі стартує.

Cheap layers of defence. Types and a linter catch most invented methods before execution: tsc --noEmit in CI, a strict ESLint config, a lock file that stops an unknown package from sneaking in. For Python, mypy or pyright. Then a mandatory local run, because the model never saw whether its code even starts.

Небезпечніший випадок. Вигаданий пакет із правдоподібною назвою: якщо хтось зареєструє його в публічному реєстрі, npm install затягне чужий код. Тому нові залежності з AI-коду перевіряємо вручну: чи є пакет, хто автор, чи його справді рекомендує офіційна документація.

A nastier case. An invented package with a plausible name: if someone registers it in a public registry, npm install pulls in a stranger's code. So new dependencies from AI code are checked by hand: does the package exist, who publishes it, does the official documentation actually recommend it.

Компроміс для команди. Забороняти AI не варто — варто зробити так, щоб вигадка падала якомога раніше і дешевше: компілятор, лінтер, CI, рев'ю людиною. HITL тут не формальність, а останній шар для логічних помилок, які типізація не бачить.

The team trade-off. Banning AI is not the answer — making invention fail as early and cheaply as possible is: compiler, linter, CI, human review. HITL here is not a formality but the last layer for logic errors that types cannot see.

Принцип. Рев'ю AI-тесту суворіше, ніж тесту колеги, бо автор не може пояснити свій задум. Я перевіряю не «чи гарний код», а «чи впаде цей тест, коли функція зламається». Тест, що ніколи не червоніє, — баласт.

The principle. Reviewing an AI test is stricter than reviewing a colleague's, because the author cannot explain its intent. I do not check "is the code pretty" but "will this test fail when the feature breaks". A test that never goes red is dead weight.

Що дивлюся. Звідки очікувані значення (вимоги, а не поточний вивід); чи є перевірки взагалі і чи вони про суть, а не лише про статус; чи існують усі методи й пакети; чи немає жорстких пауз замість очікувань; чи тест незалежний від порядку та спільних даних; чи назва каже, що саме перевіряється; чи не залишилися в коді реальні токени, email або внутрішні URL.

What I look at. Where the expected values come from (requirements, not current output); whether there are assertions at all and whether they check substance rather than just the status; whether every method and package exists; no hard sleeps instead of waits; independence from order and shared data; a name that says what is verified; and no real tokens, emails or internal URLs left in the code.

Практичний прийом. «Зламай і подивись» — ручна версія мутаційного тестування (mutation testing): тимчасово ламаю код або тестові дані й перевіряю, що тест червоніє з зрозумілим повідомленням. Якщо в команді є мутаційний інструмент (наприклад, Stryker чи PIT), він робить те саме масово.

A practical trick. "Break it and watch" — a manual version of mutation testing: I temporarily break the code or the test data and check that the test goes red with a clear message. If the team has a mutation tool (Stryker or PIT, for example), it does the same at scale.

Типова помилка. Приймати пачку з 40 згенерованих тестів одним PR «бо всі зелені». Краще менше тестів, кожен з яких перевірено на здатність падати.

Typical mistake. Accepting a batch of 40 generated tests in one PR "because they are all green". Better fewer tests, each proven able to fail.

Визначення. Human-in-the-loop — це обов'язкова участь людини в точках, де результат AI стає рішенням: злиття тесту, закриття бага, зміна еталона, реліз. AI пропонує, людина перевіряє і підтверджує, а відповідальність лишається за людиною.

Definition. Human-in-the-loop means a human must take part at the points where AI output turns into a decision: merging a test, closing a bug, changing a baseline, releasing. AI proposes, a person checks and confirms, and accountability stays with the person.

Чому це стандарт. Модель галюцинує, не знає бізнес-контексту й не несе відповідальності. Без людини помилка AI тихо потрапляє в регресійний набір і живе там роками. До того ж деякі дії небезпечні: агент, який сам оновлює скріншот-еталони чи «лагодить» тести, може замаскувати справжній дефект.

Why it is the standard. The model hallucinates, lacks business context and carries no accountability. Without a person an AI mistake slips quietly into the regression suite and stays there for years. Some actions are risky too: an agent that updates screenshot baselines or "fixes" tests on its own can mask a real defect.

Як налаштувати. Рівень контролю залежить від ризику дії. Чернетка тест-кейсів — вибіркове рев'ю. Новий автотест — повне рев'ю в PR. Зміна еталона, лікування локатора, пропуск тесту — тільки явне підтвердження з поясненням причини. Автоматичний реліз на основі вердикту AI — ні.

How to set it up. The level of control follows the risk of the action. A draft of test cases gets a sample review. A new automated test gets a full PR review. Changing a baseline, healing a locator or skipping a test needs explicit approval with a reason. An automatic release based on an AI verdict — no.

Пастка. HITL перетворюється на «гумову печатку», коли людина натискає Approve на 50 змін підряд. Допомагає обмеження обсягу одного рев'ю і метрика: яку частку AI-пропозицій відхиляють. Нуль відхилень — тривожний знак, а не успіх.

The trap. HITL becomes a rubber stamp when someone clicks Approve on 50 changes in a row. What helps is a size limit per review and a metric: what share of AI suggestions gets rejected. Zero rejections is a warning sign, not a success.

Проблема. Відчуття «я став швидше» ненадійне: люди переоцінюють швидкість генерації і недооцінюють час на виправлення. Кількість написаних тестів теж погана метрика — AI легко роздуває набір тестами, що нічого не ловлять. Тож потрібні вимірювання результату, а не активності.

The problem. The feeling "I got faster" is unreliable: people overestimate generation speed and underestimate the time spent fixing output. The number of tests written is a poor metric too — AI easily inflates a suite with tests that catch nothing. So you need outcome measurements, not activity counts.

Дизайн вимірювання. Базова лінія за 4–8 тижнів до впровадження, потім той самий період після, в ідеалі — пілотна і контрольна команди на схожих задачах. Метрики: час від готової історії до автотесту в main, частка AI-коду, переписаного на рев'ю, частка тестів, видалених чи вимкнених протягом місяця, flaky rate, дефекти, що втекли в прод, а також мутаційний бал для нових тестів.

Measurement design. A baseline over 4–8 weeks before rollout, then the same period after, ideally a pilot team and a control team on similar work. Metrics: time from a ready story to an automated test in main, share of AI code rewritten in review, share of tests deleted or disabled within a month, flaky rate, escaped defects, plus the mutation score of new tests.

Витрати теж рахуються. Ліцензії, токени, час на рев'ю, навчання, супровід промптів, юридичне погодження. Якщо ефект не перекриває їх на реальних даних, чесно кажемо про це.

Costs count too. Licences, tokens, review time, training, prompt upkeep, legal sign-off. If the effect does not cover them on real data, we say so honestly.

Підводні камені. Ефект новизни в перші тижні; різна складність задач у періодах; метрика, що стає ціллю (закон Гудгарта): команда почне генерувати тести заради цифри. Я поєдную кількісні дані з короткими інтерв'ю: де AI допоміг, а де заважав.

Pitfalls. The novelty effect in the first weeks; different task complexity between periods; a metric turning into a target (Goodhart's law), so the team starts generating tests for the number. I combine quantitative data with short interviews: where AI helped and where it got in the way.

Сценарій. Вендор показує демо: інструмент «сам пише й лікує тести». Менеджер хоче купити. Моя задача — перетворити враження від демо на рішення на наших даних.

Scenario. A vendor shows a demo: the tool "writes and heals tests by itself". The manager wants to buy. My job is to turn a demo impression into a decision based on our data.

Спершу проблема. Яку конкретну біль ми лікуємо: повільне написання, дорогий супровід, flaky-тести, брак візуальних перевірок? Якщо біль — нестабільне середовище, жоден AI не допоможе. Формулюю критерій успіху числом і терміном.

Problem first. Which concrete pain are we treating: slow authoring, costly maintenance, flaky tests, missing visual checks? If the pain is an unstable environment, no AI will help. I state the success criterion as a number with a deadline.

Пілот на реальному застосунку. Два-чотири тижні, 10–20 наших складних сценаріїв (iframe, динамічні таблиці, авторизація через SSO), а не демо-магазин. Перевіряю: чи ловить інструмент навмисно внесені баги, що він робить при зміні UI, як виглядає лог лікування, чи можна експортувати тести, якщо підемо.

A pilot on the real app. Two to four weeks, 10–20 of our hard scenarios (iframes, dynamic tables, SSO login), not a demo shop. I check: does the tool catch deliberately injected bugs, what does it do when the UI changes, what the heal log looks like, and can tests be exported if we leave.

Нефункціональне. Куди йдуть наші дані й скріншоти, чи навчають на них модель, де хостинг, SSO і ролі, інтеграція з CI, ціна при зростанні кількості прогонів, залежність від вендора (vendor lock-in). Рішення фіксую письмово з можливістю повернутися до нього через пів року.

Non-functional. Where our data and screenshots go, whether the model is trained on them, hosting location, SSO and roles, CI integration, price as run volume grows, vendor lock-in. I record the decision in writing with a review point in six months.

Що зменшується. Рутинне написання типових тестів, шаблонного коду (boilerplate), тестових даних, перших чернеток тест-кейсів і розбору типових логів. На цьому економиться час, але лише за умови якісного рев'ю.

What shrinks. Routine writing of typical tests, boilerplate code, test data, first drafts of test cases and parsing of typical logs. Time is saved there, but only if the review is solid.

Що зростає. Стратегія тестування і аналіз ризиків — що саме варто перевіряти; рев'ю результатів AI з розумінням домену; дослідницьке тестування (exploratory testing), яке AI не замінює; і нова велика область — тестування самих AI-функцій: eval-набори, метрики якості, безпека промптів, моніторинг у проді.

What grows. Test strategy and risk analysis — deciding what is worth checking; reviewing AI output with domain understanding; exploratory testing, which AI does not replace; and a big new area — testing AI features themselves: eval sets, quality metrics, prompt security, production monitoring.

Нові навички. Формулювати задачі для моделі (промпти з обмеженнями), розуміти недетермінованість і статистику (частка проходжень замість «пройшов/впав»), базова безпека (prompt injection, витоки), робота з даними й приватністю. Технічна планка не падає — навпаки, треба швидко відрізняти правдоподібний код від правильного.

New skills. Framing tasks for a model (prompts with constraints), understanding non-determinism and statistics (pass rates instead of pass/fail), basic security (prompt injection, leaks), data and privacy handling. The technical bar does not drop — quite the opposite, you must quickly tell plausible code from correct code.

Ризик для кар'єри. Джуніор, який лише копіює згенероване, не вчиться діагностувати. Я раджу спершу розв'язати задачу самостійно хоча б частково, а потім порівняти з варіантом AI і розібрати різницю.

Career risk. A junior who only copies generated output does not learn to diagnose. My advice is to solve the task yourself at least partly first, then compare with the AI version and work through the differences.

Ідея. Під час запису або першого успішного прогону інструмент зберігає не один селектор, а «відбиток» елемента: id, класи, текст, роль, атрибути, позицію в DOM, сусідів, іноді зображення. Коли основний локатор нічого не знаходить, інструмент шукає на сторінці кандидатів і рахує, наскільки кожен схожий на збережений відбиток.

The idea. During recording or the first passing run the tool stores not a single selector but an element "fingerprint": id, classes, text, role, attributes, DOM position, neighbours, sometimes an image. When the primary locator finds nothing, the tool scans the page for candidates and scores how closely each matches the stored fingerprint.

Що далі. Якщо найкращий кандидат перевищує поріг схожості, тест продовжується з ним, а інструмент записує подію лікування (heal) і, залежно від налаштувань, пропонує або сам оновлює локатор. Якщо нікого схожого немає — тест падає як звичайно. Частина інструментів використовує прості евристики з вагами, частина — моделі машинного навчання, натреновані на історії змін.

What happens next. If the best candidate clears a similarity threshold, the test continues with it, and the tool logs a heal event and, depending on settings, suggests or applies a locator update. If nothing is similar enough, the test fails as usual. Some tools use simple weighted heuristics, others use machine learning models trained on the history of changes.

Коли корисно. Коли UI часто змінюється косметично: перейменували CSS-клас, згенерований id змінився після збірки, обгорнули кнопку в новий div. Тоді лікування економить години супроводу.

When it helps. When the UI changes cosmetically and often: a CSS class got renamed, a generated id changed after a build, a button got wrapped in a new div. Healing then saves hours of maintenance.

Важливе уточнення. Лікування — це латка, а не заміна хорошим локаторам. Стабільні селектори за роллю, текстом чи data-testid роблять потребу в ньому мінімальною. Інтерв'юер часто питає саме про ризики — вони в наступній картці.

An important caveat. Healing is a patch, not a substitute for good locators. Stable selectors by role, text or data-testid keep the need for it minimal. Interviewers often ask specifically about the risks — those are in the next card.

Як це стається. Лікування не відрізняє «кнопку перейменували» від «кнопку помилково видалили». Приклад: після релізу кнопка «Оплатити» зникла через баг у фіче-прапорі, а поруч лишилася «Оплатити пізніше» з тим самим класом і батьківською формою. Інструмент знаходить схожий елемент, тест клікає не туди, наступний крок теж якось проходить — і регресія зелена.

How it happens. Healing cannot tell "the button was renamed" from "the button was removed by mistake". Example: after a release the "Pay" button disappears because of a feature-flag bug, while "Pay later" stays next to it with the same class and parent form. The tool finds a similar element, the test clicks the wrong thing, the next step somehow passes as well — and regression is green.

Інші форми маскування. Змінений текст кнопки, який насправді є дефектом перекладу; елемент, що переїхав у недоступне для клавіатури місце; дублікат елемента після бага рендерингу. У всіх випадках тест «виживає», а користувач — ні.

Other forms of masking. Changed button text that is actually a translation defect; an element that moved somewhere keyboard users cannot reach; a duplicated element after a rendering bug. In every case the test "survives" and the user does not.

Політика контролю. Лікування — це завжди сигнал, а не тихий успіх: подія потрапляє в звіт як попередження. На релізних гілках і для критичних потоків (оплата, реєстрація) лікування або вимкнене, або тест позначається нестабільним до рев'ю. Автооновлення локаторів у репозиторії — лише через PR, який підтверджує людина. Раз на спринт переглядаємо журнал лікувань: часті лікування одного елемента означають, що треба виправити сам локатор або попросити розробників додати тестовий атрибут.

A control policy. A heal is always a signal, never a silent success: the event goes into the report as a warning. On release branches and for critical flows (payment, sign-up) healing is either off or the test is marked unstable until reviewed. Automatic locator updates in the repository go only through a PR a human approves. Once a sprint we review the heal log: frequent heals on one element mean the locator itself needs fixing, or developers should add a test attribute.

Компроміс. Суворіша політика — більше червоних прогонів і ручної роботи, м'якша — ризик пропустити баг. Я обираю строгість за критичністю потоку, а не одну для всіх.

The trade-off. A stricter policy means more red runs and manual work, a looser one risks missing a bug. I pick strictness per flow criticality, not one setting for everything.

Що це. Testim — один із відомих прикладів платформ, які поєднують запис дій користувача (record & replay), «розумні» локатори на основі багатьох атрибутів елемента і self-healing. Ідея — зменшити витрати на супровід UI-тестів, які ламаються через дрібні зміни верстки.

What it is. Testim is one well-known example of platforms that combine recording user actions (record & replay), "smart" locators built on many element attributes, and self-healing. The goal is to cut the maintenance cost of UI tests that break on small layout changes.

Типові можливості таких платформ. Візуальний редактор кроків, де тест можна зібрати без коду або з невеликими вставками JavaScript; повторне використання груп кроків; параметризація даними; запуск у хмарі на різних браузерах; інтеграція з CI і звіти зі скріншотами. Конкретний набір функцій відрізняється між продуктами й тарифами, тож перед вибором варто читати актуальну документацію.

Typical capabilities of such platforms. A visual step editor where a test can be built without code or with small JavaScript snippets; reusable step groups; data-driven parameters; cloud runs across browsers; CI integration and reports with screenshots. The exact feature set differs between products and plans, so read the current documentation before choosing.

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

Who it suits. Teams with many manual testers who need UI regression quickly, and products with frequent cosmetic UI changes.

Підводні камені. Залежність від вендора, складність рев'ю змін у візуальному редакторі порівняно з diff коду, ціна при зростанні кількості прогонів і ризик, що лікування маскує дефекти. Записаний тест без продуманих перевірок лише «проклацує» сторінку.

Pitfalls. Vendor lock-in, changes that are harder to review in a visual editor than in a code diff, cost as run volume grows, and the risk of healing masking defects. A recorded test without deliberate assertions merely clicks through the page.

Попіксельне порівняння. Скріншот порівнюється з еталоном (baseline) піксель за пікселем. Це просто і вбудовано в багато фреймворків, але крихко: згладжування шрифтів (anti-aliasing), інший рендеринг на CI-машині, дата чи банер змінюють пікселі без реального дефекту. Команди борються масками і допусками на частку різних пікселів.

Pixel comparison. A screenshot is compared to a baseline pixel by pixel. It is simple and built into many frameworks but brittle: font anti-aliasing, different rendering on a CI machine, a date or a banner change pixels without any real defect. Teams fight back with masks and a tolerance for the share of differing pixels.

Visual AI. Інструменти на кшталт Applitools Eyes порівнюють знімки на рівні структури й сприйняття: розпізнають елементи, макет, текст, і намагаються відрізнити «зсунувся блок чи зник текст» від «змінилося згладжування». Зазвичай є режими суворості — від строгого до порівняння лише макета — і групування однакових змін на багатьох сторінках, щоб прийняти їх одним рішенням.

Visual AI. Tools such as Applitools Eyes compare images at the level of structure and perception: they recognise elements, layout and text, and try to tell "a block moved or text vanished" from "anti-aliasing changed". There are usually strictness modes — from strict to layout-only — and grouping of identical changes across many pages so they can be accepted with one decision.

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

Common to both. A human must approve the baseline: accept a screenshot with a broken layout and the bug becomes the norm. Dynamic regions are masked or ignored, and the data is made deterministic.

Вибір. Для кількох стабільних сторінок вистачає вбудованого порівняння; для сотень сторінок на багатьох браузерах і пристроях visual AI зменшує шум, але коштує грошей і відправляє скріншоти вендору.

Choosing. For a few stable pages built-in comparison is enough; for hundreds of pages across many browsers and devices visual AI reduces noise, but it costs money and sends screenshots to a vendor.

Супровід. Коли змінюється API чи UI, асистент може прочитати diff і знайти тести, які зачіпає зміна, запропонувати оновлення локаторів, моделей даних чи Page Object. Людина перевіряє, чи оновлення відображає нову задуману поведінку, а не просто підганяє тест під будь-що.

Maintenance. When an API or UI changes, an assistant can read the diff, find the tests the change affects and suggest updates to locators, data models or Page Objects. A person checks that the update reflects the new intended behaviour rather than simply bending the test to whatever happens.

Тріаж падінь. Сотні червоних прогонів за ніч мають кілька справжніх причин. Спершу групуємо падіння за нормалізованим підписом помилки (без id, часу, чисел), потім даємо LLM по одному прикладу з кожної групи з контекстом: історія проходжень, зміни в коді, середовище. Модель пропонує гіпотези: таймінг, спільні дані, нестабільне середовище чи справжній баг.

Failure triage. Hundreds of red runs overnight usually come down to a few real causes. First we group failures by a normalised error signature (no ids, timestamps or numbers), then give the LLM one example per group with context: pass history, code changes, environment. The model suggests hypotheses: timing, shared data, an unstable environment or a real bug.

Ознаки flaky. Тест то проходить, то падає на тому самому коміті; падає лише паралельно; падає в певний час доби. Такі дані краще рахувати детерміновано скриптом, а AI використовувати для пояснення і пропозиції виправлення.

Flaky signals. The test passes and fails on the same commit; fails only in parallel; fails at a certain time of day. These facts are better computed deterministically by a script, with AI used to explain and propose a fix.

Пастка. Позначити тест flaky і додати ретраї за порадою AI, коли насправді це стан гонитви (race condition) у продукті. Гіпотезу моделі завжди перевіряємо відтворенням.

The trap. Marking a test flaky and adding retries on AI advice when it is actually a race condition in the product. The model's hypothesis is always checked by reproducing it.

Пріоритизація. Замість запуску всіх 5000 тестів на кожен коміт система оцінює ризик кожного тесту: які файли змінено і які тести їх покривають (за картою покриття), як часто тест падав раніше, як давно запускався, наскільки важлива фіча. Спершу йдуть тести з найвищим балом, щоб ймовірне падіння було видно за хвилини, а не за годину.

Prioritisation. Instead of running all 5000 tests on every commit, the system scores each test's risk: which files changed and which tests cover them (from a coverage map), how often the test failed before, how long since it last ran, how important the feature is. The highest-scoring tests go first so a likely failure shows up in minutes rather than an hour.

Де тут ML. Прості системи використовують правила й ваги. Складніші тренують модель на історії: «при зміні таких файлів найчастіше падали такі тести». Вона вловлює неочевидні зв'язки, яких немає в карті покриття, наприклад конфіги чи міграції.

Where ML comes in. Simple systems use rules and weights. More advanced ones train a model on history: "when these files change, these tests fail most often". It captures non-obvious links missing from the coverage map, such as configs or migrations.

Continuous testing з AI. На кожну зміну система визначає зачеплені області, запускає цільовий набір і може запропонувати нові тест-кейси для нового коду. Повний набір усе одно регулярно запускається — вночі або перед релізом, — щоб ловити те, що модель пропустила.

Continuous testing with AI. On every change the system finds affected areas, runs a targeted set and may suggest new test cases for new code. The full suite still runs regularly — nightly or before a release — to catch what the model missed.

Ризик. Тест, який ніколи не падав, отримує низький бал і рідко запускається — а саме він міг би зловити рідкісну регресію. Тому частину тестів вибирають випадково, а пропущені падіння від нічного прогону повертаються в модель як зворотний зв'язок.

The risk. A test that never failed gets a low score and rarely runs — yet it might be the one to catch a rare regression. So some tests are chosen at random, and failures the nightly run finds that selection missed are fed back into the model.

Доступність (a11y). Автоматичні сканери (наприклад, на основі axe-core) знаходять контраст, відсутні alt-тексти, неправильні ARIA-атрибути, поля без підписів. AI-надбудови пропонують тексти для alt чи виправлення. Але автоматика покриває лише частину критеріїв WCAG: чи осмислений alt-текст, чи логічний порядок фокусу, чи зручно з екранним читачем — перевіряє людина.

Accessibility (a11y). Automated scanners (for example ones built on axe-core) find contrast issues, missing alt text, wrong ARIA attributes, unlabeled fields. AI add-ons suggest alt text or fixes. But automation covers only part of the WCAG criteria: whether the alt text is meaningful, whether focus order is logical, whether it works well with a screen reader — a person checks that.

Безпека. AI допомагає генерувати контекстні payload-и для фазингу, пояснювати знахідки сканерів, писати перевірки для OWASP Top 10, шукати аномалії в логах. Проте бізнес-логічні вразливості — обхід оплати, доступ до чужого замовлення за id (IDOR) — вимагають розуміння правил доступу, і модель їх сама не вигадає. Будь-який активний тест — тільки на погодженому середовищі.

Security. AI helps generate context-aware payloads for fuzzing, explain scanner findings, write checks for the OWASP Top 10 and spot anomalies in logs. Business-logic flaws, though — bypassing payment, reading someone else's order by id (IDOR) — require understanding access rules, and a model will not invent them on its own. Any active test runs only on an approved environment.

Продуктивність. AI добре шукає аномалії в метриках і логах, прогнозує тренди, допомагає написати скрипт навантаження. Але профіль навантаження з бізнес-подій (розпродаж, кінець місяця), вибір SLO і архітектурні рішення щодо масштабування залишаються за людьми, які знають контекст.

Performance. AI is good at spotting anomalies in metrics and logs, forecasting trends and helping write a load script. But a load profile built from business events (a sale, month end), choosing SLOs and architectural scaling decisions stay with people who know the context.

Головний ризик. Персональні дані клієнтів (PII — імена, email, телефони, адреси, номери договорів) виходять за периметр компанії до третьої сторони. Після відправки ви вже не контролюєте, де запит логується, скільки зберігається, хто з персоналу постачальника може його побачити і чи потрапить він у навчання моделі. Витік не можна відкликати: навіть якщо постачальник обіцяє видалення, факт передачі без правової підстави вже є порушенням GDPR і внутрішніх політик.

The main risk. Customers' personal data (PII — names, emails, phone numbers, addresses, contract numbers) leaves the company boundary and lands at a third party. Once sent, you no longer control where the request is logged, how long it is kept, which vendor staff can see it, or whether it ends up in model training. A leak cannot be recalled: even if the vendor promises deletion, transferring the data without a legal basis is already a GDPR and internal policy violation.

Чому це не дрібниця. Проблеми з форматом згенерованих даних видно одразу і їх лікує валідація. Витік тихий: його помічають через місяці на аудиті або після скарги клієнта. Для регульованих доменів (фінанси, медицина) це ще й штрафи та обов'язкове повідомлення регулятора.

Why it is not minor. Format problems in generated data show up immediately and validation fixes them. A leak is silent: it is found months later in an audit or after a customer complaint. In regulated domains such as finance or healthcare it also means fines and a mandatory notice to the regulator.

Що робити замість. Надсилати моделі схему і бізнес-правила, а не записи: типи полів, обмеження, розподіли, приклади з вигаданими значеннями. Якщо без реальних прикладів не обійтися — спершу маскування або анонімізація, і тільки через погоджений корпоративний контракт із постачальником (без навчання на ваших даних, з обмеженим терміном зберігання).

What to do instead. Send the model the schema and business rules, not records: field types, constraints, distributions, examples with made-up values. If real examples are unavoidable, mask or anonymise them first, and only through an approved enterprise agreement with the vendor (no training on your data, limited retention).

Уточнення. Питання «а якщо модель локальна?» — ризик менший, але доступ до продакшн-даних на тестовому стенді все одно має бути обґрунтований і журнальований.

Follow-up. "What if the model runs locally?" — the risk is lower, but access to production data in a test environment still has to be justified and logged.

Суть. Маскування (masking) — заміна чутливих значень на безпечні токени до того, як текст покине вашу машину. Для розбору логів чи стек-трейсу моделі не потрібні справжні email, телефон чи номер картки: їй достатньо знати, що «тут був email». Важливо робити заміну стабільною: той самий email у всьому лозі стає тим самим токеном, наприклад EMAIL_1, щоб модель бачила, що це один користувач.

The idea. Masking replaces sensitive values with safe tokens before the text leaves your machine. To analyse logs or a stack trace, the model does not need the real email, phone or card number: it only needs to know "an email was here". The replacement should be stable: the same email throughout the log becomes the same token, such as EMAIL_1, so the model can see it is one user.

Як будувати. Регулярні вирази ловлять структуровані дані: email, телефони, номери карток (з перевіркою алгоритмом Луна, щоб не чіпати звичайні числа), IP, JWT і API-ключі. Імена й адреси регулярками не зловиш — для них потрібні NER-бібліотеки або словники, і це варто чесно назвати обмеженням. Скрипт запускають як обов'язковий крок перед будь-якою вставкою в зовнішній інструмент.

How to build it. Regular expressions catch structured data: emails, phone numbers, card numbers (with a Luhn check so ordinary numbers are left alone), IPs, JWTs and API keys. Names and addresses cannot be caught with regexes — they need NER libraries or dictionaries, and that limitation should be stated honestly. The script runs as a mandatory step before anything is pasted into an external tool.

Підводні камені. Маскування — не анонімізація: комбінація дати, міста і суми платежу все ще може ідентифікувати людину. Друга пастка — забути про поля в JSON-тілах запитів та в URL-параметрах. Третя — не тестувати сам маскувальник: на нього потрібні юніт-тести з реальними форматами ваших логів.

Pitfalls. Masking is not anonymisation: a combination of date, city and payment amount can still identify a person. The second trap is forgetting fields inside JSON request bodies and URL parameters. The third is not testing the masker itself: it needs unit tests built on the real formats of your logs.

Що це. Синтетичні дані (synthetic data) — записи, які відповідають схемі й бізнес-правилам, але не належать жодній реальній людині. LLM зручна тим, що розуміє опис природною мовою: «100 профілів покупців інтернет-магазину, 10% з неповною адресою, картки лише тестові». Так дані не містять PII і їх можна вільно класти в репозиторій та фікстури.

What it is. Synthetic data are records that match the schema and business rules but belong to no real person. An LLM is handy because it understands a natural-language description: "100 e-commerce shopper profiles, 10% with an incomplete address, test cards only". The data contain no PII and can be committed to the repository and fixtures freely.

Чому не можна брати на віру. Модель генерує правдоподібно, а не правильно: дублікати email там, де поле унікальне, дата народження після дати реєстрації, «тестова» картка, що не проходить перевірку, або однакові імена у половині записів. Ще одна проблема — розподіли: модель тяжіє до «типових» значень і рідко сама дає крайові випадки.

Why you cannot take it on trust. The model generates what is plausible, not what is correct: duplicate emails where the field is unique, a birth date after the registration date, a "test" card that fails validation, or identical names in half the records. Distributions are another problem: the model drifts toward "typical" values and rarely produces edge cases on its own.

Як перевірити. Кожен згенерований набір проганяють через валідатор: JSON Schema для форми, окремі перевірки для крос-полів і унікальності, підрахунок розподілів проти заявлених. Для великих обсягів краще попросити модель написати генератор (наприклад, на Faker із фіксованим seed), а не самі дані: код відтворюваний і його можна переглянути.

How to validate. Every generated set goes through a validator: JSON Schema for shape, separate checks for cross-field rules and uniqueness, and distribution counts against what was requested. For large volumes it is better to ask the model to write a generator (for example with Faker and a fixed seed) rather than the data itself: code is reproducible and can be reviewed.

Проблема. Тестувальник постійно працює з речами, які не можна виносити: конфіги стендів із паролями, .env-файли, токени в заголовках запитів, HAR-файли з cookie сесій, внутрішні URL і сам код продукту. Вставка такого фрагмента в публічний чат-бот дорівнює публікації секрету. Навіть в інструменті всередині IDE контекст часто відправляється на сервер постачальника, тож «я ж нічого не копіював» — не аргумент.

The problem. A tester constantly handles things that must not leave the building: stand configs with passwords, .env files, tokens in request headers, HAR files with session cookies, internal URLs and the product code itself. Pasting such a fragment into a public chatbot equals publishing the secret. Even an in-IDE tool often sends context to the vendor's server, so "I didn't copy anything" is not an argument.

Правила, що працюють. Перше — тільки інструменти, погоджені безпекою, з корпоративним договором (без навчання на даних, відомий термін зберігання, журнал доступу). Друге — виключення файлів: .env, ключі, дампи БД і HAR додаються в ignore-список інструмента, якщо він таке підтримує. Третє — автоматична перевірка перед відправкою: сканер секретів на pre-commit і на все, що копіюється в промпт. Четверте — секрет, що все ж потрапив у промпт, вважається скомпрометованим і ротується одразу.

Rules that work. First, use only tools approved by security, under an enterprise agreement (no training on your data, known retention, access log). Second, exclude files: .env, keys, database dumps and HAR files go into the tool's ignore list if it supports one. Third, an automatic check before sending: a secret scanner on pre-commit and on anything copied into a prompt. Fourth, a secret that did reach a prompt is treated as compromised and rotated at once.

Пастка. Заборонити все — означає, що люди почнуть користуватися особистими акаунтами потай. Краще дати дозволений інструмент і зрозумілі правила, ніж тіньове використання без контролю.

The trap. Banning everything means people start using personal accounts quietly. It is better to provide an approved tool and clear rules than uncontrolled shadow usage.

Три групи ризиків. Перша — походження: модель навчалася на публічному коді, і зрідка може відтворити фрагмент майже дослівно, разом із ліцензійними умовами оригіналу (наприклад, copyleft, що вимагає відкриття похідного коду). Друга — права на результат: у різних юрисдикціях по-різному вирішують, чи захищається авторським правом текст, створений машиною, і хто його власник. Третя — умови постачальника: договір визначає, кому належить вивід, чи використовуються ваші запити для навчання і чи є відшкодування (indemnity) у разі претензій.

Three groups of risk. The first is provenance: the model was trained on public code and can occasionally reproduce a fragment almost verbatim, along with the original's licence terms (for example copyleft, which requires opening derived code). The second is rights to the output: jurisdictions differ on whether machine-produced text is protected by copyright and who owns it. The third is vendor terms: the contract decides who owns the output, whether your requests are used for training, and whether there is indemnity if someone makes a claim.

Чому це стосується QA. Тестовий код рідко продається, але він живе в тому ж репозиторії, що й продукт, а тестові фреймворки та утиліти компанії іноді відкривають як open source. Крім коду, є тестові дані й медіа: згенеровані зображення для візуальних тестів чи тексти для eval-наборів теж мають походження.

Why it concerns QA. Test code is rarely sold, but it lives in the same repository as the product, and companies sometimes open-source their test frameworks and utilities. Beyond code there are test data and media: generated images for visual tests or texts for eval sets also have a provenance.

Практичне рішення. Юридичні висновки робить не QA, а юристи компанії. Роль сеньйора — забезпечити процес: інструмент із погодженими умовами, увімкнений фільтр збігів із публічним кодом, якщо інструмент його має, сканування ліцензій залежностей, позначка в PR про суттєво згенерований код і ручний перегляд великих «готових» блоків, які виглядають підозріло завершеними.

The practical answer. Legal conclusions are made by the company's lawyers, not QA. A senior's role is to secure the process: a tool with approved terms, a public-code match filter switched on if the tool offers one, licence scanning of dependencies, a note in the PR about substantially generated code, and manual review of large "ready-made" blocks that look suspiciously complete.

Що це. Оракул (test oracle) — механізм, що каже, чи правильний результат. У класичному тесті це очікуване значення: 2 + 2 = 4. Для AI-систем єдиної правильної відповіді часто немає: «підсумуй лист клієнта» чи «опиши зображення» має десятки коректних варіантів, а ще більше — майже коректних. Порівняння рядків тут безглузде, тож тест не знає, з чим звіряти.

What it is. An oracle is the mechanism that tells you whether an output is right. In a classic test it is the expected value: 2 + 2 = 4. AI systems often have no single correct answer: "summarise the customer's email" or "describe the image" has dozens of correct variants and even more almost-correct ones. String comparison is meaningless here, so the test does not know what to compare against.

Як його обходять. Комбінують кілька часткових оракулів, кожен із яких ловить свій клас помилок. Детерміновані перевірки властивостей: формат JSON, наявність обов'язкових фактів, відсутність заборонених тем, довжина. Референсні метрики на кшталт BLEU чи ROUGE порівнюють із еталоном за словами, але погано бачать зміст, тому для генеративного тексту частіше беруть семантичну схожість або LLM-as-judge з рубрикою. Метаморфні відношення перевіряють не саму відповідь, а зв'язок між відповідями. І нарешті — людська оцінка вибірки, яка калібрує все інше.

How it is worked around. You combine several partial oracles, each catching its own class of error. Deterministic property checks: JSON format, required facts present, forbidden topics absent, length. Reference metrics such as BLEU or ROUGE compare against a reference by words but see meaning poorly, so for generative text semantic similarity or LLM-as-judge with a rubric are more common. Metamorphic relations check not the answer itself but the relation between answers. And finally, human rating of a sample calibrates all the rest.

Трейдоф. Чим дешевший оракул, тим вужче, що він бачить. Детерміновані перевірки швидкі й стабільні, але пропускають змістові помилки; суддя-модель бачить зміст, але коштує грошей і сам помиляється; люди найточніші, але повільні. Сеньйорська відповідь — піраміда: багато дешевих перевірок на кожен коміт, суддя на eval-наборі перед релізом, люди на вибірці і на спірних випадках.

The trade-off. The cheaper the oracle, the narrower its view. Deterministic checks are fast and stable but miss errors of meaning; a judge model sees meaning but costs money and makes mistakes itself; humans are the most accurate but slow. The senior answer is a pyramid: many cheap checks on every commit, a judge on the eval set before release, humans on a sample and on disputed cases.

Звідки недетермінованість. Модель обирає наступний токен із розподілу ймовірностей; параметр temperature керує тим, наскільки випадковим буде вибір. Temperature 0 і фіксований seed (якщо API його підтримує) зменшують розкид, але не гарантують однакову відповідь: на результат впливають пакетна обробка на сервері, апаратні відмінності та оновлення моделі постачальником. Тож тест, що порівнює рядок дослівно, рано чи пізно почне «мигати».

Where non-determinism comes from. The model picks the next token from a probability distribution; the temperature parameter controls how random the pick is. Temperature 0 and a fixed seed (if the API supports one) reduce the spread but do not guarantee an identical answer: server-side batching, hardware differences and vendor model updates all affect the result. So a test that compares the string verbatim will start flickering sooner or later.

Толерантні твердження. Перевіряють не текст, а властивості: HTTP-статус, валідний JSON за схемою, обов'язкові сутності (номер замовлення, сума), приналежність категорії до дозволеного набору, відсутність заборонених фраз, довжину в межах. Для змісту — нечутливий до регістру пошук ключових фактів або семантична схожість із порогом. Кожен тест перевіряє одну властивість, щоб падіння одразу казало, що саме зламалося.

Tolerant assertions. You check properties, not text: HTTP status, valid JSON against a schema, required entities (order number, amount), category within an allowed set, forbidden phrases absent, length within bounds. For meaning, a case-insensitive search for key facts or semantic similarity above a threshold. Each test checks one property, so a failure tells you immediately what broke.

Типова помилка. Лікувати «мигання» ретраями. Ретрай ховає реальну нестабільність, яку побачить користувач. Правильніше виміряти частку успішних прогонів (див. наступну картку) і звести твердження до того, що справді має бути стабільним.

Common mistake. Curing flakiness with retries. A retry hides real instability the user will see. It is better to measure the pass rate across runs (see the next card) and narrow the assertions down to what truly must be stable.

Ідея. Один прогін LLM-тесту — це одна вибірка з розподілу. Якщо тест пройшов, це не означає, що він пройде завтра. Тому для важливих кейсів той самий запит надсилають N разів (зазвичай 10–30) і рахують частку прогонів, де виконалися всі перевірки. Результат — не «зелений/червоний», а pass rate, наприклад 27 з 30, і поріг, нижче якого кейс вважається нестабільним.

The idea. One run of an LLM test is one sample from a distribution. A pass does not mean it will pass tomorrow. So for important cases the same request is sent N times (usually 10–30) and you count the share of runs where all checks held. The result is not "green/red" but a pass rate, say 27 out of 30, plus a threshold below which the case is considered unstable.

Що ще міряти. Окрім pass rate корисно бачити, скільки різних варіантів дала модель для полів, що мають бути однаковими (категорія, рішення «так/ні»), і розкид довжини. Коли на 30 прогонах intent двічі змінився з refund на other — це дефект продукту, а не «шум тесту»: реальний користувач так само отримає інше рішення.

What else to measure. Besides the pass rate it helps to see how many distinct values the model produced for fields that should be identical (a category, a yes/no decision) and the spread of length. When intent switches from refund to other twice in 30 runs, that is a product defect, not "test noise": a real user will get a different decision in the same way.

Практичні межі. N прогонів коштують N викликів, тому повний прогін стабільності роблять на невеликому наборі критичних кейсів уночі або перед релізом, а не на кожен коміт. Поріг обирають за ризиком: для класифікації повернень коштів — 100%, для тону відповіді — 90%. Чи не найчастіша помилка — рахувати стабільність на кешованих відповідях: переконайтеся, що кеш вимкнено.

Practical limits. N runs cost N calls, so a full stability run goes over a small set of critical cases nightly or before a release, not on every commit. The threshold follows the risk: 100% for refund classification, 90% for the tone of the answer. One of the most frequent mistakes is measuring stability on cached responses, so make sure the cache is off.

Що це. Golden set (еталонний набір) — версіонований набір вхідних запитів з очікуваними характеристиками відповіді, перевірений людьми. Це аналог регресійного набору тест-кейсів для LLM-функції: на ньому порівнюють версії промпту чи моделі. Очікування записують не як точний текст, а як критерії: які факти мають бути, чого не має бути, яку категорію повернути, чи має модель відмовитися.

What it is. A golden set is a versioned collection of input requests with expected answer characteristics, verified by humans. It is the LLM counterpart of a regression suite: prompt or model versions are compared on it. Expectations are written not as exact text but as criteria: which facts must be present, what must be absent, which category to return, whether the model should refuse.

Звідки брати кейси. Найцінніше джерело — реальні запити з продакшну (після маскування PII), бо вони показують, як люди насправді питають. До них додають крайові випадки від QA: неоднозначні запити, питання поза темою, запити без відповіді в базі знань, спроби prompt injection, різні мови, опечатки. Кожен виправлений інцидент теж стає новим кейсом. Корисно тегувати кейси (категорія, ризик), щоб бачити метрики за зрізами.

Where cases come from. The most valuable source is real production requests (after PII masking), because they show how people actually ask. QA adds edge cases on top: ambiguous requests, off-topic questions, requests with no answer in the knowledge base, prompt injection attempts, different languages, typos. Every fixed incident also becomes a new case. Tagging cases (category, risk) lets you see metrics by slice.

Підводні камені. Набір із 20 «зручних» кейсів дає ілюзію якості. Інша пастка — використовувати ті самі кейси як few-shot приклади в промпті: модель просто «запам'ятає» відповіді, і оцінка буде завищена. Golden set живе в git, змінюється через рев'ю, а його версію пишуть у кожен звіт.

Pitfalls. A set of 20 "convenient" cases gives an illusion of quality. Another trap is reusing the same cases as few-shot examples in the prompt: the model effectively "memorises" the answers and the score is inflated. The golden set lives in git, changes through review, and its version is written into every report.

Що це. LLM-as-a-judge — підхід, коли одна модель оцінює відповіді іншої (або тієї ж) системи за заданою рубрикою: правдивість відносно контексту, корисність, тон, безпека. Він автоматизує частину людської оцінки і масштабується на сотні кейсів, де перевірка рядків безсила. Найкраще працює, коли судді дають чіткі критерії, еталонну відповідь чи вихідний документ і просять спочатку коротке обґрунтування, а потім бал.

What it is. LLM-as-a-judge is an approach where one model rates the answers of another (or the same) system against a given rubric: truthfulness relative to the context, helpfulness, tone, safety. It automates part of human evaluation and scales to hundreds of cases where string checks are powerless. It works best when the judge gets clear criteria, a reference answer or the source document, and is asked for a short justification first and a score second.

Відомі упередження. Позиційне (position bias): при порівнянні двох відповідей суддя частіше обирає ту, що стоїть першою або другою. Упередження довжини (verbosity bias): довші відповіді здаються кращими. Самовподобання (self-preference): модель вище оцінює текст свого «стилю» чи своєї родини. Поблажливість: схильність ставити середньо-високі бали всім. Крім того, суддя вразливий до prompt injection у відповіді, яку оцінює.

Known biases. Position bias: when comparing two answers the judge favours whichever comes first or second. Verbosity bias: longer answers look better. Self-preference: a model rates text in its own "style" or from its own family higher. Leniency: a tendency to give everyone medium-high scores. On top of that the judge is vulnerable to prompt injection inside the answer it is grading.

Як пом'якшити. Міняти порядок відповідей і рахувати обидва варіанти; використовувати шкалу з описом кожного бала або бінарні питання замість «оціни 1–10»; брати суддю іншої родини, ніж модель продукту; і головне — калібрувати на 50–100 кейсах, оцінених людьми, та регулярно перевіряти узгодженість.

How to mitigate. Swap the answer order and score both variants; use a scale with a description of every score, or binary questions instead of "rate 1–10"; pick a judge from a different family than the product model; and above all, calibrate on 50–100 human-rated cases and keep checking agreement regularly.

Групи метрик. Коректність: accuracy для задач із правильною відповіддю (класифікація intent, витяг полів), exact match чи F1 для коротких відповідей. Обґрунтованість (groundedness, faithfulness): чи кожне твердження спирається на наданий контекст — ключова метрика для RAG. Релевантність (relevance): чи відповідь стосується питання, а не просто правдива. Безпека: токсичність, частка витоків PII, частка успішних ін'єкцій. Поведінка: частка доречних відмов і частка хибних відмов (коли бот відмовив, хоча відповідь була). Експлуатація: латентність p95, токени й вартість на запит.

Metric groups. Correctness: accuracy for tasks with a right answer (intent classification, field extraction), exact match or F1 for brief factual replies. Groundedness or faithfulness: is every claim supported by the provided context — the key metric for RAG. Relevance: does the answer address the question rather than merely being true. Safety: toxicity, PII leak rate, successful injection rate. Behaviour: rate of appropriate refusals and rate of false refusals (the bot declined although an answer existed). Operations: p95 latency, tokens and cost per request.

Як обирати. Метрики виводять із ризиків функції, а не з переліку в бібліотеці. Для бота повернень найважливіші обґрунтованість і відсутність вигаданих строків; для генератора описів товарів — релевантність і тон. Кожна метрика має спосіб вимірювання (детермінований, суддя, людина) і поріг, прив'язаний до рішення «випускаємо чи ні».

How to choose. Metrics are derived from the feature's risks, not from a library's list. For a refund bot, groundedness and the absence of invented deadlines matter most; for a product description generator, relevance and tone. Every metric has a measuring method (deterministic, judge, human) and a threshold tied to the "ship or not" decision.

Пастка. Одне агреговане число «якість 87%» ховає провали на важливих зрізах. Дивіться метрики за тегами: загальна обґрунтованість може бути 95%, а на запитах про повернення — 80%.

The trap. A single aggregate "quality 87%" hides failures on important slices. Look at metrics by tag: overall groundedness can be 95% while refund questions sit at 80%.

Що це. RAG (Retrieval Augmented Generation) — схема, де перед генерацією система шукає релевантні фрагменти в базі знань (документи, FAQ, політики) і передає їх моделі разом із питанням. Модель відповідає на основі актуальних даних компанії, а не лише того, що запам'ятала під час навчання. Це зменшує галюцинації, але не усуває їх, і додає нові точки відмови.

What it is. RAG (Retrieval Augmented Generation) is a design where, before generating, the system searches a knowledge base (documents, FAQ, policies) for relevant fragments and passes them to the model together with the question. The model answers from the company's current data rather than only what it memorised in training. This reduces hallucinations but does not remove them, and it adds new points of failure.

Тестуємо два етапи окремо. Пошук (retrieval): чи потрапив потрібний документ у top-k результатів — метрики recall@k і MRR на наборі «питання → очікуваний документ». Генерація: чи відповідь спирається на знайдені фрагменти (groundedness), чи посилання (citations) ведуть на справжні документи і чи цитований фрагмент справді містить твердження. Якщо розділити етапи, одразу видно, хто винен: пошук не знайшов чи модель проігнорувала знайдене.

Test the two stages separately. Retrieval: did the needed document land in the top-k results — recall@k and MRR on a "question → expected document" set. Generation: is the answer based on the retrieved fragments (groundedness), do the citations point to real documents, and does the cited fragment actually contain the claim. Splitting the stages shows immediately who is to blame: retrieval missed it, or the model ignored what was found.

Застарілі знання. Коли політика змінилася (строк повернення з 30 на 14 днів), а стара версія лишилася в індексі, бот впевнено відповість неправильно. Тест: оновити документ і перевірити, що після переіндексації відповідь змінилася, а стара версія не знаходиться. Окремо — кейси, де відповіді в базі немає: правильна поведінка — сказати про це.

Stale knowledge. When a policy changes (the return window goes from 30 to 14 days) but the old version stays in the index, the bot will answer wrongly and confidently. The test: update the document and check that after reindexing the answer changes and the old version is no longer retrieved. Separately, cases where the knowledge base has no answer: the correct behaviour is to say so.

Що шукаємо. Галюцинація у продукті — це відповідь, яка звучить впевнено, але містить твердження, яких немає в джерелах: вигаданий строк доставки, неіснуючий тариф, посилання на сторінку, якої немає. Для користувача вона гірша за відмову, бо на неї покладаються. Тестування будують навколо ситуацій, де модель спокушається вигадати.

What we look for. A hallucination in a product is an answer that sounds confident but contains claims absent from the sources: an invented delivery time, a non-existent plan, a link to a page that doesn't exist. For the user it is worse than a refusal, because they rely on it. Testing is built around situations where the model is tempted to make things up.

Класи тест-кейсів. Питання без відповіді в базі знань (правильно — визнати, що не знає). Питання з хибною передумовою: «Чому ваш тариф Platinum подорожчав?», хоча такого тарифу нема (правильно — виправити передумову). Питання про точні числа й дати, де модель любить «округлювати». Запити на посилання й номери документів. Схожі сутності, які легко сплутати: два товари з близькими назвами.

Test case classes. Questions with no answer in the knowledge base (correct: admit not knowing). Questions with a false premise: "Why did your Platinum plan get more expensive?" when no such plan exists (correct: correct the premise). Questions about exact numbers and dates, where the model likes to "round". Requests for links and document numbers. Similar entities that are easy to mix up: two products with close names.

Як перевіряти. Для відомих фактів — must_not_include зі спокусливими хибними значеннями. Для URL і ідентифікаторів — детермінована перевірка, що вони існують. Для загального змісту — суддя з критерієм «кожне твердження підтверджено контекстом». Метрика — частка відповідей з хоча б одним непідтвердженим твердженням, окремо на високоризикових тегах.

How to check. For known facts, must_not_include with tempting wrong values. For URLs and identifiers, a deterministic check that they exist. For overall content, a judge with the criterion "every claim is supported by the context". The metric is the share of answers with at least one unsupported claim, tracked separately for high-risk tags.

Сценарій. Команда хоче перейти на новішу модель, бо вона дешевша, а заодно «трохи підкрутили» системний промпт. Для класичного коду регресію ловлять тести; тут будь-яка зміна — промпт, модель, параметри, чанкінг бази знань, навіть оновлення моделі на боці постачальника під тим самим ім'ям — може тихо погіршити частину відповідей, покращивши іншу.

The scenario. The team wants to move to a newer model because it is cheaper, and the system prompt was "tweaked a bit" along the way. In classic code regressions are caught by tests; here any change — the prompt, the model, parameters, knowledge base chunking, even a vendor-side model update under the same name — can quietly make some answers worse while improving others.

Процес. Усе, що впливає на відповідь, версіонується разом: текст промпту, ідентифікатор моделі (закріплений, а не «latest»), параметри, версія індексу. Будь-яка зміна запускає eval на golden set для базової і кандидатної конфігурацій, бажано з кількома прогонами, і звіт порівнює метрики за тегами. Зміну вносять по одній: якщо одночасно міняти модель і промпт, неможливо зрозуміти, що саме дало ефект.

The process. Everything that affects the answer is versioned together: the prompt text, the model identifier (pinned, not "latest"), parameters, the index version. Any change triggers an eval on the golden set for both the baseline and the candidate configurations, ideally with several runs, and the report compares metrics by tag. Change one thing at a time: if you swap the model and the prompt together you cannot tell which one caused the effect.

Рішення. Порівнювати не лише середні, а й кейси, що перевернулися: були зеленими й стали червоними. Три нові провали на повернення коштів важать більше, ніж плюс 2% релевантності загалом. Метрики безпеки — жорсткий гейт; для решти допускається шум у межах, виміряних на повторних прогонах базової версії. Після релізу — shadow або канарка з моніторингом тих самих метрик.

The decision. Compare not only averages but also the cases that flipped: green before, red now. Three new failures on refunds weigh more than plus 2% relevance overall. Safety metrics are a hard gate; for the rest, noise is tolerated within the range measured on repeated runs of the baseline. After release, shadow or canary with monitoring of the same metrics.

Латентність. Час відповіді LLM залежить від довжини вводу і, особливо, виводу: модель генерує токени послідовно. Тому міряють два числа: час до першого токена (TTFT), який користувач відчуває при стрімінгу, і повний час відповіді. Дивляться p95 і p99, а не середнє, бо довгі відповіді дають важкий хвіст. Окремо перевіряють поведінку під навантаженням: провайдери обмежують кількість запитів і токенів за хвилину, і на піку з'являються відповіді 429.

Latency. LLM response time depends on input length and especially on output length: the model generates tokens sequentially. So two numbers are measured: time to first token (TTFT), which the user feels with streaming, and full response time. Look at p95 and p99, not the mean, because long answers create a heavy tail. Behaviour under load is checked separately: providers limit requests and tokens per minute, and at peak you start seeing 429 responses.

Вартість. Платять за токени вводу й виводу, часто за різними цінами. Тест — порахувати середню і p95 кількість токенів на запит на golden set і помножити на тариф; регресія вартості — такий самий гейт, як і регресія якості. Типові «вбивці бюджету»: занадто багато фрагментів у RAG-контексті, вся історія чату в кожному запиті, ретраї без обмеження.

Cost. You pay for input and output tokens, often at different prices. The test is to compute mean and p95 tokens per request on the golden set and multiply by the rate; a cost regression is as much a gate as a quality regression. Typical budget killers: too many fragments in the RAG context, the whole chat history in every request, unbounded retries.

Ліміти токенів. Контекстне вікно скінченне. Що буде, коли користувач вставить документ на 200 сторінок або чат триває годину? Правильна поведінка — зрозуміле повідомлення чи обрізання історії за правилом, а не помилка 500 чи обрізана посеред речення відповідь. Також перевіряють, що ліміт вихідних токенів не ріже JSON, від якого залежить інтерфейс.

Token limits. The context window is finite. What happens when a user pastes a 200-page document or a chat runs for an hour? The correct behaviour is a clear message or history trimming by a rule, not a 500 error or an answer cut off mid-sentence. You also check that the output token limit does not truncate JSON the UI depends on.

Вихідна ситуація. Компанія запускає бота, що відповідає про замовлення, доставку й повернення на основі бази знань (RAG) і має доступ до API статусу замовлень. Питання інтерв'юера — не «які метрики», а як зробити, щоб кожна зміна проходила оцінку автоматично і щоб рішення про реліз спиралося на дані.

The setting. The company launches a bot that answers questions about orders, delivery and returns from a knowledge base (RAG) and can call the order status API. The interviewer's question is not "which metrics" but how to make every change go through evaluation automatically and base the release decision on data.

Кроки. 1) З продуктом і підтримкою визначити ризики та «червоні лінії»: вигадані умови повернення, витік чужих замовлень, обіцянки компенсацій. 2) Зібрати golden set з 300–500 кейсів: реальні замасковані діалоги, крайові випадки, атаки, теги ризику. 3) Шари оцінки: детерміновані перевірки на кожен PR (хвилини), повний eval із суддею перед мерджем змін промпту, моделі чи індексу, людська оцінка вибірки щотижня. 4) Звіт baseline проти кандидата з гейтами. 5) Продакшн: логування з маскуванням, онлайн-метрики (оцінки користувачів, передача оператору), щотижневе поповнення набору з реальних провалів.

Steps. 1) Define risks and "red lines" with product and support: invented return terms, leaking other customers' orders, promises of compensation. 2) Build a golden set of 300–500 cases: real masked conversations, edge cases, attacks, risk tags. 3) Evaluation layers: deterministic checks on every PR (minutes), a full eval with a judge before merging prompt, model or index changes, weekly human rating of a sample. 4) A baseline vs candidate report with gates. 5) Production: logging with masking, online metrics (user ratings, hand-off to a human agent), a weekly top-up of the set from real failures.

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

Trade-offs. A full eval on every commit is expensive and slow, so it is tied to changes in the "AI part". A judge saves people's time but has to be calibrated, otherwise the pipeline stays nicely green on wrong data. In the first weeks after launch people review more conversations than seems necessary: that is how the set becomes realistic.

Суть атаки. Prompt injection (ін'єкція в промпт) — це коли користувач вписує у своє повідомлення інструкції, які мають переважити системний промпт: «ігноруй попередні правила», «ти тепер у режимі розробника», «виведи свої налаштування». Модель не має надійної межі між інструкціями розробника і даними користувача, бо для неї все це один потік токенів.

The attack. Prompt injection is when a user writes instructions into their message that are meant to override the system prompt: "ignore the previous rules", "you are now in developer mode", "print your configuration". The model has no reliable boundary between the developer's instructions and the user's data, because to it everything is a single stream of tokens.

Що саме може піти не так. Три наслідки: витік системного промпту або прихованих правил, обхід обмежень (бот каже те, що йому заборонено) і небажані дії, якщо модель має інструменти, — наприклад, запускає повернення коштів чи надсилає лист. Останнє найнебезпечніше, бо шкода виходить за межі тексту на екрані.

What can actually go wrong. Three outcomes: the system prompt or hidden rules leak, restrictions get bypassed (the bot says what it was told not to), and unwanted actions happen when the model has tools, such as triggering a refund or sending an email. The last one is the worst, because the damage leaves the text on the screen.

Як тестувати. Збираю набір атак за категоріями: пряме «ігноруй», рольова гра, прохання перекласти чи переказати інструкції, фальшиві службові мітки на кшталт «SYSTEM:», інша мова. У тестову збірку кладу унікальний канарковий рядок (canary) у системний промпт і перевіряю, що він ніколи не потрапляє у відповідь, а ризикові інструменти не викликаються.

How to test. I build a set of attacks by category: a plain "ignore", role play, asking the model to translate or paraphrase its instructions, fake service labels such as "SYSTEM:", a different language. In the test build I put a unique canary string into the system prompt and check that it never reaches the reply and that risky tools are never called.

Підводні камені. Один прогін нічого не доводить: відповіді недетерміновані, тож кожну атаку запускаю кілька разів і рахую частку вдалих обходів (attack success rate). Ввічлива відмова в тексті теж не гарантія — дивлюся ще й на виклики інструментів у логах.

Pitfalls. A single run proves nothing: replies are non-deterministic, so I run each attack several times and track the attack success rate. A polite refusal in the text is not a guarantee either; I also look at tool calls in the logs.

Уточнення. Повністю закрити ін'єкції формулюванням промпту неможливо, тому тест перевіряє і захист поза моделлю: мінімальні права інструментів, підтвердження людиною для ризикових дій, фільтр вихідного тексту.

Follow-up. You cannot fully close injection through prompt wording, so the test also covers defences outside the model: least-privilege tools, human confirmation for risky actions, and an output filter.

Чим відрізняється від прямої. У непрямій ін'єкції (indirect prompt injection) атакує не користувач, а контент, який модель читає під час роботи: сторінка, яку асистент підсумовує, лист у скриньці, PDF у базі знань RAG, коментар у тікеті. Інструкцію ховають у білий текст, HTML-коментар, alt-текст картинки чи метадані, і людина її не бачить, а модель бачить.

How it differs from direct injection. In indirect prompt injection the attacker is not the user but content the model reads while working: a web page the assistant summarises, an email in the inbox, a PDF in the RAG knowledge base, a comment in a ticket. The instruction hides in white text, an HTML comment, image alt text or metadata, invisible to a person but visible to the model.

Чому це серйозніше. Жертва — чесний користувач, який просто попросив «підсумуй мої листи». Якщо в агента є інструменти, отруєний лист може змусити його переслати дані, створити задачу чи вставити у відповідь посилання-картинку з даними в параметрах URL: клієнт автоматично завантажить її, і дані підуть на чужий сервер без жодного кліку.

Why it is more serious. The victim is an honest user who just asked "summarise my emails". If the agent has tools, a poisoned email can make it forward data, create a task, or put an image link into the reply with data in the URL parameters: the client loads the image automatically and the data goes to someone else's server without a single click.

Як я будую тести. Готую набір отруєних фікстур для кожного каналу, звідки модель бере текст, і кладу їх у тестову скриньку, індекс чи мок веб-сторінки. Потім даю звичайні завдання й перевіряю: підсумок не містить виконаної інструкції, немає викликів інструментів, яких не просив користувач, у відповіді немає посилань на домени поза allowlist.

How I build the tests. I prepare a set of poisoned fixtures for every channel the model reads from and place them in a test mailbox, the index or a mocked web page. Then I give ordinary tasks and check: the summary does not carry out the hidden instruction, there are no tool calls the user did not ask for, and the reply has no links to domains outside an allowlist.

Компроміси. Агресивний фільтр, що викидає документи зі словом «ignore», ламає легітимний контент і дає хибне відчуття захищеності, бо атаку легко перефразувати. Надійніші архітектурні рішення: позначати зовнішній контент як дані з нижчим рівнем довіри, не рендерити зовнішні картинки автоматично, вимагати підтвердження людиною для дій, ініційованих після читання чужого тексту. Мій тест має перевіряти саме ці бар'єри, а не лише текст відповіді.

Trade-offs. An aggressive filter that drops documents containing the word "ignore" breaks legitimate content and gives a false sense of safety, because the attack is easy to rephrase. Sturdier architectural measures are: mark external content as lower-trust data, do not render external images automatically, and require human confirmation for actions triggered after reading someone else's text. My tests should verify exactly those barriers, not only the reply text.

Терміни. Jailbreak — спроба змусити модель порушити власну політику безпеки: рольова гра («уяви, що ти персонаж без обмежень»), гіпотетичні сценарії, розбиття шкідливого запиту на невинні частини. Guardrails (запобіжники) — шари навколо моделі: фільтр вхідних запитів, обмеження тематики, фільтр вихідного тексту на токсичність і персональні дані, правила для інструментів.

Terms. A jailbreak is an attempt to make the model break its own safety policy: role play ("pretend you are a character with no limits"), hypothetical framing, splitting a harmful request into innocent pieces. Guardrails are the layers around the model: an input filter, topic restrictions, an output filter for toxicity and personal data, and rules for tools.

Дві метрики, а не одна. Перша — частка вдалих атак (attack success rate), її треба тримати близькою до нуля. Друга — частка хибних відмов (false refusal rate): бот відмовляється від легітимного запиту, бо в ньому страшні слова, як-от «як убити процес Python». Команда, яка міряє лише першу, отримує бота, що боїться всього і дратує клієнтів.

Two metrics, not one. The first is the attack success rate, which should stay near zero. The second is the false refusal rate: the bot refuses a legitimate request because it contains scary words, like "how do I kill a Python process". A team that measures only the first ends up with a bot that is afraid of everything and annoys customers.

Як організувати. Тестую guardrails на двох рівнях. Юніт-рівень: сам фільтр отримує таблицю входів і очікуваних рішень, це швидко й детерміновано. Наскрізний рівень: той самий набір іде через увесь продукт, бо фільтр може бути правильним, а обхід станеться через інструмент чи іншу мову. Кожен знайдений обхід переходить у регресійний набір.

How to organise it. I test guardrails at two levels. Unit level: the filter alone gets a table of inputs and expected decisions, which is fast and deterministic. End-to-end level: the same set goes through the whole product, because the filter may be right while the bypass happens through a tool or another language. Every bypass we find goes into the regression set.

Підводні камені. Набір атак старіє: нові техніки з'являються постійно, тому його оновлюють з публічних джерел і власних інцидентів. І не варто перевіряти відмову точним текстом — перевіряйте категорію рішення (відмова, відповідь, перенаправлення).

Pitfalls. The attack set goes stale: new techniques keep appearing, so it is refreshed from public sources and your own incidents. And do not check a refusal by exact wording; check the category of the decision (refuse, answer, redirect).

Звідки витікає. Джерел кілька: системний промпт із внутрішніми правилами чи адресами; дані іншого клієнта, якщо індекс RAG чи пам'ять сесій спільні для кількох тенантів; секрети, які випадково потрапили в контекст (ключі в конфігу, токени в логах); дані, запам'ятовані моделлю під час донавчання (fine-tuning) на реальних розмовах; і власні логи продукту, куди промпти пишуться з персональними даними.

Where it leaks from. There are several sources: a system prompt with internal rules or addresses; another customer's data when the RAG index or session memory is shared between tenants; secrets that slipped into the context (keys in a config, tokens in logs); data memorised during fine-tuning on real conversations; and the product's own logs, where prompts are stored with personal data.

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

Canary strings. The most practical technique is to plant unique strings that exist nowhere else: in the system prompt, in tenant A's documents, in fine-tuning examples. Then, acting as tenant B or a plain user, I ask questions that invite the model to reveal that data and search for canaries in replies, logs and analytics. A canary that turns up shows the leak path beyond doubt.

Приклад із практики. У мультитенантному помічнику пошук по індексу фільтрувався за тенантом, але кеш відповідей ключувався лише текстом запитання. Однакове питання двох компаній отримувало закешовану відповідь із документами першої. Канарковий тест знайшов це за кілька хвилин, а ручне тестування пропускало, бо тестувальники працювали в одному тенанті.

An example from practice. In a multi-tenant assistant, index search was filtered by tenant, but the answer cache was keyed on the question text only. The same question from two companies got the cached answer with the first company's documents. A canary test found it in minutes, while manual testing missed it because testers worked inside a single tenant.

Підводні камені. Перевіряти лише відповідь недостатньо: витік у лог чи сторонню систему моніторингу теж витік. І канарки мають бути в тестовому середовищі, а не в продакшн-даних.

Pitfalls. Checking only the reply is not enough: a leak into a log or a third-party monitoring system is still a leak. And canaries belong in the test environment, not in production data.

Що це. Упередженість (bias) — систематична помилка моделі, через яку одна група людей отримує гірші результати: частіше відмову в кредиті, гіршу якість розпізнавання мовлення чи інший тон відповіді. Найчастіше причина — нерепрезентативні навчальні дані або ознаки-проксі, що непрямо кодують захищену ознаку, як-от поштовий індекс замість етнічності.

What it is. Bias is a systematic model error that gives one group of people worse outcomes: more loan rejections, worse speech recognition quality or a different tone of reply. The usual cause is unrepresentative training data or proxy features that indirectly encode a protected attribute, such as a postcode standing in for ethnicity.

Як міряти. Рахую метрики окремо для кожної групи: частку позитивних рішень (selection rate), точність, частку хибнопозитивних і хибнонегативних. Демографічний паритет (demographic parity) порівнює частки позитивних рішень, вирівняні шанси (equalized odds) — частки помилок. Для LLM зручні контрфактичні пари: той самий запит, де змінено лише ім'я чи стать, і порівняння відповідей.

How to measure. I compute metrics per group: selection rate, accuracy, false positive and false negative rates. Demographic parity compares selection rates, and equalized odds compares error rates. For LLMs counterfactual pairs are handy: the same request with only the name or gender changed, and a comparison of the replies.

Підводні камені. Прибрати захищену ознаку з даних недостатньо — модель відновлює її через проксі. Різні визначення справедливості в загальному випадку не можна задовольнити одночасно, тому вибір метрики і порогу — рішення продукту, юристів і доменних експертів, а не лише QA. Правило чотирьох п'ятих (відношення часток не менше 0,8) — поширена евристика, а не універсальний закон.

Pitfalls. Removing the protected attribute from the data is not enough, because the model rebuilds it through proxies. Different fairness definitions generally cannot all be satisfied at once, so choosing the metric and threshold is a decision for product, legal and domain experts, not QA alone. The four-fifths rule (a ratio of rates of at least 0.8) is a common heuristic, not a universal law.

Уточнення. Малі групи дають шумні метрики: перед висновком перевірте розмір вибірки і довірчі інтервали.

Follow-up. Small groups produce noisy metrics: check the sample size and confidence intervals before drawing conclusions.

Від принципів до вимог. Відповідальний AI (responsible AI) зазвичай описують принципами: справедливість, прозорість, приватність, безпека, надійність, підзвітність. Для QA принцип сам по собі не тестується — його треба перетворити на вимогу з метрикою і порогом: «різниця FPR між групами не більше 5 п. п.», «0 канарок у відповідях», «частка токсичних відповідей на adversarial-наборі нижче 0,5%».

From principles to requirements. Responsible AI is usually described through principles: fairness, transparency, privacy, safety, reliability, accountability. A principle cannot be tested as such, so QA turns it into a requirement with a metric and a threshold: "FPR gap between groups at most 5 points", "zero canaries in replies", "toxic reply rate on the adversarial set below 0.5%".

Model card. Це короткий документ про модель, запропонований у статті «Model Cards for Model Reporting» (Mitchell та ін., 2019): призначення і небажані сценарії використання, дані для навчання й оцінювання, метрики загалом і за групами, відомі обмеження, етичні міркування. Для QA це одночасно тестовий базис і об'єкт перевірки: кожне число в картці має відтворюватися з нашого eval-прогону.

Model card. This is a short document about a model, proposed in the paper "Model Cards for Model Reporting" (Mitchell et al., 2019): intended and out-of-scope uses, training and evaluation data, overall and per-group metrics, known limitations, ethical considerations. For QA it is both a test basis and something to verify: every number on the card should be reproducible from our eval run.

Сценарій. Продукт хоче запустити скоринг заявок, дедлайн через місяць, а eval показує, що для однієї вікової групи recall на 12 п. п. нижчий. Мій хід: зафіксувати розрив у model card як відоме обмеження, запропонувати варіанти (додаткові дані, окремий поріг, ручний перегляд для цієї групи) і винести рішення на власника ризику. Приховати проблему заради дедлайну — найгірший варіант, бо картка стане неправдивою.

Scenario. Product wants to launch application scoring in a month, and the eval shows recall is 12 points lower for one age group. My move: record the gap on the model card as a known limitation, propose options (more data, a separate threshold, manual review for that group) and take the decision to the risk owner. Hiding the problem for the deadline is the worst option, because the card becomes untrue.

Компроміс. Кожен додатковий гейт уповільнює реліз, тому гейти ранжують за ризиком: для чат-бота про рецепти досить токсичності й приватності, для кредитного скорингу — повний набір із зовнішнім аудитом.

Trade-off. Every extra gate slows the release, so gates are ranked by risk: a recipe chatbot needs toxicity and privacy checks, while credit scoring needs the full set plus an external audit.

Що перевіряємо. Пояснюваний AI (XAI) дає відповідь на питання «чому модель так вирішила»: важливість ознак (permutation importance), локальні пояснення методами SHAP чи LIME, карти уваги для зображень. Тестування пояснюваності перевіряє, що ці пояснення правдиві щодо реальної логіки моделі, стабільні і не спираються на заборонені чи безглузді ознаки.

What we check. Explainable AI (XAI) answers "why did the model decide this": feature importance (permutation importance), local explanations from SHAP or LIME, attention or saliency maps for images. Explainability testing checks that these explanations are faithful to the model's real logic, stable, and not based on forbidden or nonsensical features.

Практичні перевірки. Правдоподібність: доменний експерт дивиться на топ ознак і каже, чи це має сенс. Стабільність: два майже однакові клієнти мають отримати схожі пояснення. Заборонені ознаки: захищені атрибути і їхні проксі мають мати близьку до нуля важливість. Санітарна перевірка: якщо перемішати ваги чи мітки, пояснення має змінитися — інакше метод пояснює дані, а не модель.

Practical checks. Plausibility: a domain expert looks at the top features and says whether they make sense. Stability: two nearly identical customers should get similar explanations. Forbidden features: protected attributes and their proxies should have near-zero importance. Sanity check: if you randomise the weights or labels, the explanation should change; otherwise the method explains the data, not the model.

Сценарій і компроміс. Модель відмов у кредиті має найкращий AUC, але 30% важливості припадає на «кількість змін адреси», яка корелює з міграційним статусом. Можна прийняти кращу метрику і юридичний ризик або прибрати ознаку і втратити трохи якості. У регульованих доменах, де клієнту треба пояснити причину відмови, я б рекомендував друге і зафіксував рішення.

Scenario and trade-off. A loan decision model has the best AUC, but 30% of its importance sits on "number of address changes", which correlates with migration status. You can accept the better metric and the legal risk, or drop the feature and lose a little quality. In regulated domains where the customer must be told why they were declined, I would recommend the latter and record the decision.

Про LLM. Пояснення, яке генерує сама мовна модель («я вирішив так, тому що...»), не гарантовано відображає її справжній процес, тому його не можна приймати як доказ без перевірки.

About LLMs. An explanation a language model writes about itself ("I decided this because...") is not guaranteed to reflect its actual process, so it cannot be accepted as evidence without verification.

Перші години — стримування. Клієнт виклав у соцмережі скріншот, де бот процитував внутрішню інструкцію з тарифами для партнерів. Спочатку зупиняю кровотечу: вимикаю бота прапором або переводжу на безпечний режим без бази знань, повідомляю security і DPO, зберігаю логи до того, як їх перезапише ротація. Якщо в контексті могли бути секрети, їх ротують негайно, не чекаючи аналізу.

First hours: containment. A customer posted a screenshot where the bot quoted an internal partner pricing guide. First I stop the bleeding: switch the bot off with a flag or move it to a safe mode without the knowledge base, notify security and the DPO, and preserve the logs before rotation overwrites them. If secrets could have been in the context, they are rotated immediately without waiting for the analysis.

Масштаб і причина. Далі відповідаю на питання «що, кому і з якого часу». Шукаю в логах цитати з того самого документа, дату, коли він потрапив в індекс, і всі сесії, де він повертався. Типова причина — конвеєр індексації забрав розділ вікі без фільтра за правами доступу, а пошук не враховував роль користувача. Іноді причина інша: внутрішні посилання прямо в системному промпті.

Scope and cause. Next I answer "what, to whom, and since when". I search the logs for quotes from that document, the date it entered the index, and every session where it was returned. A typical cause: the indexing pipeline picked up a wiki section without an access-rights filter, and retrieval ignored the user's role. Sometimes the cause is different, such as internal links sitting right in the system prompt.

Внесок QA. Відтворюю інцидент тестом, який червоний на старій конфігурації: питання, що витягує документ, і канарка в тестовій копії. Разом із розробниками перевіряю виправлення (фільтрація за правами на етапі пошуку, allowlist джерел для індексації, вихідний фільтр внутрішніх маркерів) і додаю в регресію цілий клас подібних питань, а не одне.

QA's contribution. I reproduce the incident with a test that is red on the old configuration: a question that pulls the document out, plus a canary in a test copy. With the developers I verify the fix (rights filtering at retrieval time, an allowlist of indexable sources, an output filter for internal markers) and add a whole class of similar questions to the regression set, not just one.

Після інциденту. Постмортем без пошуку винних, моніторинг частоти цитування документів з внутрішніх просторів і правило: нове джерело даних для бота проходить рев'ю доступів до індексації.

After the incident. A blameless postmortem, monitoring of how often documents from internal spaces are cited, and a rule that any new data source for the bot passes an access review before it is indexed.

Основа. Модель не можна оцінювати на даних, на яких вона вчилася: там вона може просто запам'ятати відповіді. Тому дані ділять на навчальну (train), валідаційну (validation, для підбору гіперпараметрів) і тестову (test) частини, і тестову відкривають лише для фінальної оцінки. Якщо дивитися на тест під час налаштування, він поступово перетворюється на ще один валідаційний набір.

The basics. A model cannot be evaluated on the data it learned from, because there it may simply have memorised the answers. So data is split into training, validation (for tuning hyperparameters) and test sets, and the test set is opened only for the final evaluation. If you keep looking at the test set while tuning, it gradually turns into another validation set.

Перенавчання (overfitting). Ознака — великий розрив між якістю на train і на test: 99% проти 81% означає, що модель вивчила шум. Недонавчання (underfitting) видно, коли обидві цифри низькі. Для QA це проста автоматична перевірка з порогом розриву.

Overfitting. The sign is a large gap between training and test quality: 99% versus 81% means the model has learned noise. Underfitting shows when both numbers are low. For QA this becomes a simple automated check with a gap threshold.

Метрики під задачу. Accuracy обманює на незбалансованих класах: якщо шахрайських транзакцій 1%, модель «завжди ні» має 99% accuracy і нуль користі. Тоді дивляться на precision (скільки знайденого справді шахрайство) і recall (скільки шахрайства знайдено), а баланс між ними обирають за ціною помилки.

Metrics that fit the task. Accuracy lies on imbalanced classes: if 1% of transactions are fraud, an "always no" model has 99% accuracy and zero value. Then you look at precision (how much of what was flagged is really fraud) and recall (how much fraud was caught), and choose the balance by the cost of each error.

Підводні камені. Витік даних між частинами: дублікати записів, одні й ті самі клієнти в train і test, ознака, обчислена з майбутнього. Для часових рядів ділять за часом, а не випадково, інакше модель «бачить майбутнє» і метрики завищені.

Pitfalls. Leakage between splits: duplicate records, the same customers in both train and test, a feature computed from the future. For time series, split by time rather than at random, otherwise the model "sees the future" and the metrics are inflated.

Чому це головне. У звичайному коді баг сидить у логіці; в ML логіку модель виводить із даних, тож брудні дані дають «правильно навчену» неправильну модель. Помилкові мітки, дублікати, пропуски, які заповнили нулями, зсув одиниць виміру (кілограми проти грамів) — усе це модель сумлінно вивчить і не повідомить про проблему.

Why it matters most. In ordinary code the bug lives in the logic; in ML the model derives its logic from the data, so dirty data yields a "correctly trained" wrong model. Wrong labels, duplicates, gaps filled with zeros, a unit mix-up (kilograms versus grams) — the model learns all of it diligently and never reports a problem.

Що перевіряти. Схему (колонки й типи), пропуски за колонками, допустимі діапазони (вік від 18 до 100), унікальність ключів, розподіл міток (чи не зник рідкісний клас), узгодженість між полями (дата закриття не раніше за дату відкриття) і перетин між train і test. Такі перевірки запускаються в конвеєрі перед кожним навчанням, як юніт-тести перед збіркою.

What to check. The schema (columns and types), missing values per column, valid ranges (age from 18 to 100), key uniqueness, label distribution (has the rare class disappeared), cross-field consistency (a close date not before the open date) and overlap between train and test. These checks run in the pipeline before every training, like unit tests before a build.

Приклад. Після зміни в ETL поле «сума» почало приходити в копійках замість гривень. Модель перенавчилася, метрики на новому тесті навіть трохи зросли, бо тест теж був у копійках, а в продакшні через старий клієнтський формат прогнози стали хаотичними. Перевірка діапазону на вході конвеєра зупинила б навчання одразу.

Example. After an ETL change the "amount" field started arriving in cents instead of whole currency units. The model was retrained, metrics on the new test set even rose slightly because the test set was in cents too, while in production, where an older client format was still used, predictions became chaotic. A range check at the pipeline entrance would have stopped training immediately.

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

Pitfalls. Checking only the schema is not enough: types match while values are wrong. And the rules must be agreed with the data owners, otherwise the thresholds are made up.

Два види дрейфу. Дрейф даних (data drift) — зміна розподілу вхідних ознак у продакшні порівняно з навчальними даними: прийшла нова аудиторія, змінився сезон, оновився мобільний клієнт. Дрейф концепції (concept drift) — зміна зв'язку між входом і правильною відповіддю: шахраї змінили тактику, і ті самі ознаки тепер означають інше. Обидва тихо знижують якість моделі без жодної помилки в логах.

Two kinds of drift. Data drift is a change in the distribution of input features in production compared with the training data: a new audience arrives, the season changes, the mobile client is updated. Concept drift is a change in the relationship between input and the correct answer: fraudsters change tactics and the same features now mean something else. Both quietly lower model quality without a single error in the logs.

Як виявляти. Для числових ознак — тест Колмогорова-Смирнова (KS) або індекс стабільності популяції (PSI), для категоріальних — PSI чи хі-квадрат. Поширене емпіричне правило для PSI: до 0,1 — стабільно, 0,1–0,25 — помірний зсув, понад 0,25 — суттєвий. Дрейф концепції видно лише за справжніми мітками, які часто приходять із затримкою, тому дивляться також на розподіл прогнозів моделі.

How to detect it. For numeric features, the Kolmogorov-Smirnov (KS) test or the population stability index (PSI); for categorical ones, PSI or chi-square. A common rule of thumb for PSI: below 0.1 is stable, 0.1 to 0.25 a moderate shift, above 0.25 a significant one. Concept drift shows up only against true labels, which often arrive with a delay, so the distribution of the model's predictions is watched as well.

Підводні камені. На мільйонах записів p-value тесту KS майже завжди мізерне, навіть для неважливого зсуву, тому дивіться на розмір ефекту (статистику KS чи PSI), а не лише на значущість. Дрейф не завжди означає «перенавчай негайно»: спершу перевірте, чи впала якість і чи це не баг у збиранні даних.

Pitfalls. On millions of records the KS p-value is almost always tiny, even for an irrelevant shift, so look at the effect size (the KS statistic or PSI), not only at significance. Drift does not always mean "retrain now": first check whether quality has actually dropped and whether it is not simply a bug in data collection.

Уточнення. Еталоном для порівняння зазвичай служить навчальна вибірка або стабільний період продакшну, і його треба явно зафіксувати й версіонувати.

Follow-up. The reference is usually the training sample or a stable production period, and it should be pinned and versioned explicitly.

Суть. Adversarial-тестування шукає входи, які навмисно сконструйовані, щоб обдурити модель: кілька непомітних для людини пікселів змушують класифікатор бачити замість знака «стоп» знак обмеження швидкості; заміна кириличної «о» на латинську проводить спам повз фільтр; одна додана фраза змінює тональність відгуку для аналізатора. Це перевірка стійкості (robustness), а не звичайної точності.

The idea. Adversarial testing looks for inputs deliberately crafted to fool the model: a few pixels invisible to a human make a classifier read a stop sign as a speed limit sign; swapping a Cyrillic "o" for a Latin one gets spam past a filter; one added phrase flips a review's sentiment for an analyser. It checks robustness, not ordinary accuracy.

Де критично. Медична діагностика, автономне водіння, антифрод, модерація контенту, біометрія — там, де є мотивований зловмисник або ціна помилки висока. Для внутрішнього класифікатора тікетів глибоке adversarial-тестування зазвичай не окупається, досить базового набору шуму й опечаток.

Where it is critical. Medical diagnosis, autonomous driving, anti-fraud, content moderation, biometrics: wherever there is a motivated attacker or a high cost of error. For an internal ticket classifier, deep adversarial testing usually does not pay off; a basic set of noise and typos is enough.

Сценарій. Команда антиспаму хвалиться 98% точності на тестовому наборі. Я додаю набір трансформацій, які реально використовують спамери: гомогліфи, пробіли всередині слів, zero-width символи, заміна букв цифрами. Точність на трансформованих прикладах падає до 71% — це і є реальний рівень захисту. Висновок — нормалізація тексту перед моделлю і доповнення навчальних даних такими прикладами (adversarial training).

Scenario. The anti-spam team is proud of 98% accuracy on the test set. I add a set of transformations spammers actually use: homoglyphs, spaces inside words, zero-width characters, digits for letters. Accuracy on the transformed examples drops to 71%, and that is the real level of protection. The conclusion is text normalisation before the model and augmenting training data with such examples (adversarial training).

Компроміс. Стійкість часто коштує трохи якості на чистих даних і часу навчання, тому поріг стійкості погоджують як окрему вимогу, а не вимагають «стійкості до всього».

Trade-off. Robustness often costs a little clean-data quality and training time, so a robustness threshold is agreed as a separate requirement rather than demanding "robustness to everything".

Проблема, яку воно вирішує. Для багатьох AI-систем немає оракула: невідомо, яким має бути «правильний» опис фото чи точна оцінка ціни квартири. Метаморфне тестування (metamorphic testing) перевіряє не саму відповідь, а зв'язок між відповідями на пов'язані входи — метаморфні відношення. Правильне значення знати не потрібно, досить знати, як воно має змінитися.

The problem it solves. Many AI systems have no oracle: nobody knows the "correct" caption for a photo or the exact price estimate for a flat. Metamorphic testing checks not the answer itself but the relationship between answers to related inputs, the metamorphic relations. You do not need the correct value, only how it should change.

Приклади відношень. Поворот фото кота на 5° не змінює клас «кіт». Додана нейтральна фраза «Відгук написано у вівторок» не змінює тональність. Збільшення площі квартири при інших рівних не зменшує прогнозовану ціну. Перефразоване фактичне питання до чат-бота дає ту саму суть відповіді. Порушення відношення — знайдений баг без жодного очікуваного значення.

Example relations. Rotating a cat photo by 5° keeps the class "cat". Adding a neutral sentence like "The review was written on a Tuesday" keeps the sentiment. Increasing a flat's area with everything else equal does not lower the predicted price. A paraphrased factual question to a chatbot yields the same substance. A violated relation is a found bug with no expected value at all.

Сценарій. Модель оцінки нерухомості проходить усі метрики на тесті, але метаморфний тест показує: для 3% квартир додавання балкона знижує ціну. Розбір виявив, що ознака «балкон» у навчальних даних корелювала зі старим житловим фондом. Звичайна перевірка MAE цього не помітила б, бо середня помилка залишилася гарною.

Scenario. A property valuation model passes every metric on the test set, but a metamorphic test shows that for 3% of flats adding a balcony lowers the price. Analysis revealed that "balcony" in the training data correlated with old housing stock. A plain MAE check would never notice, because the average error stayed good.

Компроміси. Відношення треба формулювати з доменними експертами: хибне відношення дає хибні баги. Для недетермінованих моделей порівнюю з допуском і на кількох прогонах, а не на точну рівність.

Trade-offs. Relations must be written with domain experts, since a wrong relation produces false bugs. For non-deterministic models I compare with a tolerance and over several runs, not on exact equality.

Ідея. У класичному мутаційному тестуванні в код вносять дрібні зміни (мутанти) і дивляться, чи тести їх «вбивають». Для ML те саме питання звучить так: чи помітить наш набір перевірок, якщо модель чи дані зіпсуються? Мутують дані (шум у мітках, перемішана ознака, прибраний клас), модель (шум у вагах, вимкнений шар) або код підготовки (інша нормалізація, зсув колонок).

The idea. In classic mutation testing you make small changes to code (mutants) and see whether the tests "kill" them. For ML the same question becomes: would our set of checks notice if the model or the data got corrupted? You mutate the data (label noise, a shuffled feature, a removed class), the model (noise in weights, a disabled layer) or the preprocessing code (different normalisation, shifted columns).

Що це дає. Метрика — частка вбитих мутантів (mutation score) для нашого eval-набору і гейтів. Якщо перемішування ключової ознаки не валить жодної перевірки, eval-набір надто легкий або пороги надто м'які. Так ми оцінюємо якість самих тестів, а не моделі.

What it gives you. The metric is the share of killed mutants (mutation score) for our eval set and gates. If shuffling a key feature does not fail a single check, the eval set is too easy or the thresholds too lenient. This measures the quality of the tests themselves, not of the model.

Сценарій. Команда впевнена у своїх гейтах перед релізом моделі. Я роблю десять мутантів: 10% і 30% шуму в мітках, перемішаний дохід, зсув колонок на одну позицію, відсутній рідкісний клас тощо. Шість із десяти проходять усі гейти, бо поріг accuracy стоїть на 0,7, а recall для рідкісного класу не перевіряється взагалі. Висновок — підняти пороги і додати перевірки за класами та зрізами.

Scenario. The team trusts its gates before a model release. I build ten mutants: 10% and 30% label noise, shuffled income, columns shifted by one position, a missing rare class, and so on. Six of the ten pass all gates, because the accuracy threshold is 0.7 and rare-class recall is not checked at all. The conclusion: raise the thresholds and add per-class and per-slice checks.

Компроміси. Кожен мутант потребує перенавчання чи повного прогону, тому це дорого: запускають вибірково, перед важливими змінами гейтів, а не на кожен коміт. Частина мутантів еквівалентна (не змінює поведінку), і їх треба відсіювати вручну.

Trade-offs. Every mutant needs retraining or a full run, so it is expensive: it is done selectively, before important gate changes, not on every commit. Some mutants are equivalent (they do not change behaviour) and have to be filtered out by hand.

Shadow mode. Нова модель отримує копію реального трафіку і рахує відповіді паралельно зі старою, але користувач бачить лише відповідь старої. Прогнози нової моделі логуються і порівнюються: частка розбіжностей, латентність, помилки, розподіл відповідей. Ризику для користувачів немає, зате немає й реакції користувачів — ми не знаємо, чи нова відповідь їм сподобалася б.

Shadow mode. The new model receives a copy of real traffic and computes answers in parallel with the old one, but users see only the old model's reply. The new model's predictions are logged and compared: disagreement rate, latency, errors, output distribution. There is no risk to users, but also no user reaction: we do not know whether they would have liked the new answer.

A/B-тест. Трафік ділиться: наприклад, 50% користувачів бачать модель A, 50% — модель B. Порівнюють бізнесові й продуктові метрики: конверсію, частку ескалацій до оператора, оцінки відповідей. Висновок роблять лише після досягнення заздалегідь розрахованого розміру вибірки і статистичної значущості, а не тоді, коли графік «виглядає добре».

A/B test. Traffic is split: for example 50% of users see model A and 50% model B. Business and product metrics are compared: conversion, escalation-to-agent rate, answer ratings. A conclusion is drawn only after reaching a sample size calculated in advance and statistical significance, not when the chart "looks good".

Як поєднувати. Типовий порядок: офлайн-eval на golden set, потім shadow для технічних ризиків (латентність, падіння, дивні відповіді на реальних даних), потім A/B з малою часткою трафіку (canary) і поступовим розширенням. QA відповідає за план і гейти кожного етапу та за перевірку, що розподіл трафіку і логування працюють правильно.

How to combine them. A typical order: offline eval on the golden set, then shadow for technical risks (latency, crashes, odd answers on real data), then an A/B test with a small traffic share (canary) and gradual expansion. QA owns the plan and the gates for each stage and checks that traffic splitting and logging work correctly.

Підводні камені. У shadow не можна виконувати побічні дії нової моделі (листи, списання), інакше «тінь» стає реальністю. В A/B — «підглядання» (peeking) за результатом і ранні зупинки, які дають хибні перемоги.

Pitfalls. In shadow mode the new model's side effects (emails, charges) must never execute, otherwise the "shadow" becomes real. In A/B tests the trap is peeking at results and stopping early, which produces false wins.

Чому моніторинг — частина тестування. Для AI-функції реліз не кінець перевірок: дані змінюються, провайдер моделі оновлює версію, користувачі знаходять сценарії, яких не було в eval-наборі. Тому частина якості перевіряється вже в продакшні, і QA допомагає визначити сигнали, пороги й реакцію на алерти.

Why monitoring is part of testing. For an AI feature, release is not the end of the checks: data changes, the model provider updates versions, users find scenarios that were not in the eval set. So part of quality is verified in production, and QA helps define the signals, thresholds and the response to alerts.

Чотири групи сигналів. Якість: оцінки користувачів (палець угору чи вниз), частка ескалацій до людини, повторні запитання тією ж сесією, оцінки LLM-судді на випадковій вибірці розмов. Безпека: частота спрацювань guardrails, знайдені персональні дані, скарги. Експлуатація: p95 латентності, помилки й таймаути провайдера, кількість токенів і вартість на запит. Дані: дрейф тем і мов, частка запитів поза продуктом.

Four groups of signals. Quality: user ratings (thumbs up or down), escalation-to-human rate, repeated questions in the same session, LLM-judge scores on a random sample of conversations. Safety: guardrail trigger rate, detected personal data, complaints. Operations: p95 latency, provider errors and timeouts, tokens and cost per request. Data: drift in topics and languages, share of out-of-scope requests.

Приклад. Після тихого оновлення моделі провайдером відповіді стали на 40% довшими: латентність і вартість зросли, а частка ескалацій не змінилася. Без моніторингу токенів на запит це помітили б лише в рахунку наприкінці місяця.

Example. After the provider quietly updated the model, answers became 40% longer: latency and cost went up while the escalation rate stayed flat. Without monitoring tokens per request, this would have been noticed only in the invoice at the end of the month.

Підводні камені. Лайки дають мало сигналу — оцінку ставить малий і упереджений відсоток користувачів, тому їх поєднують із вибірковою експертною перевіркою. Логи розмов для аналізу мають проходити маскування персональних даних і мати строк зберігання.

Pitfalls. Thumbs give little signal, since a small and biased share of users rate answers, so they are combined with sampled expert review. Conversation logs used for analysis must go through personal data masking and have a retention period.

Від «перевірити фічу» до «визначити якість». Для AI-функції немає готового очікуваного результату, тому перша задача QA — разом із продуктом сформулювати, що таке «добре»: метрики, пороги, неприйнятні помилки. Без цього команда сперечатиметься про враження від демо, а не про дані.

From "test the feature" to "define quality". An AI feature has no ready-made expected result, so QA's first job is to work out with product what "good" means: metrics, thresholds, unacceptable errors. Without that the team argues about impressions from a demo instead of data.

Що QA будує. Eval-набір із реальних і граничних випадків, adversarial-набір для безпеки, перевірки упередженості, регресію на кожну зміну моделі, промпту чи даних, гейти релізу і план викатки (shadow, A/B), а також моніторинг у продакшні з алертами. QA також оцінює ризики: що станеться, якщо модель помилиться, і чи є людина в циклі там, де помилка дорога.

What QA builds. An eval set from real and edge cases, an adversarial set for safety, bias checks, regression on every change to the model, prompt or data, release gates and a rollout plan (shadow, A/B), plus production monitoring with alerts. QA also assesses risk: what happens if the model is wrong, and whether a human is in the loop where an error is expensive.

Сценарій. Продукт хоче за три тижні запустити AI-підсумки звернень клієнтів для операторів. Я пропоную: перший тиждень — 150 реальних звернень із підсумками від досвідчених операторів як golden set і рубрика оцінки; другий — прогони, аналіз помилок, тести на персональні дані й ін'єкції; третій — shadow на частині операторів з оцінкою корисності. Реліз лише за виконання гейтів, а якщо не встигаємо — обмежений пілот замість повного запуску.

Scenario. Product wants to launch AI summaries of customer tickets for agents in three weeks. I propose: week one, 150 real tickets with summaries written by experienced agents as the golden set, plus a scoring rubric; week two, runs, error analysis, personal data and injection tests; week three, shadow mode for some agents with a usefulness rating. Release only if the gates pass, and if we run out of time, a limited pilot instead of a full launch.

Компроміс. Надто суворі гейти вбивають корисну фічу, надто м'які — репутацію. Моя позиція — прозоро показати ризики з цифрами і дати бізнесу ухвалити рішення, а не блокувати реліз одноосібно.

Trade-off. Gates that are too strict kill a useful feature; gates that are too soft kill the reputation. My position is to show the risks transparently with numbers and let the business decide, not to block the release single-handedly.