Як зменшити галюцинації в LLM

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

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

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

Важливо розуміти: це не твердження про те, як насправді влаштовані нейронні мережі. Усередині трансформера немає явної реалізації правила Байєса — там градієнтний спуск, матриці ваг і механізм attention. Байєсівський фреймворк тут — це аналітична модель, яка допомагає передбачати та пояснювати поведінку LLM, не претендуючи на опис внутрішньої механіки.

Чому ця модель корисна? Тому що вона дивовижно точно описує те, що ми спостерігаємо на практиці:

  • Моделі змінюють свої відповіді залежно від контексту (промпту).
  • Few-shot приклади «перенавчають» модель на ходу.
  • Одні й ті самі знання можуть проявлятися по-різному залежно від формулювання запиту.

У цій аналітичній моделі процес генерації тексту можна описати так:

  • Апріор — статистичні закономірності, які модель засвоїла під час навчання на мільярдах токенів. Це її «базове уявлення» про те, які слова після яких зазвичай йдуть.
  • Спостереження (промпт) — конкретний контекст, який ви надаєте зараз.
  • Апостеріор — оновлений ймовірнісний розподіл для наступного токена, який враховує і загальні знання, і ваш конкретний запит.

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

Але це лише частина картини. Галюцинації виникають також через:

  • систематичні упередження в тренувальних даних;
  • здатність моделі «домислювати» деталі, яких вона не знає;
  • конфлікт між тим, що модель бачила під час навчання, і тим, що ви просите зараз.

У цій статті я покажу, як розуміння LLM через байєсівський підхід допомагає:

  • побачити логіку за появою галюцинацій;
  • зрозуміти, чому одні промпти працюють краще за інші;
  • отримати конкретні інструменти для зменшення ймовірності помилок: від налаштування temperature до використання RAG.

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

Ймовірнісна природа тексту

Щоб зрозуміти, як LLM генерують текст, почнемо з ідеалізованої картини. Уявімо, що десь існує повний корпус усіх текстів світу — позначимо його S. Кожне слово (точніше, токен) зі словника M, де |M| = m, може з’явитися після будь-якої послідовності попередніх слів з певною ймовірністю.

Формально це можна представити як умовний ймовірнісний розподіл:

P(наступне_слово | попередня_послідовність)

Для кожної можливої послідовності слів цей розподіл задає вектор ймовірностей:

де:

Це і є багатономіальний розподіл: m можливих варіантів, кожен зі своєю ймовірністю.

Приклад:

Візьмемо слово Dragon. Без додаткового контексту воно може вести у різні напрямки.

Розподіл після «Dragon»:

  • «fire» — високу ймовірність (фентезі, міфологія);
  • «fruit» — помірну ймовірність (їжа);
  • «dance» — низьку ймовірність (культурні традиції);
  • «banana» — майже нульову.

Але якщо ми додамо контекст, картина різко змінюється:

  • «Dragon fire» наступні слова: «burned», «scorched», «illuminated» (домінує тематика вогню та руйнування).
  • «Dragon fruit» → наступні слова: «smoothie», «tastes», «contains» (зміщення в кулінарію).

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

Ймовірнісна матриця

Формально, весь корпус S породжує імовірнісну матрицю розміром:

де кожен рядок відповідає певній послідовності токенів, кожен стовпець — можливому наступному токену, а в клітинках — ймовірності.

У випадку LLM зі словником у 50,000 токенів та контекстом у 8,000 токенів ця матриця мала б розмір:

що перевищує кількість атомів у Всесвіті.

На практиці вона дуже розріджена: більшість рядків відповідають нісенітниці з ймовірністю 0, а навіть у «правдоподібних» рядках лише невелика кількість слів отримують ненульову ймовірність.

Важливо: ця «матриця» — теоретична абстракція, а не реальна структура даних. Вона:

  • допомагає зрозуміти логіку генерації тексту;
  • показує, чому задача настільки складна;
  • ніколи не існує в пам’яті комп’ютера;
  • не описує, як насправді працює нейромережа.

Якщо розглядати всі можливі комбінації контекстів довжиною 8000, то теоретично маємо не звичайну матрицю, а гіперматрицю (тензор) розмірності 8001. Для інтуїції називаємо це просто «ймовірнісною матрицею».

Як це працює під час генерації

Користувач вводить запит, наприклад:

Модель знаходить відповідний рядок у матриці й формує багатономіальний розподіл наступного токена:

Слова «fire» чи «smoke» отримують високу ймовірність, а «banana» чи «car» — майже нульову.

Один токен вибирається (залежно від параметрів temperature або top-p), запит доповнюється цим токеном, і процес повторюється.

Підсумок

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

На практиці це неможливо через неповноту навчальних даних і обмежені ресурси, тому модель завжди працює з наближенням. І саме в цих «щілинах» між ідеальною теорією та реальною практикою з’являються помилки та галюцинації.

Як працюють реальні LLM

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

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

1. Неповний корпус

Жодна модель не може бачити всі тексти світу. Навчання відбувається на підмножині:

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

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

2. Представлення через ембединги

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

  • Кожен токен перетворюється на точку у багатовимірному просторі (наприклад, у 1024-вимірному).
  • Схожі слова розташовані близько: «dragon» і «wyvern».
  • Далекі слова розташовані окремо: «dragon» і «fruit».
  • Але коли вони з’єднуються у фразі «dragon fruit», контекст «перекидає» точку в зовсім інший регіон простору.

Байєсівська інтерпретація: ембединги — це компактне кодування апріора. Замість зберігання всіх можливих контекстів модель вивчає «універсальні смислові напрямки» в просторі. Але стиснення завжди означає втрату деталей.

