Пилотният проект с ИИ мина добре на демонстрацията. Как да разберете дали върши работа, преди да го разширите?

За 1 минута

Демонстрацията показва какво може ИИ с подбрани примери. Пилотният проект трябва да отговори на друг въпрос: дали върши ежедневната работа по-добре, по-евтино или по-бързо, отколкото се върши днес, със случаите, които наистина пристигат. За да разберете това, са нужни три неща и е добре да ги определите преди началото: колко струва и колко време отнема работата днес, извадка от реални случаи — включително трудните — и писмени критерии, които казват кой резултат води до разширяване, до настройка или до спиране.

Представете си обслужваща компания, която всеки ден получава стотици запитвания от клиенти: въпроси за фактури, промени в данни, удостоверения. Тя е измислена, но прилича на много други. Екип от петима души ги чете, класифицира и пише отговора.

Доставчик предлага пилотен проект с ИИ: системата класифицира всяко запитване и подготвя готов отговор, който човек преглежда и изпраща. На демонстрацията пред комитета ИИ решава двадесет примера без засечка. Отговорите са ясни, тонът е правилен и всичко отнема секунди. Някой пита: «кога го пускаме за всички?».

Въпросът е естествен. И точно на него е добре още да не се отговаря, защото демонстрацията не даде данните за отговор.

Тази статия е за онзи, който трябва да одобри — или да спре — преминаването на пилотен проект с ИИ към експлоатация. Тя защитава една идея: пилотният проект се измерва спрямо днешната работа, с реални случаи и критерий за приемане, определен преди началото; не спрямо демонстрацията. Не е нужно да разбирате от модели, за да я приложите; нужно е да знаете как се работи днес.

Какво не може да каже една демонстрация

Демонстрацията е направена, за да покаже. Примерите са подбрани, сценарият е изчистен и никой не пита колко е струвал всеки отговор, нито колко време е отнело на човека да го прегледа. Това не я прави подвеждаща: прави я непълна за вземане на решение.

Затова демонстрацията сама по себе си дава ограничени доказателства за три неща:

• Случаите, които наистина пристигат. Ръководството за оценки на OpenAI препоръчва тестовете да отразяват способността на модела «в разпределения от реалния свят» (свободен превод) [3]: случаите със смесицата и трудността, които има в работата, а не онези, които изглеждат най-добре.
• Вариацията. Същото ръководство предупреждава, че генеративният ИИ «е променлив»: моделът може да даде различни отговори на един и същ вход и затова традиционните софтуерни тестове не са достатъчни (свободен превод) [3]. Двадесет попадения са начален сигнал; не стигат, за да се прецени как ще се държи системата при обема на един месец.
• Точката за сравнение. «Мина добре» — в сравнение с какво? Без да знаете как излиза днес същата работа, няма как да кажете дали ИИ я подобрява.

Стъпка 1 · Измерете днешната работа, преди да пипнете каквото и да е

Правилата за машинно обучение, които Google публикува, поставят това на първо място: преди да формализирате какво ще прави системата, проектирайте и внедрете показателите и записвайте колкото се може повече от сегашната система (свободен превод) [1]. Причината е проста: ако «преди» не се измери, «след» няма с какво да се сравни.

В измислената компания да се измери днешният ден означава да се отговори, с данни от нормален месец:

• Колко запитвания пристигат и от какви видове?
• Колко време отнема средно един отговор, от пристигането до изпращането?
• Колко излизат с грешка и трябва да се поправят, и колко водят до оплакване?
• Колко струва обслужването на едно, като се събере времето на хората?

Същият документ на Google съдържа още едно правило, което си струва да се прочете преди всеки пилотен проект: не се страхувайте да пуснете продукт без машинно обучение, защото едно добре обмислено просто правило може да даде повече от модел без данни (свободен превод) [1]. Понякога измерването на днешния ден показва, че половината запитвания се решават с шаблон за отговор и едно правило. И това е добра находка: ИИ остава за онова, което наистина се нуждае от него.

Стъпка 2 · Напишете критериите преди началото

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

Документацията на Anthropic за онези, които създават с нейните модели, изисква критерии за успех с четири черти: конкретни («да класифицира правилно запитванията», а не «добро представяне»), измерими (с числа или добре определени скали), постижими (основани на реални отправни точки, а не на желаното) и уместни (в съответствие с нуждите на бизнеса) (свободен превод) [2]. Предлага също сравнение с отправна точка — базов модел или предишна версия — и отделно измерване на граничните случаи [2].

На езика на комитета критериите се побират в една таблица. Тази е пример, с измислени числа за илюстрация; числата на всяка компания идват от стъпка 1:

Праговете са илюстративни: всяка компания ги определя според процеса, според това кой отговаря за него и според прага на риск, който е одобрила. Два детайла на тази таблица са по-важни от числата. Първо, тя отделя събитията с голямо въздействие от леките грешки: тон, който може да се подобри, се поправя; изпращането на данни на един клиент до друг — не. Второ, тя има колона за спиране: ако не е записано кой резултат прекратява пилотния проект, той не спира.

Стъпка 3 · Тествайте с реални случаи, включително трудните

С написаните критерии се подготвя заедно с екипа, който върши работата, извадка от реални случаи, която прилича на пристигащата работа — например тези от един нормален месец, в пропорцията, в която пристигат —, а не двадесетте от демонстрацията. Три правила я правят полезна за решението:

• Отделете случаите за настройка от случаите за решение. Първите служат за прецизиране на инструкциите; вторите се пазят настрана и се използват само накрая. Документацията на Anthropic ги нарича задържани оценки (held-out) [2].
• Напишете предварително кой отговор се смята за правилен, кой го оценява и как се решава разминаване между двама проверяващи.
• Решете писмено кои данни влизат: кой може да ги вижда, каква информация се скрива или заменя за теста и кой е разрешил тази употреба. Това, че в работата има контроли, само по себе си не казва, че извадката може да излезе към тестова среда или към доставчик.

Профилът за генеративен ИИ на NIST, американския институт за стандарти и технологии, е ръководство за доброволно ползване, което го казва така във функцията за измерване: представянето на системата се измерва и демонстрира при условия, подобни на тези на експлоатацията, а мерките се документират (свободен превод) [4]. Ръководството на OpenAI предлага и да се записва всичко по време на теста, за да се извлекат от тези записи нови тестови случаи [3].

В тази извадка е добре да се отдели група трудни случаи — дори да са малко, включително тези с голямо въздействие — и да се измери отделно: двусмисленото запитване, това с две теми, това на ядосания клиент, това, което споменава данни, които ги няма в системата. Там пилотният проект печели или губи доверието на екипа, който ще го използва.

Стъпка 4 · Измерете колко струва, а не само колко улучва

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

• Времето за преглед. Ако човекът отделя почти толкова време да прегледа отговора, колкото да го напише, спестяването е малко.
• Цената на обработката на случай. Използването на модела, според договора или инфраструктурата на компанията, плюс прегледа от човек. Умножено по реалния обем на един месец, това число може да промени решението. Началната подготовка се представя отделно, за да не се смесва с цената на работата.
• Случаите, които предава на човек. Добре е ИИ да разпознава какво не бива да решава; ако предава почти всичко, значи не спестява работа.
• Работата по поддръжката. Някой трябва всеки месец да преглежда резултатите, да настройва инструкциите и да следи какво се променя в системите, от които ИИ взема данни.

Стъпка 5 · Решете писмено: разширяване, настройка или спиране

Накрая резултатът се сравнява с критериите и се взема едно от три решения, писмено:

• Разширяване, ако изпълнява договорените цели и остава в рамките на одобрения праг на риск.
• Настройка и повторение, ако е близо и има ясна причина, която може да се поправи: инструкция, липсващи данни, вид запитване, което е добре да се остави настрана.
• Спиране, ако не изпълнява и няма ясна причина. Навременното спиране също е добър резултат: то предотвратява разширяването на един разход.

Сред предложените действия NIST препоръчва резултатите от тестовете преди внедряването да се споделят с онези, които имат правомощието да одобрят пускането в експлоатация (свободен превод) [4]. На езика на комитета: решението за разширяване се взема от онзи, който отговаря за работата, с документа с резултатите в ръка, а не със спомена от демонстрацията. Същият протокол посочва кой отговаря за процеса, как се докладва и обработва инцидент и кога е следващият преглед. Праговете на риск се разглеждат отделно от целите за спестяване или бързина.

Сигналите, че пилотният проект още не е готов

Пет въпроса за следващия комитет

1. Колко време отнема, колко струва и колко грешки има днес работата, която пилотният проект иска да подобри? Ако няма число, това е първата задача.
2. Кой резултат би ни накарал да разширим и кой — да спрем, и записано ли е това отпреди началото?
3. С какви случаи е тествано: подбрани или реална извадка от един месец, с трудните, измерени отделно?
4. Имало ли е събития с голямо въздействие и колко струва всеки случай, като се съберат обработката и прегледът от човек?
5. Кой подписва решението за разширяване, с какъв документ, и кой отговаря за процеса, след като влезе в експлоатация?

Ако на няколко отговора отговорът е «не знам», пилотният проект още не е готов за решение; готов е за измерване.

Откъде да започнете тази седмица

Напишете критериите на пилотния проект на една страница, дори ако той вече тече. Четири блока:

• Днешната работа: обем, време, грешки и цена за един нормален месец.
• Показателите: от три до пет, с днешната стойност, с това, което води до разширяване, и с това, което води до спиране.
• Извадката: откъде идват тестовите случаи, кой ги избира и кои са трудните.
• Решението: кой го взема, на коя дата и с какъв документ.

Ако страницата не може да се попълни, това вече казва какво липсва, преди да се разшири.

Какво прави Hábil

В Hábil изграждаме по мярка ИИ, който работи с данните и правилата на вашите системи.

Ако пилотният ви проект има нужда от тези критерии за приемане, предложението е в Hábil AI. Преди да започне работа, се изпробва с реалните ви случаи и с уговорен критерий за приемане. Пътят е: диагностика → предложение с обхват, цена и риск → тест с критерий за приемане → експлоатация. Можем да работим с ИИ, който вече имате – ChatGPT, Copilot, Gemini или Claude –, или с такъв, инсталиран на вашите сървъри; а това, което движи пари или данни, се изпълнява с одобрение от човек.

Разговорът може да започне от страницата с критериите, дори наполовина попълнена: кой процес, как се измерва днес и какъв резултат се очаква. С това заедно преглеждаме дали си струва да се продължи, да се настрои или да се започне с друг процес. Пишете ни в WhatsApp; за да защитим информацията, не споделяйте по този канал данни на клиентите си или на системите си: в разговора ще договорим канала за случая.

Поискайте първия си разговор, безплатно.

Прегледани на 12 ноември 2026 г. Всеки източник е с ниво на доверие: високо (прочетен първичен източник).