Векторна база — це мапа, а не джерело: що ми з'ясували про пошук

🗺️ Що дає пошук

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

Саме тому ми вживаємо слово «мапа». Вона підказує, де шукати. Вона не каже, що там лежить.

🧭 Як побудована наша внутрішня база

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

Кожен результат несе три поля: шлях до файлу, sha256 файлу на момент індексації та час індексації. Агенту сказано відкрити файл за цим шляхом і порівняти хеш, перш ніж покладатися на текст. Результат, чий хеш не збігається, застарілий.

📏 Один вимір, який змінив нашу звичку

15 жовтня 2026 року ми поставили базі відкрите питання «чому агент зупинився», і першими результатами були довгі бізнес-дослідження, а не короткий висновок, у якому була відповідь. Запит за типом це виправив. База підтримує фільтри для правил, пам'яті, передач змін, специфікацій і досліджень. Фільтр за типом шукає по всій базі, тож навіть рідкісний тип усе одно повертає свої найкращі результати.

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

🛠️ Практика: зробіть пошук надійним

1. Зберігайте шлях, хеш вмісту й час індексації разом із кожним фрагментом.
2. Додавайте тип або вид джерела кожному фрагменту й виводьте його як фільтр.
3. В інструкціях для агента напишіть: «знайдений текст — це вказівник; відкрий джерело й перевір хеш; числа беруться з артефакту».
4. Складіть невеликий тестовий набір: двадцять питань із документом, який має бути першим. Напишіть набір до того, як спробуєте систему, і ніколи не правте його потім, щоб поліпшити оцінку.
5. Вимірюйте, як часто потрібний документ потрапляє до першої трійки. Подавайте число разом із датою.
6. Додайте графік перебудови й перевірку, яка позначає результати, старші за їхній файл.

✅ Перевірте себе

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

🚧 Коли це не працює

• Точні пошуки. Для id, назви чи числа кращий пошук за ключовими словами. Не замінюйте його векторами.
• Застарілий вміст. Якщо ви рідко перебудовуєте базу, вона повертає вчорашню правду. Плануйте перебудову.
• Отруєні джерела. Будь-що проіндексоване може містити інструкції, призначені для моделі. Фільтруйте на вході й тримайте права вузькими.
• Короткі схожі документи. Багато майже однакових сторінок ділять свою оцінку, і жодна не перемагає. Об'єднуйте або прибирайте дублікати.
• Надмірна довіра до першого результату. Перший результат — найближчий, а не правильний. Читайте три.

📊 Докази

➡️ Далі

Подивіться, як сторінки й джерела з'єднуються, у Зв'язки, зворотні посилання та граф знань, і прочитайте Контекстні вікна та токени про те, що агент може вмістити з одного результату.

Джерела

• Зв'язки, зворотні посилання та граф знань: як сторінки посилаються одна на одну.
• Контекстні вікна та токени: що вміщається в запит.
• Джерела, дати й що означає «перевірено»: як ми позначаємо докази.
• Чому AI-агенти вигадують і як перевірити відповідь: перевірка відповідей.