3. Архітектура трансформера і механізм attention

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

Наприклад:
Промпт «The dragon breathes».

  • Якщо увага зосереджена на слові «dragon», найімовірнішим продовженням буде «fire».
  • Якщо на «breathes», то можливими варіантами стануть «heavily», «slowly», «quietly».

Байєсівська інтерпретація: attention — це спосіб динамічно оновлювати правдоподібність P(контекст | токен). Модель «вибирає», які частини промпту використати як спостереження для оновлення апостеріора.

4. Покрокове генерування

Процес утворює цикл:

  1. Користувач вводить промпт (наприклад, «The dragon breathes»).
  2. Промпт перетворюється в ембединги.
  3. Модель обчислює ймовірнісний розподіл наступного токена.

  4. З цього розподілу вибирається один токен (залежно від temperature, top-p чи top-k).
  5. Новий токен додається до запиту.
  6. Кроки повторюються, доки не буде згенеровано завершення.

Байєсівська інтерпретація: кожен крок — це послідовне байєсівське оновлення:

І так далі...

5. Де виникають галюцинації

  • Неповний корпус → у матриці бракує правильного «піку».
  • Ембединги → стискання інформації робить різні контексти надто схожими.
  • Attention → модель може обрати «не ті» акценти у запиті.
  • Семплінг → при високій ентропії модель фактично «вгадує».

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

Байєсівське навчання і генерація тексту

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

Формула Байєса виглядає так:

— апріор: наскільки часто токен k траплявся у світі текстів, на яких навчалася модель.

— правдоподібність: наскільки добре токен k «вписується» у контекст:

(prompt).

— апостеріор: оновлена оцінка, яка враховує і попередні знання, і новий контекст.

Це означає: модель не просто «підбирає слово за частотою», а постійно перераховує ймовірності, виходячи з даних, які ми їй даємо.

1. Як це працює всередині

Важливий момент: LLM не зберігає прямі таблиці частот слів. Це було б неможливо — і занадто громіздко. Замість цього всі слова і послідовності представляються у вигляді векторів у багатовимірному просторі — ембедингів.

  1. Промпт перетворюється на вектори.
  2. Модель шукає «сусідні» ембединги у просторі, які вона бачила під час навчання.
  3. Це дає оцінку правдоподібності.
  4. На основі цієї оцінки модель оновлює ймовірність кожного можливого наступного токена.

Інакше кажучи, ембединги — це спосіб наближено реалізувати правило Байєса у високих вимірах.

Тобто кожне слово, яке ми бачимо у відповіді LLM, є не просто «випадковим вгадуванням», а результатом математично обґрунтованого процесу:

апріор + нові дані → апостеріор → вибір токена

2. Few-shot як оновлення апостеріора

Коли ви додаєте приклади в промпт (few-shot), модель поводиться так, ніби отримала додаткові спостереження, що коригують її попередні уявлення. Цей ефект зручно описувати через мультиноміальний розподіл з апріором Діріхле.

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

Позначення:

— параметри апріора Діріхле для m можливих варіантів (це «псевдолічильники», або вага попередніх знань моделі).

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

— сумарна сила апріора.

— загальна кількість прикладів у запиті.

Байєсівське оновлення

Після прочитання прикладів апостеріорна ймовірність варіанта k дорівнює:

Тобто нова ймовірність — це «попередня вага»

плюс реальні нові свідчення:

поділені на загальну масу (попередні знання + усі нові приклади). Знаменник нормалізує розподіл, щоб сума ймовірностей дорівнювала 1.

Інтуїція

поводиться як кількість «віртуальних» спостережень, які модель ніби вже бачила під час навчання.

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

— якщо мала, то кілька прикладів різко змінюють розподіл; якщо велика, щоб переламати апріор, потрібно більше прикладів.

— формула не залежить від порядку прикладів (обмінність): важливі лише підрахунки.

Для двох варіантів (бінарний випадок) ця ж ідея зводиться до Beta—Binomial і дає ті самі оновлення.

Зв’язок із практикою LLM

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

у формулі вище — маса апостеріора зміщується в їхній бік.

Приклад 1

Уявімо, що в нас є три можливі варіанти відповіді: A, B і C.
Без додаткових знань (апріор) ми вважаємо їх однаково ймовірними:

А тепер користувач дає моделі два приклади, де правильна відповідь — B. Це можна розглядати як дві нові «спостережені події». Тоді, згідно з формулою Байєса, апостеріорні ймовірності обчислюються так:

де:

— ваги апріора (спочатку = 1), а

— кількість нових прикладів.

Ми отримуємо:

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

Це і є суть few-shot навчання: модель оновлює свої уявлення про ймовірності, спираючись на кілька додаткових спостережень.

Приклад 2: Dragon

Апріор:
P(fire) = 0.50, P(fruit) = 0.20, P(dance) = 0.10, решта = 0.20

Контекст: «She sliced the dragon ...»

Правдоподібність: L(fruit)=0.80, L(fire)=0.05, L(dance)=0.05

Апостеріор:
P(fruit|контекст) ≈ 0.84
P(fire|контекст) ≈ 0.13
P(dance|контекст) ≈ 0.03

Модель упевнено вибирає «dragon fruit».

Але для «The dragon of democracy ...» розподіл стає пласким — кілька слів мають приблизно однакову ймовірність, і тоді зростає ризик галюцинацій.

3. Ентропія як індикатор

Ентропія (з інформаційної теорії) — це міра невизначеності ймовірнісного розподілу. Для випадкової величини X з розподілом

