Шість концепцій ШІ, які підкажуть вам, що перевірити перед тим, як довіряти відповіді
Токени, вікна контексту, температура, галюцинації, RAG та агенти пояснюються як інструменти перевірки, щоб ви могли виявляти помилки, контролювати витрати та оцінювати твердження продуктів ШІ.
Ви передаєте штучному інтелекту звіт, і отримуєте відповідь у вигляді добре опрацьованого резюме, яке містить графік, якого немає в жодному місці документа. Коли ви запитуєте про це, асистент вибачається та пропонує інший графік. Чи бракувало інформації, чи зазнала невдачі процедура пошуку, чи просто число було вигадане? Шість основних концепцій, зрозумілих через рішення, на які вони впливають, дозволяють замінити запитання „Чому він бреше?“ на точне діагностичне запитання, а також допомагають контролювати витрати та оцінювати твердження постачальників.
Чому скептицизм є розумним стандартом
Недовіра до результатів роботи ШІ є поширеною навіть серед тих, хто використовує їх щодня. У опитуванні розробників Stack Overflow 2025 року 46% учасників, яким поставили запитання про точність, сказали, що не довіряють результатам ШІ, на відміну від 33%, які їм довіряли, загалом було отримано 33 244 відповіді (результати опитування). Прочитайте це уважно: тут записані думки розробників, а не показники точності моделей, і це не є репрезентативною вибіркою населення. Проте це все ж відображає реальну напругу – люди використовують ці інструменти, але все одно не вірять у все, що вони кажуть.
По-перше, застосовуйте таку саму критичність до заголовків
Тексти про ШІ часто обіцяють, що знання кількох термінів дозволяє опинитися „попереду 90% людей“. Це звучить як результат дослідження, але без відповідного дослідження це просто маркетинг у вигляді статистики. Слід поставити очевидні запитання: попереду кого, як це вимірюється, з якими учасниками та де опубліковані результати? Відсутність оцінки, вибірки чи даних означає, що цей відсоток не має підстав. Це не робить усі пояснення, пов’язані з ним, хибними, і нічого не говорить про наміри когось; це просто означає, що ця цифра не має жодної ваги.
Знання визначень — це початкова точка. Їх застосування, розпізнавання винятків та перевірка реальних результатів — це окремі навички, і жодна з них не вимірюється привабливим відсотком.
Та сама дисципліна стосується тверджень про те, що один запит може замінити цілу команду, або що певний інструмент у десять разів прискорює роботу всіх. Запитуйте про конкретне завдання, базові параметри, спосіб його оцінки та наявні обмеження. Одна вражаюча демонстрація не може підтвердити загальний результат. Хороший заголовок — це добре; проблеми починаються, коли твердження є більш точним, ніж докази, які його підтримують. Дотримуйтеся цього посібника за тими самими стандартами.
1. Токени: справжній розмір завдання
Токен — це одиниця тексту, яку насправді обробляє модель мови. Залежно від токенайзера токен може бути цілим словом, фрагментом слова, знаком пунктуації або іншою частиною тексту, причому токенайзер присвоює кожній частині числовий ідентифікатор.
Не існує жорсткого правила на кшталт „одне слово дорівнює одному токену“. У огляді токенайзерів Hugging Face описано кілька підходів, зокрема кодування пар байтів, WordPiece та методи, пов’язані з SentencePiece; одне й те саме речення може бути розділене досить по-різному різними токенайзерами. Мови, відмінні від англійської, код та незвичайний форматування часто використовують більше токенів на слово.
Чому це має значення, стає зрозумілим з такого запитання:
Які три скарги клієнтів зустрічалися найчастіше?
Саме запитання дуже коротке. Але якщо для його відповіді потрібно прочитати тисячі повідомлень підтримки, це запитання є похибкою округлення у загальному обсязі вхідних даних. Як ілюстрація, а не як точний показник: 400 повідомлень по приблизно 150 токенів кожне вже дають 60 000 токенів ще до будь-яких інструкцій чи іншого контексту.
Отже, важливе питання полягає не у довжині вашого запиту, а у кількості матеріалу, який система змушена обробляти. Оскільки ціни, час виконання та обмеження контексту зазвичай виражаються у токенах, саме це впливає на вартість. Перед обробкою великого документа видаліть повторювані підписи електронних листів, нерелевантні додатки та дублікати записів, які не надають жодних доказів, залишивши лише те, від чого справді залежить відповідь.
2. Вікно контексту: що модель може бачити в одному запиті
Вікно контексту обмежує кількість матеріалу, з яким може працювати модель у одному запиті. Інструкції системи, історія розмов, отримані уривки та будь-які інші дані використовують цей ліміт; спосіб підрахунку токенів вихідного тексту залежить від моделі та API. Документація Google щодо довгого контексту показує, як великі вікна дозволяють працювати з великими колекціями тексту та інших медіафайлів.
Однак прийняття документа — це не те саме, що надійне використання кожної релевантної деталі в ньому. Дослідження 2023 року „Lost in the Middle“ тестувало функції відповідей на запитання з кількох документів та пошуку ключ-значення та виявило, що для досліджуваних моделей точність часто знижувалась, коли релевантна інформація знаходилась посеред довгого вхідного тексту, а не ближче до початку чи кінця. Вважайте це історичним доказом тих конкретних експериментів, а не показником для сучасних моделей, проте урок щодо перевірки залишається актуальним.
Продукти чату також рідко поводяться так, як передбачає їхній інтерфейс. Коли розмова перевищує обсяг вікна, додаток не зобов’язаний просто видаляти найстаріші повідомлення; він може замість цього створити узагальнення, вибрати чи знайти попередні матеріали. Те, що ви бачите в історії чату, — це не надійний образ того, що потрапляє до моделі під час кожного виклику.
На практиці:
- Для тривалих завдань слід підтримувати короткий, чіткий опис поточних вимог та рішень, а також повторювати його кожного разу, коли це необхідно.
- Якщо висновок залежить від одного конкретного уривку, попросіть асистента процитувати чи знайти цей уривок перед тим, як робити висновок.
Велике вікно надає системі простору для роботи; це не свідчить про те, що система використала правильні докази.
3. Температура: контроль над різноманітністю, а не правдою
На кожному етапі генерації модель оцінює кожен можливий наступний токен. Параметр температури змінює розподіл ймовірностей, який використовується для вибору токенів на основі цих оцінок: низькі значення концентрують ймовірність на найбільш імовірних варіантах, тоді як високі значення розподіляють її між більшою кількістю варіантів. У документації Hugging Face температура описується разом із схожими параметрами керування генерацією, такими як вибір токенів за принципом top-p та жадібне декодування.
Привабливим спрощенням є твердження, що «низька температура означає точність». Це не так. Якщо найймовірніша відповідь моделі є неправильною, зменшення різноманітності не допоможе додати бракуючу інформацію; це лише призведе до того, що та сама помилка буде повторюватися ще частіше. Так само підвищення температури не гарантує кращих ідей, а лише більш різноманітних.
Два протилежні завдання демонструють цю різницю. Створення п’яти назв для вигаданого кафе вигідно завдяки різноманітності. Вилучення номерів рахунків-фактур вигідно завдяки послідовному форматуванню, але ці номери все одно мають відповідати реальним рахункам-фактурам, і температура тут не має жодного значення.
Розглядайте температуру як один з параметрів для експериментування та оцінюйте його з урахуванням фактичних потреб завдання. Для вилучення даних підраховуйте кількість неправильних та відсутніх полів; під час мозкового штурму перевіряйте, чи є ідеї як корисними, так і справді різними одна від одної. Прогнозованість та точність потребують окремої перевірки.
4. Галюцинація: результат, який виходить за межі наявних доказів
Тут під галюцинацією розуміється створений контент, який є вигаданим, фактично неправильним або не підтверджується матеріалом, який він нібито описує. Впевнений тон ускладнює його виявлення, але впевненість не є частиною визначення; нейтральне формулювання також може бути не підтвердженим.
Очевидним прикладом є вигадана наукова стаття. Більш тонким та поширеним прикладом є справжня стаття, процитована щодо результату, якого вона ніколи не повідомляла, і яка залишається непоміченою при швидкому огляді саме через наявність цитати.
У бенчмарку TruthfulQA було представлено 817 запитань у 38 категоріях, створених на основі поширених хибних уявлень. Під час початкової оцінки найкраща протестована модель давала правильні відповіді на 58% запитань, порівняно з 94% у людей. Це історичні результати досліджень 2021 та 2022 років, які не є показником сучасних чат-ботів та не відображають загальний рівень галюцинацій. Це дослідження демонструє, що моделі можуть вірно відтворювати хибні переконання, які зустрічаються у текстах, написаних людьми.
Якщо у резюме є несподівана цифра, обов’язково запитайте про її джерело:
Вкажіть джерельний уривок, наведіть дату та контингент, який було виміряно. Якщо уривок не підтверджує цю цифру, позначте її як непідтверджену.
Потім перевірте посилання на власні очі. Будь-яка цитата, яку створює модель, є лише твердженням, поки ви не підтвердите як існування сторінки, так і те, що вона дійсно містить конкретне речення.
5. RAG: отримання доказів перед відповіддю
Метод Retrieval-augmented generation поєднує крок пошуку з кроком генерації. Система шукає відповідний матеріал у зовнішньому сховищі, передає його моделі та просить її дати відповідь на основі цього матеріалу.
Впливова стаття про RAG 2020 року поєднала заздалегідь навчений генератор із засобом пошуку в індексі Вікіпедії, і після опублікування досягла найкращих результатів у трьох тестах якості запитань з відкритими доменами. Ці результати описують одну дослідницьку систему, а не гарантію якості для кожного продукту, що має позначку RAG.
Уявімо собі співробітника, який запитує, скільки днів у нього є на подання заяви на відшкодування витрат. Хороша система отримує поточні правила та дає відповідь на їхній основі. Якщо ж вона отримує правила минулого року, навіть добре написаний текст не виправить помилку — відповідь буде зрозумілою, але неправильною. Саме тому проблеми RAG зазвичай легше діагностувати на кожному етапі, ніж просто дивлячись на кінцеву відповідь; цей підхід розглядається у оцінці RAG за етапами виникнення помилок.
Варто роз’яснити два хибні уявлення:
- RAG не залежить від наявності спеціалізованого сховища векторів. Крок пошуку може полягати у класичному зіставленні ключових слів, оцінці схожості векторних представлень або у поєднанні обох методів, і огляд RAG від Microsoft розглядає ці варіанти разом із важливістю підготовки контенту для ефективного пошуку.
Щоб оцінити будь-якого асистента з обробки документів, поставте два окремі запитання: чи знайшов він правильний уривок, та чи його відповідь вірно відображає цей уривок?
6. Агенти: системи, які обирають свої наступні кроки
Термін „агент“ використовується досить широко, тому конкретне розмежування допомагає. Посібник Anthropic зі створення ефективних агентів описує робочі процеси як системи, що дотримуються заздалегідь визначених шляхів коду, тоді як агенти дозволяють моделі динамічно керувати власним процесом та використанням інструментів.
Фіксований алгоритм роботи може вилучати поля з рахунку-фактури, перевіряти їх та зберігати запис завжди в цьому порядку. Співробітник, який стикається з неповною рахунком-фактурою, може самостійно вирішити відкрити додаток, знайти відповідне замовлення та надіслати запит щодо відсутніх деталей.
Тож ключове питання полягає у тому: які рішення та дії дозволено приймати системі? Написана відповідь та здійснена повернення грошей мають зовсім різні наслідки. Співробітнику потрібні чітко визначені повноваження, помітні результати кожної дії та можливість зупинитися, коли він не може визначити наступний логічний крок.
Більше кроків також означає більше шансів на невдачу. Як спрощений приклад, якщо для виконання завдання потрібно десять кроків, і кожен з них успішно виконується незалежно з ймовірністю 95%, то шанс того, що всі десять кроків вдасться виконати, становить 0,95 у десятому степені, що приблизно дорівнює 60%. На практиці кроки агента залежать один від одного, а повторні спроби змінюють ці розрахунки, тож це скоріше інтуїтивне розуміння компонування ризиків, ніж стандарт для оцінки. Практичний наслідок полягає у перевірці того, чи було завдання виконано правильно в цілому, включаючи усі побічні ефекти, а не того, чи здавалися окремі кроки правдоподібними. Для більш детального розгляду самого циклу дивіться розділ «Розуміння AI-агентів: цілі, інструменти, пам’ять та цикл агента».
Чек-лист із шістьома запитаннями для реальних завдань
Кожна концепція відповідає запитанню, яке можна поставити до будь-якого реального завдання:
- Токени: скільки матеріалу насправді потребує система для обробки цього завдання, і що можна видалити без втрати доказів?
- Вікно контексту: на якому уривку ґрунтувалася відповідь, і чи справді її використала система?
- Температура: чи стосується це завдання різноманітності чи послідовності, і чи перевірялися коректність та передбачуваність окремо?
- Галюцинації: де саме знаходиться джерело кожного несподіваного твердження, і чи підтверджує воно те, що стверджує відповідь?
- RAG: чи був отриманий правильний, актуальний документ, і чи був він точно представлений?
- Агенти: що дозволено робити системі, і чи було повністю виконано завдання, включаючи його побічні ефекти, правильно?
Підсумок
Спробуйте застосувати ці запитання до реального завдання — наприклад, підсумку документа, зміни коду чи відповіді клієнтській підтримці — з відкритим поруч джерельним матеріалом. Визначте, на яких даних ґрунтувалося інструмент, які висновки він зробив самостійно та які дії фактично виконав. Регулярне виконання цього дозволяє дізнатися більше про надійність інструменту, ніж будь-яка демонстрація чи статистика у заголовках, а також перетворює нечітку недовіру на конкретні, вирішувані проблеми: надмірний обсяг вхідних даних, пропущений уривок, неправильний документ, недоступна інформація чи агент з занадто великими повноваженнями.