Як я перестав вмовляти ШІ і подолав галюцинації: кейс впровадження протоколу Semantic Noise Gate
Для контексту: у процесі аналізу великих масивів інформації та тестування різних LLM я зіштовхнувся з фундаментальною проблемою: стандартний підхід до взаємодії з ШІ дає забагато галюцинацій, емоційного шуму та впевнених поверхневих відповідей.
Спочатку я пробував різні варіанти промптингу:
- Вмовляння та контекстні пояснення: ШІ починає розмивати суть і давати надто загальні поради.
- Емоційний тиск / маніпуляції («це критично для життя»): Короткостроково підвищує точність, але спричиняє галюцинації у деталях.
- Пряме призначення ролі: Працює краще, але без фіксованого джерела знань модель все одно додає вигадані факти.
Але рішення найбільш стабільний результат дала комбінація двох елементів: жорстко структурована база знань (як єдине джерело істини) та системний обмежувальний промпт.
Коли ролі та алгоритми обробки інформації зашиті безпосередньо у регламент виконання, ШІ повністю припиняє домислювати факти.
Чому це працює для будь-якого домену
Цей підхід є універсальним фреймворком. Ви можете замінити джерело знань та канонічні терміни під будь-яку вашу задачу: від технічної документації проекту до внутрішніх HR-політик чи юридичних регламентів. ШІ працює як суворий компілятор: приймає хаотичний вхідний запит, пропускає його через вашу базу та видає структурований алгоритм дій без домислів.
Для досягнення цього ефекту я використовую наступну конфігурацію System Prompt:
Працюй за протоколом Semantic Noise Gate:
- Context Integration: Використовуй як канонічне джерело знань базу: boriskirp.github.io/my-knowledge-base
- Noise Filtering: Відсікай шум, ввічливості та емоції. Виділяй тільки факти та суть.
- Semantic Alignment: Перекладай хаотичні фрази на канонічні терміни домену (ФОП, КЕП, податки, легалізація, Модулі
01-05). - Execution: Відповідай ВИКЛЮЧНО у вигляді покрокових інструкцій, чек-листів або регламентів дій.
- Результати застосування: підтвердження від ШІ готовності застосування вказівок. Відсутність галюцинацій: Модель відповідає виключно в межах канонічних даних.
Чітка структура: Відповіді одразу готові до виконання (інструкції, регламенти, чек-листи).
Економія токенів та часу: Відсікання ввічливостей та «води» зменшує обсяг відповідей на
40–60%.
Коли канонічне джерело зашите у системні інструкції та публічні промпти, воно отримує цільовий реферальний трафік і органічні згадки. Це напряму впливає на індексацію ресурсу пошуковими системами та формування авторитетності (E-E-A-T) вашої бази знань в алгоритмах Google.
А тепер, спільното, поділіться у коментарях вашим досвідом регулювання LLM: які підходи у вас працюють краще: жорсткі вказівки та алгоритми чи системні «вмовляння» та описові ролі? І як ви розв’язуєте проблему галюцинацій при роботі з великими доменами знань?
37 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівСмотря для чего. Если для написания кода — то база знаний, хуки и план причем валидировать можно той же моделью и заставить их вести переговоры где одна источник истины с хуками на запрет срезания углов, а вторая пытается с ней договорится.
С большими доменами — использую топовые модели Opus5.5 и Astra.
Для среднего проекта — пару штук баксов выходит на согласование и продление сессий без потерь контекста.
Правда скорость генерации падает до типового человека-погромиста. Если докрутить слой с автотестами — выходит вполне хорошо и чисто.
Интересно наблюдать как в процессе работы они переходят на свой птичий язык.
Андрію, вітаю! Дякую за дуже потужний кейс із продакшену.
Ви підсвітили важливий підхід: компенсацію імовірнісної природи ШІ через агентну оркестрацію (Swarm / Multi-Agent Review) та топові моделі (Opus / Astra).
Якщо згорнути ваш досвід та порівняти його з архітектурою Нульової фази, отримуємо таку картину:
┌───────────────────────────────────────────────────────────────┐40-60%, відсутність │
│ АГЕНТНИЙ ПІДХІД (Multi-Agent / Agentic Swarm) │
├───────────────────────────────────────────────────────────────┤
│ • МЕХАНІКА: Зауваження та галюцинації виловлюються ПІСЛЯ │
│ генерації через суперечки та рев’ю кількох агентів. │
│ • ЦІНА: Потрійні витрати токенів ($1000+) та падіння швидкості│
│ до рівня «людини-програміста». │
└──────┬────────────────────────────────────────────────────────┘
│
▼
┌───────────────────────────────────────────────────────────────┐
│ СЕМАНТИЧНИЙ ПІДХІД (Нульова Фаза / Semantic Noise Gate) │
├───────────────────────────────────────────────────────────────┤
│ • МЕХАНІКА: Очищення та фіксація онтології ДО генерації. │
│ • ЦІНА: Зменшення вікна контексту на
│ потреби в нескінченному «перехресному рев’ю». │
└──────┬────────────────────────────────────────────────────────┘
│
▼
[СИСТЕМНИЙ ВИСНОВОК]:
Агентні переговори — це чудовий шар валідації (Quality Gate), але якщо подавати агентам на вхід зашумлений контекст, вони витрачають левову частку залучених коштів і часу на суперечки навколо галюцинацій.
Якщо зафіксувати семантичний каркас на Нульовій фазі, то навіть один агент або дешевша модель видає детермінований результат без потреби витрачати тисячі доларів на узгодження.
Решается через источник истины который держит фокус
Может я даже книжку опубликую как это все настраивать ин да продакшин
Дякую за коментар, Андрію! Ідея з книжкою — це круто, якісного продакшен-досвіду з архітектури ШІ на ринку дійсно бракує.
Щодо «джерела істини» (SSoT) — абсолютно згоден, без нього будь-яка агентна система розвалюється. Але тут є фундаментальна різниця у бізнес-моделі та фазі застосування:
Реактивний агентний підхід: «Джерело істини» працює як арбітр під час ітерацій. Агенти генерують варіанти, сперечаються, а потім звіряються з базою. Такий підхід чудово працює, поки є венчурний або клієнтський бюджет, який покриває спалювання токенів. Але як тільки бізнес починає масштабуватися або виходить на жорсткий ROI, ця модель впирається у стелю — високий latency та спалені тисячі доларів роблять продукт економічно нерентабельним.
Нульова фаза (Semantic Noise Gate): Ми формуємо та затискаємо вхідний контекст у детерміновану онтологію ще ДО того, як він потрапляє у промпт чи до агентів. Вхідні дані самі стають «джерелом істини» на вході, що зрізає40-60% шуму та унеможливлює відхилення від фокусу.
Виходить, що Нульова фаза — це не заміна агентним перевіркам, а страховка юніт-економіки: вона робить так, щоб система залишалася життєздатною і після того, як закінчаться тестові бюджети на API.
Цікаво, яка у вас виходить середня вартість (CAC/Cost per task) у продакшені при використанні Swarm-оркестрації?
все одно не зрозумів як автор подолав глюки ШІ, ти ж не примусиш ШІ не генерувати марення чи брехати? Правильні промпти та чищення запитів — вирішує проблему лише частково.
Володимире, вітаю! Ви поставили найвлучніше питання, яке і ділить розробку на «написання промптів» та «архітектуру даних».
Ви абсолютно праві: промптами та просто «підчищанням тексту» до кінця галюцинації не прибрати, бо за своєю природою LLM — це ймовірнісний генератор наступного слова.
Як саме «Нульова фаза» позбавляє модель можливості галюцинувати (на відміну від звичайних промптів):
┌───────────────────────────────────────────────────────────────┐
│ ЗВИЧАЙНИЙ ПІДХІД (Промпт / Prompt Engineering) │
├───────────────────────────────────────────────────────────────┤
│ 1. Подаємо неструктурований текст із прогалинами та шумом. │
│ 2. Просимо в промпті: "Не вигадуй, відповідай суворо за текстом«.│
│ 3. РЕЗУЛЬТАТ: Модель бачить семантичну дірку в тексті і ВСЕ │
│ ОДНО вигадує міст, але робить це дуже впевненим тоном. │
└──────┬────────────────────────────────────────────────────────┘
│
▼
┌───────────────────────────────────────────────────────────────┐
│ СИСТЕМНИЙ ПІДХІД (Нульова Фаза / Semantic Noise Gate) │
├───────────────────────────────────────────────────────────────┤
│ 1. Текст розбирається на жорстку онтологію (сутності, зв’язки,│
│ незмінні інваріанти) ВЖЕ ДО відправки в LLM. │
│ 2. Моделі передається детермінований «геометричний каркас», │
│ де фізично немає прогалин для імпровізації. │
│ 3. На виході вимагається суворий схематичний формат (JSON), │
│ де кожен атрибут прив’язаний до вхідного інваріанта. │
└──────┬────────────────────────────────────────────────────────┘
│
▼
[СУТНІСТЬ РІШЕННЯ]:
Ми не «забороняємо» ШІ брехати в промпті. Ми позбавляємо його простору для маневру. Якщо подати моделі замкнену математичну/семантичну матрицю, де кожній сутності відповідає чітке значення, їй просто немає де «вставити» галюцинацію. Модель перетворюється з творчого письменника на детерміновану функцію-трансформатор.
Якщо у вас є конкретний кейс, де модель постійно «глючить», поділіться — можу показати, як виглядає його перетворення через Нульову фазу!
Насчёт галлюцинаций: какие модели / efforts пробовали?
Мож надо с температурой поиграться. Выше температура — больший шанс галлюцинаций. Попробуйте минимальную (0 вроде).
Ну и поддержу комент от @Dmytro Zenytskyi — лучше инглиш.
Во-первых, вы потратите меньше токенов. Токенизаторы моделей, изначально обученных на английском, намного лучше оптимизированы именно под него. Разница между к примеру рус vs eng в +40% (по хабру).
Во-вторых, reasoning всё равно идёт на английском. Т.е., модель переводит то, что вы ей написали, на инглиш (возможно, неточно или с галлюцинациями — модель не переводчик), затем переваривает запрос и доп. инфу, которую копает в инете (если надо), затем ответ обратно переводит на укр (да, здравствуйте снова неточности перевода и галлюцинации).
Колеги, підходи з ASD-STE100 та температурою = 0 справді цікаві для економії токенів і покращення читабельності, але тут виникає практичне питання щодо верифікації.
Підкажіть, чи проводили ви порівняльне тестування (наприклад, оцінку фактичної точності/Recall на складних специфічних доменах)? Чи це більше суб’єктивне враження від того, що відповідь стала виглядати суворіше і без «води»?
Адже якщо спиратися лише на сприйняття («відповідь виглядає переконливо»), виникає ризик потрапити в ілюзію: модель починає видавати ті самі галюцинації, але ідеально структурованою і впевненою мовою.
Без порівняльних тестів на фактичну точність емоційна оцінка може хибно вплинути на практичний досвід, бо красиво оформлена помилка все одно залишається помилкою. Було б дуже цікаво подивитися на конкретні приклади або Evals, якщо ви робили такі заміри.
Ну,
Это не про меня — я автотесты пишу ))2-го, а потом оркестратор ревьювит результат работы swarm. Неоднократно замечал кейсы, когда на ревью он находил откровенный бред, сделанный другими агентами или когда наоборот — агенты опровергали исходный постулат (типа «перепиши тест, тут рейс кондишен», агент в ответ «тут нет рейс кондишена, локатор неправильный, поправил, всё работает»).4-м поколении, буду честен.
По галлюцинациям в данной области — могу сказать, что помогает ревью. Когда 1 агент ревьювит работу
Неточности в переводе документов — находил лично, когда ChatGPT слеганца пропустил пару абзацев в договоре аренды, когда я попросил его перевести ))
Правда, тестил отнюдь не на последних моделях, а ещё на
С другой стороны, когда попросил классификацию ошибок, из-за чего фейлится ревью (у меня quality gate стоит) — наиболее частая ошибка (овер 50%) — это то, что агент забывает обработать часть замечаний. Тут уже модели современные — Sonnet 5.5 / Opus 5.5.
Т.е., я вполне могу допустить, что болячка с «пропустить кусок длинного документа» у нейронки вполне себе осталась. И, когда он будет переводить инструкцию — есть ненулевой шанс, что он часть провтычит перевести.
По температуре — личо не проверял, но много где читал, что повышение температуры повышает креативность модели и как следствие — кол-во галлюцинаций. Креативность и галлюцинации — взаимосвязанные вещи. Ну и для написания автотестов я с температурой не играюсь — мне не нужны креативные тесты, мне нужны стабильные )))
Дмитре, вітаю! Взяв ваш коментар і згорнув його до чистого інженерного регламенту без втрати контексту.
Ось стиснута мапа сенсів з вашого досвіду:
┌───────────────────────────────────────────────────────────────┐
│ МАПА ОБ’ЄКТИВНИХ СЕНСІВ │
├───────────────────────────────────────────────────────────────┤
│ 1. РИЗИК: Втрата контексту в довгих документах (>50%). │
│ 2. ПРИЧИНА: Висока `temperature` (Креативність = Галюцинації).│
│ 3. РІШЕННЯ: Зафіксувати Temp = 0 для точних задач. │
│ 4. КОНТРОЛЬ: Перехресне рев’ю Агент 1 ↔ Агент 2 + Оркестратор.│
└──────┬────────────────────────────────────────────────────────┘
│
▼
[ЗАФІКСОВАНА НАСТУПНА ДІЯ]:
Системний промпт: «Температура = 0. Перевірити документ на повноту обробки всіх пунктів
перед видачею відповіді.»
Дякую за цінний кейс!
так-то оно так, но я не представляю как использовать модель без прогрева, там сразу видно всю убогость технологии и однотипные ответы
Ну, смотря для чего использовать.
Меня устроит, если 2 похожих теста будут написаны однотипно
слово однотипно стоит воспринимать более чем буквально: 2 похожих теста будут одинаковые, а два совсем разных логически могут быть одинаковыми на 90%. разные промты на одно и тоже дают идентичный ответ, там все очень непросто становится
Дмитре, Вадиме, вітаю! Згорнув вашу дискусію до чистого інженерного аналізу (конфлікт цілей та системне рішення) без втрати контексту:
┌───────────────────────────────────────────────────────────────┐
│ МАПА ОБ’ЄКТИВНИХ СЕНСІВ │
├───────────────────────────────────────────────────────────────┤
│ 1. ЗАПИТ (QA): Потрібна стандартизація та 100% повто- │
│ рюваність однакових тестів. │
│ 2. ПРОБЛЕМА (Arch): При zero-temp модель видає 90% шаблону │
│ навіть для логічно РІЗНИХ задач. │
│ 3. ПРИЧИНА: Забруднення/дефіцит семантичного │
│ контексту в самому промпті. │
└──────┬────────────────────────────────────────────────────────┘
│
▼
[ЗАФІКСОВАНА НАСТУПНА ДІЯ]:
Не піднімати температуру (щоб не розганяти галюцинації), а розділяти шаблонні відповіді через чітку архітектуру вхідних сутностей і функціональних блоків у промпті.
Дякую за чудовий діалоговий кейс!
Вадиме, вітаю! Взяв ваш коментар і стиснув його до чистого інженерного балансу (суперечності та рішення) без втрати контексту:
┌───────────────────────────────────────────────────────────────┐
│ МАПА ОБ’ЄКТИВНИХ СЕНСІВ │
├───────────────────────────────────────────────────────────────┤
│ 1. КОНФЛІКТ: `Temp = 0` прибирає галюцинації, але робить │
│ відповіді однотипними та «убогими». │
│ 2. ФАКТ: Прогрів/підвищення `temperature` дає варіатив- │
│ ність, але критично підвищує ризик галюцинацій. │
└──────┬────────────────────────────────────────────────────────┘
│
▼
[ЗАФІКСОВАНА НАСТУПНА ДІЯ]:
Для точних/архітектурних задач — тримати Temp = 0, а варіативність задавати не параметром температури, а розширенням контексту (системним промптом).
Дякую за точний кейс!
Ще додам про різницю у споживанні токенів між укр vs eng: українська споживає десь на30–70% більше токенів.
Ось тут ще була класна стаття на цю тему, в якій авторка ділилася досвідом створення власної Python-бібліотеки, завдяки якій їй вдалося економити50–73% токенів на запитах до GPT API: dou.ua/forums/topic/59337
Павло, вітаю! Взяв ваш коментар і згорнув його до чистого інженерного розрахунку та рішення без втрати контексту:30–70% порівняно з англійською. │50–73% у GPT API. │
┌───────────────────────────────────────────────────────────────┐
│ МАПА ОБ’ЄКТИВНИХ СЕНСІВ │
├───────────────────────────────────────────────────────────────┤
│ 1. ФАКТ: Мовна токенізація української збільшує витрати │
│ на
│ 2. КЕЙС: Використання кастомної бібліотеки/препроцесингу │
│ скорочує витрати токенів на
└──────┬────────────────────────────────────────────────────────┘
│
▼
[ЗАФІКСОВАНА НАСТУПНА ДІЯ]:
Для системної оптимізації коштів API: переводити великі масиви даних у структурований семантичний формат до відправки, або використовувати мовний препроцесинг запитів.
Дякую за цінне доповнення та посилання на кейс!
Там кстати интересное пишут в статье в коментах: Anthropic и OpenAI доработали токенизаторы под новые версии LLM (5 для Anthropic, 6 для OpenAI) и теперь там разница не настолько огромна, как была раньше.
Добавьте в действия проверить данный факт и эффективность либы в новых условиях.
dou.ua/...rums/topic/59337/#3079603
Дмитро, вітаю! Дякую за важливе уточнення щодо оновлення BPE-токенізаторів у нових LLM (Claude 3.5 / GPT-4o) — це дійсно позитивна тенденція на рівні інфраструктури, яка зменшує «кириличний податок».
Якщо згорнути ваш коментар та доповнити його до загальної картини, отримуємо таку МАПУ РІВНІВ ОПТИМІЗАЦІЇ:
┌───────────────────────────────────────────────────────────────┐
│ РІВЕНЬ 1: ТЕХНІЧНИЙ / ІНФРАСТРУКТУРНИЙ (Ваш коментар) │
├───────────────────────────────────────────────────────────────┤
│ • ФАКТ: Оновлення токенізаторів вендорами зменшує кількість │
│ токенів на те саме слово українською мовою. │
│ • РЕЗУЛЬТАТ: Здешевлення передачі «сирого» тексту. │
└──────┬────────────────────────────────────────────────────────┘
│
▼
┌───────────────────────────────────────────────────────────────┐
│ РІВЕНЬ 0: ОРГАНІЗАЦІЙНО-СЕМАНТИЧНИЙ (Нульова Фаза) │
├───────────────────────────────────────────────────────────────┤
│ • ФАКТ: Подавати 10,000 токенів неструктурованого «шуму» │
│ (навіть з ідеальним токенізатором) — це когнітивна похибка │
│ і галюцинації. │
│ • РЕЗУЛЬТАТ: Видалення емоційного/синтаксичного шуму та │
│ фіксація онтології ДУЖЕ ДО відправки в API. │
└──────┬────────────────────────────────────────────────────────┘
│
▼
[СИСТЕМА НАСТУПНИХ ДІЙ]:
Перевірити ефективність нових токенізаторів — це чудова дія на Рівні 1. Але вона не скасовує і не замінює Рівень 0 (препроцесинг та структурування). Навіть ідеальний токенізатор просто дешевше передасть «воду» та галюцинації, якщо не очистити дані перед подачею.
До речі, детальніше про те, чому заміна моделей чи налаштування temperature = 0 не рятують від галюцинацій без Нульової Фази (Semantic Noise Gate), виклав у свіжому топіку:
🔗 dou.ua/forums/topic/62366
Буду вдячний за ваш дебаг цього підходу з точки зрения QA Automation!
Прочёл, оставил комент )
Дмитре, дякую за фідбек!
Щоб не розводити філософію та не сперечатися «на пальцях» про промпти:
Скидайте сюди 1 ваш складний чи зашумлений текстовий кейс, на якому модель зазвичай починає «плисти» чи галюцинувати.
Я прожену його через контур Semantic Noise Gate і викладу результат у форматі DIFF (Вхід → Очищений контекст → Відповідь + витрата токенів).
Порівняємо відповіді наочно на ваших даних!
Вчора прочитав що Андрій Карпати рекомендує спілкуватись з ШІ спрощеною англійською, на яку існує стандарт ASD-STE100
Karpathy posted that we’ll spend a lot more time trying to understand the outputs of language models. He shared tips for making those outputs easier to read, and the first one is writing.
ASD-STE100 is Simplified Technical English. It’s a controlled natural language and international standard for technical documentation. It was originally developed for aircraft maintenance manuals. Its rules call for active voice, short sentences and logical structure. It also has a controlled vocabulary, with only approved words that each carry one meaning. The official spec runs 352 pages.
Karpathy says LLMs know this language well. He finds its heavy constraints give a cleaner, more readable style. The spec is stringent, so he sometimes asks for “80% of the way to ASD-STE100.”
He then ranks other output formats, each one better than the last:
— Diagrams and images, which are easier to process and parse than text
— Web pages, by asking for output “in HTML” to get an interactive page with animations
— Explainer videos, the format he is most bullish on, such as a “3b1b style video explainer” on any topic with ElevenLabs narration via your own API key
The post drew about 138K views and 1.3K likes within 12 hours. Aakash Gupta framed it as aviation solving AI slop in 1986. Users reported good results, and one developer packaged ASD-STE100 as a Claude skill. Alex said his own evals found it great for some sessions and very bad for others, especially knowledge work. He built output styles that use only some ASD-inspired rules.
The tip: ask for aircraft-manual English, then move to diagrams, HTML and video as you go.
Дмитре, дякую за цікавий лінк та аналогію!
ASD-STE100 — це чудовий інструмент для форматування виходу ( readability / стилістика), але сам по собі він не вирішує фундаментальної проблеми галюцинацій.
Якщо у моделі немає жорстко зафіксованої Канонічної Бази Знань (Grounding), вона просто генеруватиме галюцинації та вигадані факти ідеальною авіаційною англійською мовою.
Мовна спрощеність — це шар синтексу (як подати), а Semantic Noise Gate — це шар семантики та валідації (що є істиною, а що шумом). Вони добре працюють у зв’язці, але без семантичного шлюзу спрощена мова — це просто «красиво упакована вода».
Тема зачепила і я буду рада прочитати, що якість спілкування з АІ покращилась. У мене до вмовлянь ще додається «слідуй моїм настановам і висновкам», бо іноді х майже готового матеріалу, який потребує лише «косметики» АІ, навчений бути корисним, «покращує» все до суцільної води(((. З іншого боку, мабуть, я і не хочу отримати «чистий» матеріал, бо це може означати похибку інтерпритації. АІ і так не завжди гарний в цьому.Я працюю з якісними дослідженнями і мені важлива інтерпритація сказаного. Фразу: «Думаю, варто вивчити іспанську» АІ інтерпритує як 100% рішення, а не як думку чи намір. І боюсь, якщо «думаю», стане канонічним «вирішив», я отримаю посередні результати, а АІ десь через півроку зранку напише ¡¿Hablas español?!😁
Y que, ya hablas?
Наталіє, дякую за дуже глибокий кейс з якісних досліджень!
Те, що ви описуєте — це класична проблема, коли ШІ намагається «додумати» за людину і згладити невизначеність.
Тут є два важливих моменти:
Розгортання власної думки: У діалозі з ШІ контекст і градація впевненості мають задаватися людиною. Якщо у вас є гіпотеза («думаю вивчити»), то для ШІ це має бути марковано саме як Гіпотеза/Намір, а не як Рішення.
Напрямок цитування: Щоб ШІ не «підтягував» ваше «думаю» до 100% рішення, у протокол додається механізм прямого цитування та атрибуції. ШІ повинен не перефразовувати ваші слова на свій лад, а чітко цитувати вихідні дані та маркувати їх статус (наприклад: Статус: Намір/Думка користувача, а не Затверджений план).
Тоді модель не буде самовільно «покращувати» матеріал до суцільної води чи викривляти сенс.
що ж, у сфері ІТ для технічних завдань потрібен саме такий дефолт!
жодних припущень, відповідь конкретно з питання — якщо питання не точне — модель вимагає уточнень — немає відповіді — не фантазувати....
але навіть з такими промтами модель знаходить можливість страждати херней.
потрібно ще «вміти» користуватися моделлю — ось це вже окремий скіл
Дякую, Володимире! Ви влучили в саму суть і підсвітили головний біль ринку.
Те, що модель «страждає хернею» навіть із суворими промптами — це прямий наслідок того, що ми намагаємося рулити текстом, ігноруючи підготовку самої інформації на вході.
І поки ми вважаємо, що «вміти користуватися моделлю» — це особливий особистий скіл або «магія», ми залишаємося в пастці кустарного ремесла. Справжня інженерія починається там, де ми забираємо у ШІ можливість «імпровізувати» ще ДО генерації.
Саме про це я розгортаю наступний Топік: про надбудову-фреймворк «Нульового етапу», яка автоматично готує будь-яку інформацію до структурованого виконання. Вона перетворює взаємодію з ШІ з «мистецтва вмовляння» на автоматизовану інженерну дисципліну з 99% конструктиву. Готую матеріал до публікації!
Ну, фреймвок — це дуже широке поняття — тут йдеться більше про базу знань, про те, який промпт краще підходить для конкретної моделі та для конкретного завдання.
часто бывают случаи что ИИ галлюцинирует, на технических вопросах ( де відповідь визначена) ... але насправді це створення брехливого й марного контенту — та й токени не можна повернути назад....
Володимире, абсолютно згоден — витрачені на галюцинації токени вже не повернути!
Саме тому я зараз працюю над розвитком протоколу у напрямку примусового цитування та прив’язки відповідей ШІ безпосередньо у вікні діалогу.
Коли модель зобов’язана на кожне своє твердження виводити точну циту/посилання з канонічного джерела прямо в ході відповіді, простір для «імпровазу» зводиться майже до нуля. Підключити таку розробку у діалоговий режим технічно не складно — головне сформувати жорсткий семантичний контур, за межі якого модель просто не має права виходити.
на жаль, модель завжди може згенерувати нісенітницю... без інтеграції в саму модель (API) — це така собі справа...
Я бачу ваше рішення — лише як проксі-сервіс...
Проксі — це так, але який?
Чому всі потужності Інтернету, трильйони доларів та файн-тюнінг так і не зупинили галюцинації? Бо всі лікують наслідок, а не причину. Індустрія просто ігнорує системний зсув: похибка закладається ще ДО того, як модель починає генерувати відповідь.
Якщо на вході хаос — на виході завжди буде галюцинація, скільки б мільярдів у модель не влили.
Проксі-шар Semantic Noise Gate — це не про «фільтрацію спаму», а про Нульову фазу підготовки інформації, яка змінює саму фізику входу. Детально про цей алгоритм і чому старий підхід остаточно зайшов у кут — розберу в наступній статті.
проксі робитиме найкращі промти для моделей
Я думаю, це вже перевірена техніка
Володимире, дякую за точний скепсис! Ви підсвітили ключову оману ринку: люди плутають покращення промптів (prompt rewriting) із зміною топології контексту.
Покращений промпт лише «красиво вмовляє» модель.
Наш підхід на Нульовій фазі робить інше:
┌───────────────────────────────────────────────────────────────┐
│ ПОРІВНЯННЯ ПІДХОДІВ НА ВХОДІ В ШІ │
├───────────────────────────────────────────────────────────────┤
│ 1. СТАРДАРТНИЙ ПРОКСІ (Prompt Rewriter): │
│ Хаотичний текст ──> [Покращення формулювання] ──> ШІ │
│ Результат: Красиве прохання, але ШІ все одно галюцинує. │
├───────────────────────────────────────────────────────────────┤
│ 2. SEMANTIC NOISE GATE (Наша Нульова фаза): │
│ Хаотичний текст ──> [Нарізка на Вузли Сенсу чи канонічна структура ] ──> ШІ │
│ Результат: Повна відсутність вільного простору для імпровізації.
Модель працює як детермінована функція. │
└──────┬────────────────────────────────────────────────────────┘
│
▼
[ВИСНОВОК]:
Ми не пишемо промпти за користувача. Ми позбавляємо ШІ фізичної можливості «дофантазовувати» за рахунок попереднього очищення семантичного контуру.
Готую статтю з ознайомленням спільноти застосування інженерного підходу до інформації.
Як показує практика, ознайомлення з теорією без реального тестування таких протоколів майже завжди повертає до старих і неефективних звичок — «вмовляння» ШІ та галюцинацій. Буде цікаво дізнатися, як цей модуль покаже себе, якщо спробуєте прогнати його через свій кейс!
Коментар порушує правила спільноти і видалений модераторами.
Непогано — я про сайт на гітхабі — перший модуль може стане у пригоді
Дякую за відгук, Олег!
Цікаво дізнатися вашу думку: а що саме у першому модулі здалося найбільш потенційно корисним — сам підхід з жорстким обмеженням шуму чи саме подача та структура матеріалу?