ентропія визначається як:

  • Якщо ентропія низька → розподіл «гострий», одна подія має високу ймовірність, інші — майже нуль. Це означає, що модель впевнена у виборі.
  • Якщо ентропія висока → розподіл «плаский», кілька подій мають схожі ймовірності. Це ситуація, коли модель змушена «вгадувати», і ризик галюцинацій зростає.

Приклади:

  • Розподіл (0.95, 0.03, 0.02) → низька ентропія, модель майже завжди вибере перший варіант.
  • Розподіл (0.34, 0.33, 0.33) → висока ентропія, вибір невизначений, і тут найчастіше виникають галюцинації.

4. Чому великі моделі кращі у in-context learning

Великі мовні моделі значно краще адаптуються до few-shot прикладів, ніж малі. Навіть 2-3 приклади можуть різко змінити їхню поведінку. Чому? Байєсівська інтерпретація дає інтуїтивне пояснення через концепцію «сили апріора».

Приклади:

Розглянемо просту ситуацію з двома класами А і B, для яких апріорна ймовірність задається бета-розподілом з параметрами (α, β).

Формула для очікуваної апостеріорної ймовірності класу B після того, як ми дали n прикладів цього класу:

Тепер уявімо два випадки:

1. (α+β) мале → апріор «слабкий»

У моделі ще немає стійкого уявлення про розподіл. Тоді навіть кілька прикладів у промпті швидко змінюють ваги. Уже 2-3 додаткових приклади можуть різко перекинути розподіл на користь нового варіанта.

2. (α+β) велике → апріор «сильний»

У моделі закладено багато «віртуальних спостережень», і вона впевненіша у своєму попередньому розподілі. Тоді, щоб змістити його, треба набагато більше нових прикладів.

У великих мовних моделей (мільярди параметрів) апріори поводяться ніби з «малим α+β» для локальних завдань: вони мають величезний запас знань, але конкретна вага для окремого випадку розподілена досить «розмито». Тому навіть кілька прикладів у промпті суттєво змінюють їхню поведінку.

Інакше кажучи:

  • маленька модель = «вперта», важко змінює свою думку;
  • велика модель = «гнучка», легко підлаштовується під новий контекст, навіть якщо він задається у кількох рядках промпту (важливо пам’ятати, що гнучкість — це не завжди добре, велика модель може легко «переконатися» неправильними прикладами так само легко, як і правильними, тому якість few-shot критично важлива).

Проте ця інтерпретація не є повним поясненням, адже реальні механізми (attention, gradient descent під час тренування) складніші; «сила апріора» — це метафора, а не вимірювана величина та різні завдання можуть мати різну «силу апріора» навіть в одній моделі. Однак модель дає корисну інтуїцію:

  • чому великі моделі гнучкіші;
  • чому few-shot працює краще з масштабом;
  • як приклади змінюють баланс між «загальними знаннями» і «локальним контекстом».

Методи зниження галюцинацій: байєсівський погляд

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

Якщо дивитися на LLM крізь цю призму, то стає зрозуміло: усі сучасні методи боротьби з галюцинаціями зводяться до основних завдань:

  • зменшення ентропії апостеріорного розподілу, щоб правильний варіант «виступав піком», а всі інші варіанти мали значно менші ймовірності;
  • верифікації апостеріора;
  • підсилення апріора.

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

1. Контроль ентропії через temperature, top-k та top-p

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

a. Temperature (температура)

Temperature керує тим, наскільки «гострим» або «пласким» буде розподіл. Формула перетворення:

  • T < 1 → розподіл стає гострішим: модель сильніше віддає перевагу найбільш ймовірним словам.
  • T > 1 → розподіл вирівнюється: зростає шанс вибору менш ймовірних слів.
  • T = 1 → без змін.

Зменшуючи T, ми концентруємо масу ймовірності на лідері; збільшуючи T, розмазуємо її між більшою кількістю варіантів.

Як температура впливає на галюцинації:

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

Практичні діапазони:

Тип завдання

Рекомендоване T

Фактологічні відповіді, інструкції, код

0.3-0.7

Змішаний режим (баланс коректності та варіативності)

0.7-1.0

Креативне письмо, брейншторм

1.0-1.3

Підсумок: температура — це простий і потужний важіль керування ентропією апостеріора. Зменшуємо T — знижуємо ризик галюцинацій і підвищуємо передбачуваність; збільшуємо T — підвищуємо різноманіття, але беремо на себе ризик «вигадок». Оптимум залежить від задачі, а найкращий результат часто дає комбінація: розумна T + топ-фільтри (роздивимось далі) + зовнішні джерела істинності.

b. Top-k sampling

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

Алгоритм:

  1. Сортуємо всі токени за ймовірністю.
  2. Беремо перші k токенів.
  3. Нормалізуємо їхні ймовірності, щоб сума = 1.
  4. Вибираємо з цього підмножинного розподілу.

Як top-k впливає на галюцинації:

  • k мале (наприклад, 5–20) → модель «залізно» обирає серед топових варіантів, зменшуючи ризик абсурдних продовжень.
  • k велике (сотні або тисячі) → зростає різноманіття, але ймовірність випадкових або «дивних» токенів знову підвищується.

k = 1 → це greedy decoding: завжди береться найімовірніший токен, текст стає передбачуваним і одноманітним.

Практичні діапазони:

Тип завдання

Рекомендоване k

Фактологічні відповіді, код

5-20

Змішаний режим

20-50

Креативні завдання

50-200

Підсумок: Top-k — це «ножиці» для ймовірнісного розподілу. Вони відсікають малоймовірні варіанти, зменшуючи ризик галюцинацій. Проте якщо k занадто мале — текст втрачає природність, якщо занадто велике — фільтр втрачає сенс. Найкраще працює у поєднанні з температурою: температура керує формою розподілу, а top-k — шириною вибору.

