grep перевершив метод векторного пошуку у тестах пам’яті агента, і вибір інструментів мав таке ж значення.

Системи з підсиленням пошуку довгий час ґрунтувалися на одній переконаності: векторний пошук кращий за пошук за ключовими словами, оскільки він враховує сенс. Запит на „документи про квартальні результати“ знаходить „Звіт про дохід за 3-й квартал“, навіть якщо ці фрази не мають спільних слів, адже простір вкладення розглядає їх як близькі. Ця переконаність спричинила величезні витрати на створення інфраструктури — від Pinecone та Weaviate до Chroma та Qdrant. Ранні дослідження щодо пошуку у детальних текстах показали, що векторний пошук кращий за розріджений алгоритм BM25 у відповідях на запитання в відкритих доменах; галузь прийняла ці результати, і векторний пошук став стандартом.

У дослідженні 2026 року був проведений інший експеримент. Агентам було поставлено завдання з пошуку інформації з бази LongMemEval – метрики, у якій агент має відповідати на запитання, шукаючи в довгих історіях розмов. У тесті протиставлялися grep, що здійснює просте точне зіставлення рядків, та векторний пошук. Експеримент проводився з використанням кількох інструментів для керування агентами: спеціального інструменту під назвою Chronos, а також вбудованих у провайдера інструментів командного рядка Claude Code, Codex та Gemini CLI.

У основному варіанті тестування grep виявився кращим за векторний пошук за точністю, і це сталось у всіх інструментах, а не лише в одному.

Короткий опис

• Умови тестування: 116 запитань з LongMemEval, порівняння grep та векторного пошуку, чотири інструменти керування, ідентичні дані розмов.
• Основний результат: при поверненні результатів безпосередньо в тексті grep перевершив векторний пошук за точністю у всіх випробуваних випадках.

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

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

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

Незручне запитання: наскільки перевага, яку приписують кращому пошуку у продакшн-системах RAG, насправді пояснюється кращим дизайном ременя безпеки?

Чому grep підходить для запитань про пам’ять

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

Метод векторного пошуку вбудовує запитання, знаходить фрагменти розмови з схожими векторними представленнями та повертає їх. Проблема полягає у тому, що близькість у значенні не означає наявності точного факту. Фрагмент про їжу взагалі знаходиться поблизу терміна „улюблений ресторан“ у просторі векторів. Він може взагалі не називати ресторан, проте має високий рейтинг та не містить жодної відповіді.

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

Vector retrieval:  high recall on semantically related segments
                   lower precision on exact-fact queries
                   noise from semantically similar but fact-absent segments

grep:              perfect precision on string matches
                   lower recall on paraphrased or implicit facts
                   no noise from semantic neighbors

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

Ефект „харнесу“

Найважливішим відкриттям є не використання grep з векторами, а сам інструмент обробки даних. За однаковим методом пошуку, однаковими даними та однаковими запитаннями точність суттєво змінюється залежно від обраного інструменту. Наведені цифри демонструють масштаб різниці: модель Claude Opus досягає 93,1% точності за допомогою Chronos та 76,7% — за допомогою Claude Code, тож заміна інструменту приблизно настільки ж впливає на результати, як і заміна засобу пошуку всередині фіксованого інструменту. Найбільша різниця між grep та векторними методами спостерігалась на платформі Chronos із використанням Gemini 3.1 Flash-Lite — 86,2% проти 62,9%.

Інструмент обробки даних виконує чотири функції:

1. Він викликає засіб пошуку з запитом.
2. Він отримує результати пошуку.
3. Він передає ці результати моделі.
4. Модель аналізує їх, щоб дати відповідь.

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

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

Ніхто не стандартизував ці варіанти вибору, і кожен постачальник має власний інтерфейс командного рядка. Виявилося, що спосіб передачі даних має велике значення. Передача результатів безпосередньо в тексті сприяла використанню grep, тоді як передача їх у вигляді файлів, які модель читає окремо, змінювала ситуацію з порівняння: пошук за векторами випередив grep приблизно у половині пар „харнес“–модель. Одна налаштування Codex зі 93,1% при використанні grep безпосередньо в тексті знизилась до 55,2%, коли результати grep передавалися у вигляді файлів.

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

Додавання відволікаючих елементів

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

Обидві методи втрачають точність у міру збільшення кількості відволікаючих елементів, що є очікуваним. Проте криві їхньої продуктивності відрізняються. При запитах на точне знаходження інформації grep погіршує свою продуктивність більш плавно. Якщо відповідний фрагмент містить шаблон запиту, grep знаходить його незалежно від кількості оточуючих його відволікаючих елементів, оскільки ці елементи не збігаються зі шаблоном та ніколи не з’являються у результатах.

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

Accuracy = f(retrieval_precision × harness_quality)

grep retrieval precision: high for exact facts, stable with distractors
vector retrieval precision: moderate, degrades with semantically similar distractors

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

Що це означає для літератури з пошуку інформації

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

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

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

Уважне читання результатів

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

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

Висновок полягає не у використанні grep. Слід підбирати метод пошуку відповідно до розподілу завдань та ретельно проектувати інструменти, як і сам алгоритм пошуку. Жоден з цих підходів поки що не є стандартною практикою, хоча обидва мали б нею стати.

Питання до вашої власної системи

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

Пов’язана література

• Agentic RAG: Дозвіл LLM вирішувати, коли та де здійснювати пошук — Чому статичний RAG не справляється з багатоетапними та часозалежними запитами, та як агент LangGraph організовує пошук між Qdrant та веб-пошуком, враховуючи певні обмеження та застереження.

Практичні нотатки: Три рівні Google Cloud RAG: векторний пошук, двигун RAG та механізм отримання даних від агента — Детальний пошаговий огляд Практичних нотаток: Три рівні Google Cloud RAG: векторний пошук, двигун RAG та механізм отримання даних від агента: контракти, перевірки та місця для вставки коду.

Практичні нотатки: RAG мертвий. LLM Wiki — ідея Андрея Карпаті — це те, що буде далі — Детальний пошаговий огляд Практичних нотаток: RAG мертвий. LLM Wiki — ідея Андрея Карпаті — це те, що буде далі: контракти, перевірки та місця для вставки коду для команд, які реалізують RAG.

Відстеження роботи Voice RAG Agent за допомогою LiveKit, Qdrant та MLflow — Створення асистента для обробки голосових команд у сфері іпотеки з використанням LiveKit, LlamaIndex та Qdrant, з відстеженнями через OpenTelemetry у MLflow, які показують кожен крок отримання інформації та роботи з LLM.

Експертний підхід до RAG: HyDE, стиснення даних, самостійне запитування та агентські робочі процеси — Чотири передові техніки отримання інформації для практичного використання в RAG у Haystack: HyDE, контекстуальне стиснення, самостійне запитування та агентські робочі процеси, з поясненням, коли використовувати кожен з них.

Шар за шаром: проектування справжньої системи отримання даних RAG для штучних інтелектуальних агентів — Складіть систему RAG за допомогою контрактів SourceDocument та DocumentChunk, процесу чанкінгу, ембеддингів та ChromaDB, усе це через RetrievalService, який забезпечує стабільність агента.

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

Практичні нотатки: Штучним інтелекту-агентам більше не потрібен векторний пошук: усередині системи Agentic — Детальний огляд Практичних нотаток: Штучним інтелекту-агентам більше не потрібен векторний пошук: усередині системи Agentic, стек пошуку, який замінить RAG у 2026 році: контракти, перевірки та готовий код.