Якщо ваша RAG-система чудово відповідає на прямі запитання, але «губиться» коли користувач питає «чому це не працює» або «що не є правдою» — ви зіткнулися з одним із найпоширеніших підводних каменів векторного пошуку. Проблема полягає в тому, як embeddings кодують семантику заперечень: вектори «кіт є собакою» і «кіт не є собакою» бувають дуже близькими в просторі. У цій статті ми детально розберемо, чому так відбувається, і покажемо конкретні технічні рішення, які реально працюють у 2026 році.
🔍 Що таке Embeddings і RAG: швидкий огляд
Embeddings — це числові вектори, які кодують смисл тексту. Модель перетворює слово, речення або документ на масив із сотень чисел (наприклад, 1536 вимірів у text-embedding-3-large від OpenAI). Схожі за змістом тексти мають малу косинусну відстань між векторами. RAG (Retrieval-Augmented Generation) — архітектура, де LLM отримує відповідь не лише зі своїх ваг, а й з динамічно знайдених документів. Процес простий: запит користувача → векторний пошук у базі → топ-K релевантних чанків → LLM генерує відповідь на основі цих чанків. Ця архітектура дозволяє будувати корпоративні чат-боти, системи пошуку в документації та юридичні асистенти без перенавчання моделі. За даними Gartner, до кінця 2025 року понад 60% нових AI-застосунків у бізнесі використовують RAG як базову архітектуру. Але є принципова слабкість: векторний пошук оптимізований під тематичну схожість, а не під логічну структуру речення — і саме тут заперечення стають проблемою.
⚡ Де саме ламається векторний пошук на запереченнях
Проблема має кілька конкретних проявів. Коли користувач запитує «що не підходить веганам у цьому меню», embedding цього запиту буде дуже близьким до документів про веганське меню — бо ключові токени збігаються. Модель поверне контекст про веганські страви, а не про невеганські інгредієнти. Дослідження BerriAI (2024) показало, що стандартні retrieval-системи помиляються на negation-запитах у 34–47% випадків залежно від домену. Ось чотири головні механізми, через які це відбувається:
- Тематичне домінування — іменники та дієслова мають набагато більшу вагу в embedding, ніж частки «не», «ні», «без». Вектор тягнеться до теми, ігноруючи модифікатор.
- Симетрія косинусної подібності — cos(«A є B», «A не є B») може перевищувати 0.92 на моделях типу SBERT, бо обидва речення описують одну пару сутностей.
- Sparse vs Dense проблема — BM25 (keyword-based) чудово бачить слово «не», а dense embeddings його «розчиняють» у загальному контексті.
- Відсутність negation-aware fine-tuning — більшість публічних embedding-моделей навчені на завданнях sentence similarity, де заперечення трапляються рідко і не розмічені окремо.
📊 Порівняння підходів до вирішення проблеми заперечень
Нижче — порівняння трьох основних стратегій, які розробники застосовують у production-системах у 2026 році. Кожна має свій баланс між складністю впровадження і якістю результату.
| Підхід | Складність | Що включено / як працює |
|---|---|---|
| Hybrid Search (BM25 + Dense) | Низька — 1–2 дні інтеграції | BM25 ловить ключове слово «не», dense vector дає семантику; RRF-злиття результатів; підходить для 80% кейсів |
| Query Rewriting + Decomposition | Середня — потрібен LLM-проміжний шар | LLM переформулює «що НЕ підходить» → «список протипоказань»; усуває заперечення до пошуку; точність +18–25% |
| Negation-aware Fine-tuning | Висока — потрібен датасет і GPU | Спеціальні contrastive pairs з негацією в training loss; моделі типу e5-mistral-negation; найкраща якість у вузькому домені |
✅ Переваги та недоліки RAG при роботі із запереченнями
Переваги:
- Hybrid Search вирішує 70–80% проблем із запереченнями без перенавчання моделі — достатньо налаштувати Elasticsearch або Weaviate з увімкненим BM25-компонентом.
- Query Rewriting через GPT-4o або Claude 3.5 Sonnet дозволяє обробляти складні логічні конструкції («ні X, але й не Y») та перетворювати їх на структуровані запити за ціну ~$0.002 на запит.
- RAG-архітектура залишається гнучкою — зміна стратегії retrieval не потребує перенавчання LLM, лише апдейт pipeline.
- Metadata filtering як доповнення до векторного пошуку дозволяє явно тегувати документи атрибутом «negation_context: true» і виключати або включати їх незалежно від embedding-відстані.
Недоліки:
- Query Rewriting додає 200–400 мс латентності та збільшує вартість пайплайну в 1.5–2 рази через додатковий LLM-виклик перед retrieval.
- Fine-tuned embedding моделі під негацію потребують якісного датасету з мінімум 5000–10000 пар «позитив/негатив», який для більшості бізнесів потрібно створювати вручну або синтетично — це 2–4 тижні роботи.
💡 Як виправити: покроковий гайд із конкретними діями
Ось практична інструкція для команди, яка хоче виправити проблему заперечень у своїй RAG-системі прямо зараз:
Крок 1. Діагностика. Зберіть тестовий набір із 50–100 реальних запитів із запереченнями від ваших користувачів. Запустіть їх через поточну систему і вручну оцініть якість retrieval (precision@5). Якщо точність нижче 60% — проблема підтверджена.
Крок 2. Увімкніть Hybrid Search. У Qdrant, Weaviate або OpenSearch активуйте sparse+dense hybrid mode. У Weaviate це параметр alpha=0.5 в BM25+vector запиті. Одразу перевірте на тестовому наборі — зазвичай це дає +10–15% precision без жодного fine-tuning.
Крок 3. Додайте Query Rewriting. Перед векторним пошуком додайте LLM-виклик із промптом: «Перепиши запит так, щоб прибрати негацію і явно описати, що шукається. Якщо запит містить ‘не X’ — сформулюй як ‘альтернативи X’ або ‘виключення X’.» Використовуйте легку модель — gpt-4o-mini або Gemini Flash 2.0 для мінімізації затримки.
Крок 4. Metadata-теги для критичних документів. Якщо у вашій базі є документи з протипоказаннями, обмеженнями, винятками — тегуйте їх явно. Додайте фільтр: якщо в запиті є слова «не», «заборонено», «не можна» — підвищуйте ранг документів із тегом negation_context.
Крок 5. Моніторинг і ітерація. Інтегруйте Ragas або TruLens для автоматичної оцінки retrieval якості. Встановіть алерт на падіння precision@5 нижче порогового значення. Переглядайте failed cases щотижня — 20% найчастіших типів помилок покриють 80% проблем.
❓ Часті запитання (FAQ)
1. Чи всі embedding-моделі однаково погано обробляють заперечення?
Ні. E5-large-v2 і GTE-Qwen2-7B показують кращу обробку негацій ніж older SBERT-моделі. Але навіть найкращі публічні моделі мають accuracy на negation-бенчмарках (NegBERT, Not-NLI) на рівні 71–78%, тоді як на звичайних задачах — 90%+.
2. Чи достатньо просто змінити embedding-модель на новішу?
Зміна моделі дає приріст 5–12%, але не вирішує проблему фундаментально. Найефективніший підхід — комбінація hybrid search + query rewriting, яка дає 25–35% покращення незалежно від базової моделі.
3. Як виміряти, наскільки серйозна проблема у моїй системі?
Запустіть BEIR-negation subset або власний тест: візьміть 30 документів, сформуйте запити-заперечення («що не можна робити з продуктом X»), перевірте чи потрібні документи потрапляють у топ-5. Якщо precision нижче 55% — проблема критична.
4. Чи допоможе збільшення кількості retrieved chunks (top-K)?
Частково. Збільшення K з 5 до 20 підвищує recall, але одночасно засмічує контекст LLM нерелевантними чанками, що знижує якість фінальної відповіді. Це workaround, а не рішення — краще виправити retrieval на рівні scoring.
5. Що робити, якщо у мене мало GPU і немає ресурсів на fine-tuning?
Hybrid search і query rewriting не потребують GPU взагалі — це зміни на рівні архітектури пайплайну. Fine-tuning рекомендується лише для висококритичних доменів (медицина, право), де точність важливіша за швидкість впровадження.
🏁 Висновок
Проблема заперечень у RAG — не баг конкретної бібліотеки, а архітектурна особливість того, як dense embeddings кодують мову. Векторний пошук блискуче вирішує тематичну релевантність, але логічні модифікатори типу «не», «окрім», «всупереч» він обробляє слабко. Ця стаття показала три рівні рішень: від швидкого hybrid search до глибокого fine-tuning — кожне з конкретними цифрами ефективності.
Hybrid Search + Query Rewriting рекомендуємо як baseline для будь-якого production RAG у 2026 році — незалежно від домену. Fine-tuned негацій-aware моделі варто розглядати командам, які будують системи в медичному, юридичному або фінансовому секторі, де хибна відповідь на заперечення може мати реальні наслідки. Для стартапів і MVP — починайте з hybrid search, це 2 дні роботи і відчутний приріст якості.
Наступний практичний крок: зберіть ваші 50 найпроблемніших запитів із запереченнями, запустіть A/B тест між поточною системою і hybrid search у Qdrant або Weaviate, та виміряйте precision@5. Результати здивують вас — і дадуть чіткий аргумент для інвестицій у покращення retrieval-шару вашої AI-системи.
РОЗСИЛКА
📬 Щотижневий AI-дайджест
Найкращі статті про ШІ та автоматизацію — без спаму, лише суть
Без спаму · Відписатись будь-коли