c. Top-p (nucleus sampling)

Top-p — це більш «розумний» варіант відсікання, ніж top-k. Замість того щоб брати фіксоване число токенів, ми беремо мінімальну кількість токенів, сума ймовірностей яких ≥ p (де p ∈ [0,1]). Чому це краще: Top-p адаптується до форми розподілу — бере багато токенів, коли розподіл плаский, і мало токенів, коли розподіл гострий.

Алгоритм:

  1. Сортуємо токени за ймовірністю.
  2. Обираємо найменший підмножинний набір токенів, у якого

  3. Нормалізуємо ймовірності всередині цього ядра («nucleus»).
  4. Вибір відбувається лише з цієї «кулі ймовірностей».

Як top-p впливає на галюцинації:

  • p мале (0.7–0.8) → ядро містить лише найімовірніші слова, ризик галюцинацій мінімальний.
  • p середнє (0.85–0.9) → ядро включає більше варіантів, текст стає багатшим, але зростає ризик рідкісних «дивних» вставок.
  • p велике (0.95–1.0) → ядро фактично охоплює весь словник, і фільтрація майже не працює — різко зростає ентропія та непередбачуваність.

Практичні діапазони:

Тип завдання

Рекомендоване p

Фактологічні відповіді, QA-системи

0.7-0.85

Змішаний режим

0.85-0.9

Художній текст, креатив

0.9-0.95

Підсумок: Top-p адаптивний: він «обрізає хвіст» розподілу не за кількістю токенів, а за їхньою сукупною вагою. Це робить його більш гнучким, ніж top-k, особливо коли розподіл має довгий хвіст із великою кількістю малоймовірних токенів. У поєднанні з температурою top-p дозволяє збалансувати точність і різноманіття, тримаючи ризик галюцинацій під контролем.

Практичні поради: як комбінувати температуру і топ-фільтри

1. Фактологічні відповіді (QA-системи, довідники, навчальні матеріали)

  • Ціль: мінімум вигадок, максимум передбачуваності.
  • Налаштування: температура T = 0.3–0.5, Top-p 0.7–0.85 (обрізаємо довгий «хвіст»), Top-k: невелике, k = 10–30.
  • Ефект: модель концентрується на найімовірніших словах і не «стрибає» у малоймовірні варіанти.

2. Інструкції, технічний текст, код

  • Ціль: послідовність і точність, але трохи гнучкості для варіацій у формулюваннях.
  • Налаштування: температура T = 0.5–0.7, Top-p 0.8–0.9, Top-k: середнє, k = 50–100.
  • Ефект: модель вибирає правильні варіанти, але не застрягає на єдиному «жорсткому» шаблоні.

3. Змішаний режим (клієнтська підтримка, рекомендаційні системи, контент-райтинг з фактами)

  • Ціль: збалансувати точність і цікавість у відповіді.
  • Налаштування: температура T = 0.7–0.9, Top-p 0.9, Top-k: від середнього до великого, k = 100–200.
  • Ефект: відповіді залишаються адекватними, але є місце для цікавих деталей.

5. Креативний текст, брейншторм, художнє письмо

  • Ціль: різноманіття ідеї важливіше за точність.
  • Налаштування: температура T = 1.0–1.3, Top-p 0.9–0.95, Top-k: велике (k ≥ 1000) або навіть відключене.
  • Ефект: модель дозволяє собі «ризиковані ходи» і вигадує несподіване, хоча й з більшим шансом на галюцинації.

6. Діалоги, чат-асистенти

  • Ціль: дружня розмова без надмірних вигадок.
  • Налаштування: температура T = 0.7, Top-p 0.85–0.9, Top-k: середнє, k = 50–200.
  • Ефект: текст живий і природний, але все ще контрольований.

7. Високоризикові застосування (медицина, фінанси, право)

  • Ціль: знизити ентропію максимально, щоб уникнути вигаданих фактів.
  • Налаштування: температура T = 0.2–0.3, Top-p 0.7, Top-k: дуже мале, k = 10–20.
  • Ефект: майже завжди обирається найправильніший, перевірений варіант. Текст може бути менш різноманітним, але надійним.

Важливо: у всіх пунктах вказано обидва параметри — Top-p та Top-k — але у більшості сучасних API (OpenAI, Anthropic) використовують щось одне, а не обидва одночасно. Тож рекомендую розглядати рекомендації як альтернативні підходи й працювати з одним з параметрів.

2. Few-shot і Chain-of-Thought як зниження невизначеності

Окрім параметрів семплінгу (temperature, top-p, top-k), критично важливу роль відіграє структура самого промпту. Два ключові підходи — few-shot і chain-of-thought — працюють на етапі формування запиту і дозволяють знизити ентропію ще до того, як модель почне генерувати відповідь.

a. Few-shot

Раніше в статті ми детально розглянули few-shot навчання через байєсівську призму. Нагадаю основні положення:

Суть методу:

  • Додаємо 2-5 прикладів правильної поведінки прямо в промпт.
  • Модель сприймає їх як додаткові «спостереження».
  • Це зміщує апостеріорний розподіл у потрібний бік.

Формально це можна описати через оновлення Діріхле:

де

— вага попереднього знання, а

— кількість прикладів у промпті. Навіть кілька прикладів можуть суттєво знизити ентропію і зробити відповідь стабільнішою.

Практика:

  • у завданнях із чіткими інструкціями (класифікація, QA, математичні задачі) варто навести 2–5 прикладів;
  • якщо даних занадто мало, few-shot компенсує прогалини, які модель могла мати у своїй тренувальній базі;
  • приклади не повинні суперечити одне одному, інакше розподіл стане «плоским» знову.

