Технічний контекст
Я заглибився в сам paper від Stanford після чергової тези в стилі «до 10 тисяч векторів RAG ще живий, після мільйона вже сміття». І тут я одразу зупинився: у цій роботі такого емпіричного порогу немає.
Документ, на який усі посилаються, це Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools. У ньому досліджують legal RAG-інструменти на кшталт Westlaw і LexisNexis, порівнюють їх із GPT-4 на юридичних завданнях і дивляться, як часто системи вигадують факти, плутають джерела чи спотворюють висновки.
Результат неприємний, але корисний: retrieval знижує кількість галюцинацій порівняно з «голою» моделлю, проте не зводить їх до нуля. Залежно від інструменту, помилки все ще помітні, приблизно в діапазоні 17-33%.
А ось історій про «10k векторів — це норм, 1 млн — це вже шум» у цьому paper я не знайшов. Ані графіків за розміром індексу, ані бенчмарків по precision@k на великих колекціях, ані аналізу деградації retrieval при зростанні корпусу там немає. Тобто як інженер я б не цитував це як доведений факт.
Але сама думка виникла не на порожньому місці. У production я і без цього paper багато разів бачив, як погано спроєктований векторний пошук починає тягнути напіврелевантне сміття: слабкі ембединги, неправильний чанкінг, кривий metadata filter, занадто щедрий top-k. І потім люди звинувачують модель, хоча проблема в AI architecture та retrieval-шарі.
Якщо коротко: Stanford показав не межу в 10k векторів, а більш приземлену річ. Навіть дорогий юридичний RAG не дає права відключати перевірку відповіді та вдавати, ніби питання надійності вже закрите.
Що це змінює для бізнесу та автоматизації
Для команд, які будують AI automation на документах, висновок простий: «додамо RAG, і все стане достовірним» не працює. Особливо в legal, compliance, policy та внутрішніх базах знань.
Виграють ті, хто проєктує retrieval як систему: гібридний пошук, жорстка фільтрація, reranking, обмеження контексту, трасування джерел. Програють ті, хто просто заливає мільйон шматків у векторну базу та чекає на магію.
Ми в Nahornyi AI Lab якраз розбираємо такі вузькі місця на практиці: де потрібен RAG, де краще knowledge graph, а де взагалі дешевше й надійніше зробити інший шар AI integration замість нескінченного накачування векторів. Якщо у вас пошук по документах вже «шумить» або відповіді не можна випускати в прод, давайте подивимося на архітектуру та зберемо AI solution development без крихких припущень.