Технічний контекст
Я якраз люблю такі атаки: зовні нічого «злого» не відбувається, а агент все одно з’їжджає не туди. У цій роботі автори показують новий вектор проти multi-hop RAG, де ламають не факти, а значущість. Для тих, хто будує AI automation і AI integration з пошуком по документах, це дуже неприємний клас помилок.
Суть проста й підступна. Текст залишається фактично правдивим, але в ньому змінюють порядок, акценти, близькість фрагментів, формулювання та рамку подачі так, щоб модель зв’язала не ті атрибути під час багатокрокового міркування. Тобто б’ють не по truthfulness, а по salience, і ось тут багато пайплайнів взагалі сліпі.
Я подивився на заявлену механіку: у авторів шість класів salience-редагування та ітеративний proposer-verifier pipeline з обмеженнями на правдивість і прихованість. Це вже не «брудний» prompt injection, який можна ловити фільтрами за інструкціями. Тут агент читає нормальний текст і сам помиляється у зв’язуванні сутностей.
За цифрами робота теж неприємна. При бюджеті редагування 30% вони отримують 83,3% attack success rate на кількох сімействах моделей, включаючи GPT, Claude, Gemini, DeepSeek та Qwen, а також на ReAct, Reflexion і tool-calling агентах. Найпоказовіше для мене: найсильніший базовий захист усе ще залишає 75,7% post-defense ASR.
Окремо зачепив захист Salience Normalization. Він input-side, тобто його можна вбудовувати без повної перебудови AI architecture, і в статті знижує ASR до 15,3%, а під adaptive attack до 23,6%. Якщо ці результати підтвердяться на практиці, це вже не академічна дрібниця, а цілком прикладний шар захисту.
Що це змінює для бізнесу та автоматизації
Перше: «правдивий контекст» більше не дорівнює «безпечний контекст». Якщо у вас RAG-агент збирає відповіді з CRM, бази знань, тікетів і зовнішніх джерел, то однієї перевірки на хибні факти та інструкції вже недостатньо.
Друге: під ударом саме багатокрокові сценарії. Чим складніше агент зв’язує сутності між документами, тим вищий шанс тихої помилки, яка виглядає переконливо. Для саппорту, комплаєнсу, аналітики та внутрішніх copilots це болючіше, ніж звичайний шум retrieval.
Я б уже зараз додавав до пайплайну нормалізацію представлення контексту, тести на misbinding і red-team набори не тільки з injection, але й з salience-маніпуляцією. Ми в Nahornyi AI Lab вирішуємо такі речі для клієнтів на рівні AI solution development: не просто підключаємо RAG, а перевіряємо, де агента можна відвести без жодного хибного рядка.
Якщо у вас уже обертається retrieval-агент і відповіді виглядають «начебто логічно, але іноді дивно», я б не списував це на випадковість. Можна разом із Vadym Nahornyi та Nahornyi AI Lab швидко розібрати ваш контекстний пайплайн і зібрати захист під реальну AI automation, поки така тиха атака не перетворилася на дорогу системну помилку.