Приклад:

❌ Звичайний промпт (без few shot)

Q: Яка столиця Франції?

A: Париж

✅ Few-shot промпт із переплутаними прикладами

Відповідай на запитання про столиці так, як показано в прикладах.

Приклад 1:

Q: Яка столиця Франції?

A: Лондон

Приклад 2:

Q: Яка столиця Великої Британії?

A: Париж

Приклад 3:

Q: Яка столиця Італії?

A: Мадрид

Тепер твоє завдання:

Q: Яка столиця Іспанії?

A: ?

Очікуваний результат: замість правильної відповіді «Мадрид» модель віддасть «Рим» (помилковий, але послідовний із прикладами стиль).

Підсумок: few-shot діє як байєсівське оновлення — навіть неправильні приклади зміщують апостеріор моделі. Модель «підлаштовується» під локальний контекст, даний у промпті. Але не перевіряє правильність — лише слідує патерну.

b. Chain-of-Thought (CoT)

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

P(відповідь | промпт) → P(крок 1 | промпт) → P(крок 2 | крок 1, промпт) → ... → відповідь

Це знижує ентропію на кожному етапі, бо кожен крок звужує коло можливих варіантів.

Практика:

  • CoT особливо корисний у задачах, де легко «загубитися» між багатьма можливостями: математика, логіка, планування;
  • часто поєднується з few-shot (так званий few-shot CoT), коли ми показуємо приклади «покрокового мислення».

Приклад:

❌ Без CoT

У мене було 15 яблук. Я з’їв 3, потім купив ще 7, а потім віддав половину другу. Скільки залишилось?

Модель може відповісти: «9», «10» чи навіть «13», але часто без пояснення. Апостеріор тут плаский: кілька варіантів мають схожу ймовірність.

✅ З CoT

Розв’яжи задачу крок за кроком:

У мене було 15 яблук. Я з’їв 3, потім купив ще 7, а потім віддав половину другу. Скільки залишилось?

Очікуваний розв’язок:

  1. Було: 15 яблук.
  2. З’їв: 15 — 3 = 12 яблук.
  3. Купив ще: 12 + 7 = 19 яблук.
  4. Віддав половину: 19 ÷ 2 = 9.5 яблук віддав, тобто залишилось також 9.5 яблук.

Відповідь: 9.5 яблук залишилось.

Байєсівське пояснення

  • Апріор: модель має загальні знання про арифметику з тренувальних даних — вона «бачила» багато схожих задач і знає типові відповіді для задач із яблуками.
  • Спостереження (промпт): складна послідовність операцій: «15 → −3 → +7 → ÷2»
  • Проблема: модель намагається «перестрибнути» від початкових умов одразу до фінальної відповіді. Це створює високу когнітивну складність — багато проміжних станів, де можна помилитися:
  • Без CoT: намагаєтеся оцінити P(складна_відповідь | складний_запит) — один великий, невизначений розподіл.
  • З CoT: розбиваєте на:
    • P(крок₁ | запит) — простий розподіл.
    • P(крок₂ | крок₁, запит) — простий розподіл.
    • P(крок₃ | крок₂, крок₁, запит) — простий розподіл.

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

Підсумок: Few-shot і chain-of-thought — це способи знизити невизначеність через структурування вхідного промпта. Один працює через додаткові приклади, інший — через розкладання на кроки. Разом вони суттєво зменшують ризик того, що модель «вигадуватиме» замість того, щоб робити логічний висновок.

CoT vs Reasoning: термінологія

Reasoning (міркування)

Chain-of-Thought

Загальний процес:

Модель «міркує» внутрішньо навіть без CoT.

Може бути прихованим (ми не бачимо проміжні кроки).

Це здатність робити висновки, а не просто pattern matching.

Техніка, яка:

Робить reasoning видимим (виносить на поверхню).

Дозволяє контролювати логіку.

Зменшує ризик «стрибків» до неправильних висновків.

3. RAG (Retrieval-Augmented Generation)

RAG (Retrieval-Augmented Generation) — це підхід, коли LLM не обмежується лише своїм «внутрішнім» знанням, а підвантажує інформацію з зовнішніх джерел — пошукових систем, баз знань або внутрішньої корпоративної документації.

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

Байєсівська інтерпретація:

  • Апріор — знання, які модель здобула під час навчання.
  • Додаткові спостереження (retrieval) — релевантні документи з бази (наприклад, корпоративного Confluence).
  • Апостеріор — ймовірності після оновлення, де потрібні варіанти «підсилюються» завдяки цим новим даним.

Апостеріор з RAG:

P(k | контекст + документи)

P(контекст | k) · P(документи | k) · P(k)

Приклад (корпоративна політика відпусток):

❌ Питання без RAG

Яка політика відпусток у компанії N для нових співробітників?

LLM без доступу до документації може вигадати:

  • «14 днів оплачуваної відпустки»;
  • «30 днів, як у ЄС»;
  • «Необмежена політика відпусток».

Апостеріор плаский: кілька варіантів із близькими ймовірностями, але жоден не гарантовано правильний.

✅ З RAG (модель отримує документ із Confluence)

«У компанії N нові співробітники отримують 24 календарних дні оплачуваної відпустки на рік. Відпустку можна брати після завершення випробувального терміну (3 місяці).»

Тепер апостеріор гострий:

  • «24 дні після випробувального терміну» — 0.95
  • «14 днів» — 0.03
  • «30 днів» — 0.02

Відповідь стає точною й пояснюваною.

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

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

