Галюцинації ≠ випадковість: без «IDK» модель змушена відповідати

Ваш агент впевнений на 99%? Перевірте: можливо, він 100% вигадав.

Галюцинації — це не баг, це очікуваний результат навчання. Якщо модель ніде не навчають відповідати «не знаю», вона відповідає будь‑що, аби не мовчати. 🤖
Мій агент упевнено «знайшов» статтю, якої не існує. Тон упевнений, посилання — вигадане. Причина проста: під час навчання моделі не були включені кейси в яких модель відповідала б "I don't know" і не отримувала за такі відповіді додаткових балів під час навчання.
Суть. Більшість моделей під час навчання не використовують «IDK» (I don't know) в даних і в метриках якості. Тому модель оптимізують за «відповідай краще», а не «визнай невпевненість». У результаті — надмірна впевненість і вигадки навіть там де це не очікується. Це добре узгоджується з висновками недавньої роботи на arXiv (https://www.arxiv.org/pdf/2509.04664). 🧠
Можливі опції що з цим робити сьогодні:
- очікуємо foundational model яка буде навчена з врахуванням «IDK»
- файн тюнимо свою модель на базі існуючих OSS / open weights models з «IDK» тестами
- загружаємо в контекст моделі необхідну інформацію і робимо grounding (базуємо відповідь лише на даних з контекста).
Під час використання foundational models використовуємо рекомендації щоб уникнути галюцинацій такі як наприклад від anthropic (https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/reduce-hallucinations#basic-hallucination-minimization-strategies).

А як ви зараз боретеся з галюцинаціями та чи доводиться вам з ними стикатися?

Як я стискаю AI-новини за 15 хв і не вигораю
Мій рецепт економії часу для AI-апдейтів: простий ноутбук + 4 кроки.
AI-новин більше, ніж часу. Мій апдейт тепер займає ~15 хв замість цілого вечора. ⏱️Як я це роблю: завантажую в NotebookLM 10–20 останніх роликів з новинами на YouTube і прошу: “Виділи головне та як це вплине на розробку систем на горизонті 6–12 місяців.” Результат — короткі тези і “чому це важливо для девів”. ✅
Ось приклад ноутубука де можна також згенерувати аудіо, відео, майндмеп або ще щось (якщо немає часу дивитись і потрібен "подкаст") https://notebooklm.google.com/notebook/f58bd70a-79ad-4c76-bd51-712e6095c15b
Мінус: API для NotebookLM я не знайшов (можливо, його й справді немає).
Тож планую зробити свій фід: агрегую джерела → ранжую локальними ЛЛМ → роблю короткі брифінги. Локальні моделі майже безкоштовні й дають пристойну якість. 💻
Порада проти “галюцинацій”: NotebookLM “з коробки” галюцинує мінімально, а для інших моделей просіть позначати сумнівні місця, давати короткі цитати з джерел та окремо пояснювати “чому це важливо”.Краще зробити простий фактчек, ніж мати красивий, але такий, що не спирається на дані, дайджест.
Хештеги: #agents #AI #automation #vibecoding #productivity
Як ви зараз фільтруєте AI-новини: вручну, через RAG/агентів чи готові дайджести — і що болить найбільше?

Copilot CLI і нова хвиля “агентів у терміналі”

GitHub викотив новий Copilot CLI (публічний прев’ю) — це не просто “ще одна тулза”, а підтвердження тренду: vibe‑coding інструменти дедалі більше покривають сценарії без прямої участі програміста. (https://github.blog/changelog/2025-09-25-github-copilot-cli-is-now-in-public-preview?utm_source=openai)

Сьогодні рутину типу code review чи генерації тестів можна знімати стеками: Claude Code, Copilot CLI, Cursor, Codex CLI. І це не теорія — є живі конфіги для CI/CD і security‑рев’ю.

Приклади:

OpenAI Cookbook: Codex CLI в GitLab, що збирає CodeClimate‑репорт і навіть пропонує патчі.
(https://cookbook.openai.com/examples/codex/secure_quality_gitlab?utm_source=openai)
Anthropic: /security‑review у Claude Code з GitHub Actions. (https://www.anthropic.com/news/automate-security-reviews-with-claude-code?utm_source=openai)

Але. Навіть якщо завтра Claude напише вам фронт і шмат бекенду — роль девелопера лишається: тримати рамки. Інакше ризик “архітектурного заносу”: з нізвідки підключився ClickHouse, або React тихо перетворився на Angular. 🙂

Обовязкові guardrails, щоб не злетіти з траси:
1 Задекларуйте дозволений стек включаючи бази в README / RULES / Claude.md
2 Обовязкові політики і рули в лінтері + обовязковий лінтер в CI (наприклад за допомогою https://npmpackagejsonlint.org/docs/rules/dependencies/no-restricted-dependencies)
3 Агенти — тільки “diff‑first”: усе через PR із чітким описом змін
4 На всіх кінцях в обовязковому порядку прописані контракти (наприклад OpenAPI або https://www.asyncapi.com/) і валідація для JSON‑виводу і валідація (https://cookbook.openai.com/examples/codex/secure_quality_gitlab?utm_source=openai)
5 Мінімальні патчі > “розумні” рефакторинги.

Ну і так... в мене поки що просто копілот CLI перманентно глючить...
https://github.com/github/copilot-cli %)

Anthropic щойно випустив підтримку для plugin marketplace у Claude Code.
Чому це важливо?
Бо кожен з розробників має свої підходи для розробки, свої хуки, агентів і т. ін.
Можливість використовувати маркетплейси дозволяє шерити всі ці частини SDLC в рамках команд та більш широкого загалу.

Оригінал новини тут:
https://docs.claude.com/en/docs/claude-code/plugin-marketplaces

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

Враховуючи що сьогодні лише перший день коли функціональність може бути використана я знайшов лише одного автора який вже зробив marketplace.json доступним. Ось його репозиторій
щоб додати маркетплейс відкриваєте клод код, /plugin заходите в Add MarketPlace і вводите кординати до репозіторія. Після цього ви можете бачити у списку плагінів всіх сабагентів яких він пропонує. Впевнений що скоро там зявляться і його хуки.
А може й ваші 😉

доволі активно попрацювавши з BMAD v6 на цьому тижні можу сказати наступне:
він набагато краще фоловить воркфлоу. самостійно без нагадування апдейтить документи і повертається до процедури навіть якщо його "відволікли".
в цілому набагато більше сфокусований, при цьому не намагається додавати умовно кажучи редіс там де не просили і 10 баз там де не потрібно.
сам себе критикує, сам виправляє помилки і в результаті дуже гарно справляється з green field девелопментом.
коли робить апдейти документів - робить їх прям дуже спрямовано без зайвого шуму (одразу змінює саме те що необхідно змінити. без пошуку, відкривання "не тих файлів" і т.ін)
є конвенції типу FR (functional requirements), NFR (non-functional requirements). Все ще присутній процес ідеації. Але наразі це навіть порівнюючи з v4 набагато більш доречні пропозиції, і, звісно... результати.
додатково все ж таки з`явився PRD документ в якому фіксують ці самі реквайрменти і т.ін.

Anthropic перший зрозумів що передача всіх відповідей від MCP тулів у LLM модель - доволі не ефективна історія. Поперше bandwidth моделі не резиновий і доволі часто є обмеженням у enterprise environments.

Наприклад ми стикалися з тим що AWS деяким клієнтам не бажав збільшувати цей самий bandwidth для Claude моделей. Звісно є і "кохані" клієнти яких всі люблять і там ці питання вирішуються швидко. Але...

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

Також, для того щоб моделі почали використовувати тули необхідно щоб під час "створення агента" модель знала про наявність тулів, їх методів і т.ін. Для цього використовуються ті ж самі токени, які заповнюють контекстне вікно моделі (фактично це стає частиною вашого system prompt) і це призводить до того що кожен раз коли виконується запит до LLM ви платите грощі за "підтримку кожної тули".

Якщо в рамках нашого workflow використовуються складні структури даних або великі обсяги інформації - вірогідність помилок під час копіювання інформації збільшується.

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

Тож anthropic вигадав використовувати MCP сервери як API замість визовів тулів. Фактично це дає можливість реалізувати lazy loading замість того щоб на етапі проектування додавати всі моделі і одразу загружати інформацію про них в контекст.

Модель бере умовно кажучи заголовки і вичітує їх при потребі що (на прикладі Anthropic) зменьшило використання токенів з 150 000 до 2 000 за одну операцію. Це, доречі, час на виконання операції теж зменьшує суттєво.

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

Оригінал тут:
https://www.anthropic.com/engineering/code-execution-with-mcp

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

Agent Skills від Anthropic - це спроба дати агентам можливість виконувати конкретні інструкції для виконання конкретної задачі.
Навичка (skill) - це не монолітна інструкція, а набір знань і процедур, які не засмічують контекст кожної сесії. Для розробників, що практикують вайб‑кодінг і тісно спілкуються з моделлю під час роботи, ця ідея звучить практично: менше тягнути в промпт наперед, більше читати й виконувати по мірі потреби. Виходить прозоріше, дешевше, стабільніше. І це помітно вже з перших ітерацій.

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

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

Ще одна корисна опція - описувати навички не обовʼязково текстом. Навички підтримують можливість виконуваний код, який агент викликає замість багатослівних описів кроків. Коли процес краще зловити функцією, а не абзацом, код дає надійність і повторюваність.

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

Оригінал можна подивитись тут: https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills

https://www.youtube.com/shorts/aIvHf8vsWBM

один з ярчайших людей у сучасному ШІ. Ілля Суцкевер. Про vibe coding і причини чому агенти пропонують фікс до однієї проблеми і в ньому повертаються до іншої.

https://www.youtube.com/watch?v=aR20FWCCjAs

повне інтервью тут і я вважаю що саме такі інтервʼю як і інші фундаментальні роботи якнайкраще заставляють замислитись щодо того які проблеми ми бачимо, куди рухається ШІ світ і де ми будемо за 3-5 років.

https://mistral.ai/news/mistral-3

а тим часом містраль все ж таки випустив нові моделі %)

тож прошу дивитись і насолоджуватись! %)

як на мене моделі дуже цікаві. enjoy! 😉

містраль намагається робити невеликі сфокусовані моделі які досягають дуже гарного cost / benefits співвідношення.

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

А тим часом кодекс вже почав (поки що в експериментальному режимі) підтримувати скіли. Що це означає: меньше проблем з менеджментом контексту та більше токенів для контексту який ми самі створимо замість забитого MCP. Дешевші взаємодії з ллм. І меньше часу на генерацію відповідей.
https://share.google/A06J4BucP6BeEB5pV

Оригінал ідеї скілів тут
https://share.google/6y4UV7gIol3EqrkKo

Здається і на нашій вулиці свято!

https://openrouter.ai/docs/guides/guides/claude-code-integration

У опенраутер занесли інтеграцію з Claude Code.

У великому відсотку випадків я все ще вважаю що це найкращий тул для агнетного кодінгу. Окрім випадків коли вам потрібно бачити або контролювати до останньої коми код який ви пишете.

З цікавого в claude code нещодавна занесли LSP. Що це означає?
що пошук символів в CLI based тулах буде знаходити всі "entries" як це зараз робить ваша IDE. Це суттєво пришвидшить якість рефакторингу і покращить роботу з наприклад оверрайдами методів. Тож в наступному році нас чекає ще більше цікавих прикладів використання і все більше інструментів для написання коду який ми вже пишемо.

Якщо комусь цікаві новини вайб кодінгу - слідкуйте за
https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
https://developers.openai.com/codex/changelog/
та
https://geminicli.com/docs/changelogs/

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

https://wisprflow.ai/r?MAKSYM77

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

Доречі, вважаю що в цій роботі дуже гарно розкладені причини чому ж моделі галюцінують

https://arxiv.org/html/2504.14764v1

Мова як інструмент несе дуже багато невизначеності. Більш того, моделі навчають досягати мети, а як можна досягти мети наприклад "будь гарним хлопцем?"
Тож питання якості роботи агентів мусить бути хоча б вимірюваним для того щоб зрозуміти чи вони відповідають очикуваному рівню якості.

У роботі приводяться три острови:
- острів специфікації
- острів розуміння
- острів генералізації

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

Read “Ralph Wiggum, explained: the Claude Code loop that keeps going“ by JP Caparas on Medium: https://jpcaparas.medium.com/ralph-wiggum-explained-the-claude-code-loop-that-keeps-going-3250dcc30809

Цікавий паттерн роботи з консольними тулами для вайб кодінгу. З наступного тижня будемо розбирати на курсі! З нуля для тих хто не дивився у бік технологій що воно таке та як використовувати. Крок за кроком.

Нещодавно вийшов новий Claude Code 2.1, а днями, якщо довіряти чуткам виходить Claude 4.7...

2.1 буквально за два тижні викатили до фіга апдейтів до

Навичок та Слеш-команд
Хуків
Дозволів
Фонових Завдань
Агентів та Субагентів
Управління Сесіями
Обробки Зображень
Інтеграції LSP
Система Плагінів та маркетплейсів
Конфігурація та Налаштування
Мультитенантної Архітектури

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

Такого протистояння майже ніколи не було в комерційних тулах... Тому дуже цікаво наблюдати як може виглядати так звана RAD (швидка розробка аплікації)

А тим часом адопшн клод кода зростає з шаленою швидкістю. 4.5 вже на першому місці на лідерборді опенраутері.

https://x.com/i/status/2011823610386600009

а ви знаєте що xml останнім часом використовується все більше?!

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/use-xml-tags

мовні моделі і їх промптінг все ще не дають 100% гарантії результату.
більше того... скоріш за все з трансформерами і не дадуть.
втім промпт інженери намагаються знайти всі можливі способи для того щоб від 50%-70% вірогідності досягти до 90% або навіть вище.
більш за те, моделі не завжди знають як їм виявити чи закінчила людина свою думку чи ні?

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

як це виглядає:

<команда>
знайди інформацію про...
</команда>

<додатковий контекст>
шукати необхідно тут, там і ще десь
</додатковий контекст>

<формат>
- рік у форматі РРР-м-д
- ПІБ
- розмір одягу
</формат>

У MiniMax підвезли підтримку MLX
Що це означає? Що тепер його можна ранати на Маках використовуючи залізо на повну.

https://github.com/MiniMax-AI/MiniMax-M2.1

Як то кажуть... enjoy! 😉

Оце так новина. Для мене це було критерієм важкого програмування...
Довгий час агенти не могли впоратися з цією задачею... Але здається зараз рахунок іде на дні і години...
https://search.app/YuQZk