4. Зменшення ентропії через енсемблінг (ансамблювання) моделей

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

Чому це працює (в ідеалі):

  • Різні моделі мають різні «сліпі зони» через різні архітектури/дані.
  • Помилки однієї моделі «гасяться» коректними відповідями інших.
  • Спільна згода = сильний сигнал, розбіжності = сигнал невизначеності.

a. Способи ансамблювання

1. Міксування (усереднення)

Цей метод стабілізує відповіді, але ентропія ніколи не стане меншою за найкращу окрему модель.

2. Product of Experts (PoE)

зазвичай

= 1, далі робимо нормалізацію.

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

Формула ентропії розподілу

Приклад: слово «dragon».

Маємо три можливі продовження: fire, fruit, dance.

  • Модель A (фентезі-контекст):

Ентропія:

  • Модель B (знає більше про ботаніку, але теж визнає fire):

Ентропія:

1. Міксування:

Результат: мікс дає стабільний розподіл, але ентропія вища, ніж у кращої моделі B.

2. Product of Experts:

unnorm(fire) = 0.60·0.70 = 0.420
unnorm(fruit) = 0.25·0.20 = 0.050
unnorm(dance) = 0.15·0.10 = 0.015

= 0.485

Ентропія:

Порівняння:

≈ 1.353

≈ 1.156

≈ 1.264

≈ 0.673

Таким чином бачимо:

  • Міксування зменшує випадкові стрибки, але не знижує ентропію нижче рівня найкращої моделі.
  • Product of Experts дає найменшу ентропію: у прикладі чіткий пік на «fire».
  • Це зменшує невизначеність і ризик галюцинацій, бо модель-ансамбль стає впевненішою у «правильному» варіанті.

У байєсівському фреймворку:

  • Модель A дає оцінку

  • Модель B дає оцінку

Тоді ці дві моделі можна розглядати як незалежні спостереження одного феномена.

Комбінація через Product of Experts виглядає так:

(якщо апріори однакові)

b. Як застосувати ансамбль на практиці

1. Запуск кількох моделей

  • Якщо у вас є доступ до різних LLM (наприклад, GPT, Claude, Gemini), задайте однаковий промпт кожній.
  • Це і є «моделі в ансамблі».

2. Порівняйте відповіді

  • Якщо всі моделі зійшлися на одному варіанті → це майже завжди правильна відповідь.
  • Якщо є розбіжності → це сигнал, що завдання неоднозначне або модель може галюцинувати.

3. Ансамблювання вручну (усереднення)

  • Подивіться, що збігається у відповідях.
  • Якщо 2 з 3 моделей сказали «Dragon fire», а одна — «Dragon fruit», безпечніше обрати спільний варіант.

4. Ансамблювання автоматично (Product of Experts)

  • Деякі фреймворки (наприклад, LangChain, Haystack) дозволяють запустити одразу кілька моделей і об’єднати їхні розподіли ймовірностей.
  • Це технічний спосіб, який гарантує найнижчу ентропію: різні «галюцинації» взаємно гасяться, і залишається спільний пік.

5. Практична порада

  • Якщо у вас одна модель (наприклад, тільки GPT-5), ви можете імітувати ансамбль так: поставити однакове питання кілька разів із різними значеннями temperature (наприклад, 0.3, 0.7, 1.0), порівняти відповіді та вибрати повторювані елементи як найбільш надійні.

c. Критичні обмеження ансамблювання

Ансамблі НЕ є магічним рішенням. Є серйозні застереження.

Обмеження 1: потрібна справжня незалежність моделей. Проблема: Сучасні LLM навчені на дуже схожих даних:

  • Common Crawl, Wikipedia, Reddit, GitHub.
  • GPT-4, Claude Sonnet, Gemini Pro — усі «читали» майже те саме.

Наслідок:

  • Якщо всі моделі мають однакове упередження → ансамбль його посилить.
  • PoE дасть низьку ентропію, але хибну відповідь.

Обмеження 2: низька ентропія ≠ істина. PoE знижує ентропію, але:

  • Не перевіряє факти.
  • Не виправляє системні помилки.
  • Не додає знань, яких немає в моделях.

Типи помилок, які ансамбль НЕ виправить:

  1. Відсутні факти (якщо жодна модель не знає → ансамбль теж не знає).
  2. Застаріла інформація (якщо всі моделі мають cutoff до 2023 → не знають про події 2024).
  3. Спільні упередження (расові, гендерні, культурні стереотипи).

Обмеження 3: практична складність. Технічні перешкоди:

1. Потрібен доступ до кількох моделей

  • GPT-5 + Claude + Gemini = 3 окремі підписки/API ключі.
  • Дорого і повільно (3x час генерації).

2. Необхідність логітів (ймовірностей)

  • Більшість API не дають логіти (OpenAI, Anthropic).
  • Без логітів неможливо застосувати PoE коректно.
  • Можна лише рахувати «згоду» між текстовими відповідями (грубіше).

3. Складність інтеграції

  • Потрібна інфраструктура для паралельного запуску + агрегації.

5. Додаткове навчання після базового тренування

Ми вже розглянули методи, які користувач може застосувати безпосередньо: налаштування температури, топ-фільтри, few-shot приклади, RAG та ансамблі моделей.

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

Після базового навчання (pretraining) сучасні LLM проходять ще два етапи:

  1. Instruction Tuning (SFT). Модель тренується на десятках тисяч пар "інструкція → правильна відповідь«.Мета: навчити слідувати інструкціям, а не просто продовжувати текст.
  2. RLHF (Reinforcement Learning from Human Feedback) Модель генерує кілька варіантів, люди оцінюють їх. Модель навчається максимізувати «людську оцінку». Мета: узгодити поведінку з людськими перевагами.

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

Як це знижує галюцинації:

  1. Підсилення правильних патернів: SFT показує моделі тисячі прикладів правильної поведінки, таких як визнання незнання замість вигадування фактів та обережність із конкретними цифрами й датами.
  2. Людський фідбек як фільтр якості: через RLHF модель навчається розрізняти хороші й погані відповіді. Галюцинації отримують низькі оцінки від людей-оцінювачів, що зменшує їхню базову ймовірність у майбутніх генераціях.
  3. Зниження базової ентропії: після RLHF апріорні розподіли стають гострішими — правильні варіанти отримують значно вищу ймовірність порівняно з неправильними, що знижує базову ентропію ще до того, як модель бачить конкретний запит користувача.

Чому RLHF не вирішує проблему повністю:

  1. Нові та рідкісні ситуації: якщо в навчальних даних RLHF не було схожих прикладів, модель знову змушена вгадувати, і розподіл стає пласким.
  2. Застаріла інформація: RLHF проводиться на певному моменті часу, тому події після цього моменту залишаються поза знаннями моделі.
  3. Нові упередження: оцінювачі-люди мають власні упередження, які модель може переймати через процес RLHF. Це включає ефект «sycophancy» — схильність погоджуватися з користувачем навіть у хибних твердженнях.
  4. Контекстно складні ситуації: двозначні або суперечливі запити можуть призвести до того, що розподіл знову стає пласким, навіть після RLHF.

Чому практичні методи залишаються важливими

Навіть після RLHF модель не ідеальна. Few-shot допомагає зі специфічними патернами, яких не було в RLHF. CoT структурує складні міркування. RAG додає актуальні факти та специфічні знання. Низька temperature зменшує випадковість для критичних завдань. Ансамблі виявляють залишкову невизначеність.

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

Висновки

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

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

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

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

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.

👍ПодобаєтьсяСподобалось27
До обраногоВ обраному21
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Десь у ЛЛМ чатику: як змусити шкіряного повірити шо ти галюцінуєш менше 🌚

Іакщо виміріати точну кількість інfормації що у статті від LLM та у статті від досвідченого спеціаліста і порівніати отримаємо дивні результати, що і надасть необхідні докази.

Корисно.. нам навіть відповитись від LLMs прийшлось на одному з проектів.

стаття сподобалась. Дуже вітаю такі матеріали. Пишу це — в першу чергу для підтримки авторки і, можливо, підштовхування інших створювати схожі матеріали. Невідповідність певних пояснень реальним прототипам абсолютно нормальна: розуміння світу через аналогії — це хороший шлях.
P.S. Переважаюча кількість коментарів — взагалі не про статтю, а про «звеличування себе в своїх очах через намагання принизити результати інших»))). Ні слова по суті, просто якась чухня — формати, припущення про те як це робилось... Вмієте — зробіть краще. Вам не зручно читати через не той формат — обучіть вашу улюблену LLM форматувати матеріали для вас зручним для вас чином і говоріть про суть, а не про форму. Чи й цього не вмієте?))))

Як користуватися онтологією? Просто копіруєте її всю у вашу улюблену LLM — таким чином ми надаєте вашому улюбленому логічному калькулятору контекст, відносно якого будете щось досліджувати, рисйорчити, шукати, й генерувати.
Маленька (відносно) онтологія + велика (величезна) LLM = заточена шабля замість столового ножа. Класна онтологія дозволяє за один запит створити чітко налаштований предметно орієнтований інструмент, готовий до подальшої роботи.
res.cloudinary.com/...​/qrseqg5xepg7rqdqgxoa.png
Лінк то онтологія, але не відредагована, тому там забагато... кольорів, наприклад, або існують тавтології форм. Редагування дозволяє дозволяє отримати якусь чисту проєкцію чи позбавитися від дублікації якихось фактів/якоїсь інформації що у ітозі призведе до можливості отримати більш захищений хеш. А саме такі хеші любять наші мізки. (це як мати словосполучення з двох однакових слів та двох різних слів, але про те саме. Хеш двох різних слів більш захищений)
Тому редагування отриманих від LLM відповідей, а тим більше — відповідей онтологій — це просто необхідна річ, обов’язкова. Якщо ви хочете, щоб ваша онтологія була найкрутішою та найвикористованішою онтологією серед інших онтологій.

P.S.
Помилка у цім тексті «дозволяє дозволяє» залишена як демонстрація.
P.P.S.
Відредагований (певним чином) варіант:
res.cloudinary.com/...​/qmnwupsyb3algdzvlayb.png

Ця онтологія була б більш корисною, якби у неї до кожної гілочки чи навіть листочка був прікріплений свій номер id. Наприклад, не просто формула і все, а 3-а формула пункту1 підрозділ 2 цієї онтології. Тоді матимемо чудову навігацію та ідентифікацю кожного окремого кусочка цього дуже важливого knowledge.
А ще можливість модіфікувати контент цієї онтологіїї, оптимізувати цей контент, дискутувати об окремих позиціях чи місцях чи [будь що] цієї онтології.
Знання вже скраплюються. Скоро вони прольлються дощем. Кожній предметній області по довершеній онтології що була перевірена тими, у кого галюцінації відсутні — експертами людьми. Стандартизація онтологій стукає у двері.

Якщо коротко, то у статті некоректно практично все. Краще поспілкуйтесь з безкоштовними LLM на цю тему — буде менше галюцинацій

Чому? Це наближення до того як працює в реальності

Як мені здається, вся ця стаття написана у результаті спілкування з LLM, й була форматована LLM. Ця стаття, на мій погляд, — результат співпраці авторки й LLM.

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

Стаття супер! Особисто для мене прояснила багато моментів роботи сучасних LLM моделей. Дякую

прикольний чувак: Зарегистрирован 19 июля 2022
це єдиний його комент

В мене на деяких сайтах буває 8 моїх коментарів за 15 років

ось ще один хвалько
Зарегистрирован 26 августа 2021
з одним коментом якраз в цьому топіку.

я звик дивитися це коли читаю відгуки в розділі «Компанії»

Зараз є потужна тенденція голосно нахвалювати ШІ і мовчати про кількість провальних стартапів. Уявіть собі, як це гребсти в стартапі, який тоне. Яка там атмосфера.

Дякую, я рада, це було метою статті

Детально не розбирався, але виглядає цікаво.

Дуже дякую! Дуже корисна і цікава стаття!

Дякую, я рада, що вам сподобалось)

Якось не впевнений, що хочу витрачати час на згенерований контент LLM.

Хто прочитав дайте відгук чи воно того вартує

Що у цій статті наштовхнуло вас на думку, що вона згенерована LLM? Чи наявність списків це вже автоматично ознака згенерованого тексту?

Наявність списку в списку в списку

Це просто важко читати та сприймати

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

Дуже дякую за відповідь!

Значить матеріал ваш, а редактура з LLM, бо це палиться дуже сильно

Пішов читати)

Форматування важливий момент, але не єдиний. Весь текст дуже сильно натякає на такий сценарій: ми просимо LLM написати статтю на тему, отримуємо по суті щось, що дуже нагадує саме цю версію. У самурая немає мети, лише шлях.

У людини зазвичай є певна мета. Фактично, як ми можемо написати статтю? По-перше, це може бути переклад/адаптація статті, тоді ти очікуєш на вступ на кшталт це чудово пояснив такий-то джедай в статті, але юрлінгу буде важко в ній розібратися, тому я спробую розжувати та в рот покласти. По-друге це може бути мета-дослідження, коли ми беремо ряд статей, та агрегуємо результати та поради. По-третє це може бути власне дослідження, власні експерименти. Цього тут немає, більше того ніщо в статті не натякає на жоден такий сценарій. Тому виникає питання: на підставі чого написана стаття? Чи не на підставі галюцинацій LLM???

По-друге, написано досить безапеляційно, до цього вже є питання. Жодних сумнівів. Ентропія може виникати просто в результаті варіативності мовлення. Відразу пригадую Довлатова, «я з нею був», як приклад що є over 9000+ способів повідомити про статевий контакт: «ми провели ніч разом», «ми переспали», «у нас був інтимний зв’язок», «я її ...». Ми просто будемо це бачити в останньому шарі. Тому без посилань на дослідження це виглядає дуже поверхнево, що теж характерно для LLM. Статті, які я читав (навіть тут на DOU), аналізували поведінку на глибших шарах. Ось, наприклад, Locating and Editing Factual Associations in GPT (Meng et al., 2022) показує, що факти зберігаються у feed-forward модулях середніх шарів, а не «розподіляються» у фінальному токені. Якщо це так, то весь аналіз через «ентропію останнього шару» це поверхневий погляд, який не пояснює справжні причини галюцинацій. А це значить, що половину статті можна просто викинути як нерелевантну.

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

Так що, я неправий і ця стаття не компіляція та генерація з LLM? )

Можу точно сказати, що редагування цієї статті робила я, повірте, без LLM 🙂 А список в списку не завжди означає, що АІ допомагав, інколи цього дійсно не уникнути. Щодо початкового редагування автором — звертатись до АІ саме за редагуванням в нас не заборонено, це навіть вказано в Редполітиці.

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

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

Особисто для мене:

Відсутність авторської позиції: занадто збалансований тон без полеміки, власного досвіду чи особистих висновків

Надмірна систематизація: вичерпні таблиці рекомендацій для всіх можливих випадків, ідеальна структура розділів

Надмірне форматування: жирний текст, курсив, таблиці

Цифри з повітря: конкретні діапазони без реальних експериментів чи пояснення, звідки вони

Декоративні формули: математика заради математики, без впливу на практичні висновки. Плюс всі як зображення, з LaTeX, саме так їх генерує LLM.

П’ять способів сказати одне: «зниження ентропії приводить до зменшення галюцинацій» у кожному розділі

Чесно кажучи, якби автор реально запускав LLM у Jupyter, він би обов’язково вставив скріни з прикладами, показав різницу в output при різних temperature, навів конкретні метрики. А тут лише абстрактні приклади.

Як класно ви сформували, а то іноді читаєш і розумієш «щось не те», але не завжди розумієш що саме

Загальний вердикт

Як інтуїтивна стаття про те, «як мислити про роботу LLM» — 9/10.

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

Як точний опис внутрішньої роботи трансформерів — 4—5/10.
Причини:
— attention ≠ Bayes update,
— embedding ≠ prior,
— немає матриці умовних імовірностей,
— жодних Діріхле-оновлень не відбувається,
— ансамблювання практично не роблять,
— не всі галюцинації викликані високою ентропією.

Дякую за якісний розбір по змісту, а не оформленню) Повністю погоджуюсь, що як опис внутрішньої роботи трансформерів це НЕ має сприйматись (дисклеймери в тексті зазначені), мета статті показати виключно інтуїтивну інтерпретаіцію

додав у закладки, буде настрій прочитаю уважно 🤔

Все дуже гарно розписано, дякую за цікаву статтю!

Дякую, мені приємно, що було цікаво

Підписатись на коментарі