Как работи RAG чатбот?

Попитайте обикновен езиков модел какъв е срокът ви за връщане на стока и ще получите отговор. Може дори да е добре написан. Просто няма да е вашият срок. Точно тази разлика е причината да съществува retrieval-augmented generation.

И така, как работи RAG чатбот? В четири хода: разрязва документите ви на части, превръща всяка част във вектор, търси сред тези вектори в момента, в който пристигне въпрос, и подава намереното на езиков модел, който изписва отговора. Първо търсене, после генериране. В този ред е целият номер. Ако искате първо определението на човешки език, прочетете какво е RAG чатбот и се върнете тук за механиката.

Първо търсене, после генериране

Архитектурата не е нова. Идва от статия от 2020 г., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, в която Патрик Люис и колегите му свързват генеративен модел с търсим индекс на Уикипедия и показват, че комбинацията бие моделите, разчитащи само на обучението си.

Полезното разграничение от тази статия е между два вида памет. Езиковият модел има параметрична памет: всичко, което е поело по време на обучението, вградено в теглата му, невъзможно за редакция и невъзможно за проверка. Индексът за търсене е непараметрична памет: хранилище, което е ваше, което можете да прочетете, да поправите и да смените във вторник следобед.

Това има напълно практическо следствие. Когато условията ви за доставка се променят, не преобучавате нищо. Обновявате документа, индексирате го наново и следващият отговор вече отразява промяната. Никой не пипа модела.

Стъпка едно: документите се разрязват на части

Първо е поглъщането на данните. PDF-ите, статиите от помощния център, продуктовите страници, ценоразписите, договорите и експортите от таблици се изтеглят, изчистват се от форматиращия шум и се разделят на парчета, които системата може да намира поотделно. Наръчник от 40 страници е безполезен като единица за търсене. Един абзац за връщането на стока е точно с правилния размер.

Колко голямо трябва да е едно парче? Материалът на Anthropic за contextual retrieval описва обичайната практика като части от не повече от няколкостотин токена, което се равнява горе-долу на абзац или два. Компромисът важи и в двете посоки. Твърде голямо парче влачи със себе си неотносим текст, който размива отговора. Твърде малко отрязва изречението от условието, което го уточнява, и така чатботът обещава безплатна доставка, която всъщност важи само над 100 евро.

Стратегиите за разделяне, които си струва да познавате:

• Фиксиран размер с припокриване: режете на всеки N токена, като повтаряте последните 10-20% от предишната част. Грубо, бързо и напълно разумно за начало.
• Структурно: режете по заглавия, точки от списък, редове в таблица или граници на статии. Работи, когато изходните документи наистина имат структура — помощните центрове обикновено имат, сканираните PDF-и обикновено нямат.
• Семантично: режете там, където темата се сменя, засечено чрез сравняване на embeddings на изреченията. По-бавно за изграждане, по-добро при дълъг свързан текст.
• Контекстуално: добавяте отпред кратко изречение, генерирано от модел, което обяснява от кой документ и раздел идва частта, за да има смисъл и извадена от контекста.

Този етап определя тавана на всичко след него. Част, която никога не е създадена, не може да бъде намерена, а отговор, който го няма в източника, не може да бъде генериран. По-голямата част от работата по качеството в един RAG проект се случва тук, много преди някой да напише промпт.

Стъпка две: всяка част се превръща във вектор

После всяка част минава през embedding модел, който превръща текста в дълъг списък от числа. Документацията на OpenAI за embeddings дава конкретни стойности: text-embedding-3-small връща 1536 измерения по подразбиране, а text-embedding-3-large връща 3072. Всяко от тези числа е координата, а самата част е точка някъде в много високомерно пространство.

Полезното е, че позицията носи смисъл. Две части за отказ от поръчка се озовават близо една до друга дори когато едната казва „анулиране“, а другата „отказ от покупката“. Търсенето по ключови думи не прави тази връзка. Векторното търсене я прави по подразбиране и точно затова RAG чатботът се справя с начина, по който клиентите наистина се изразяват, а не с начина, по който е написана документацията ви.

Българският се обработва достатъчно добре от съвременните многоезични embedding модели, че по клиентските ни проекти го третираме като решен въпрос. Въпрос, зададен на български, намира правилната част в документ на английски и обратното, защото embedding-ът улавя смисъла, а не буквалната форма на думите.

Стъпка три: търсенето, което се случва преди отговора

Векторите живеят във векторна база данни, чиято единствена задача е да отговаря бързо на един въпрос: като ми дадете тази точка, кои запазени точки стоят най-близо до нея? Когато клиент попита нещо, въпросът му минава през същия embedding модел и базата връща най-близките части по косинусова близост.

Обичайните хранилища са pgvector, ако вече поддържате Postgres и не искате нова инфраструктура, както и Qdrant, Pinecone или Weaviate, ако предпочитате специализирана услуга. При обемите на типична българска фирма, от няколко хиляди до няколкостотин хиляди части, pgvector обикновено стига и държи базата ви от знания вътре в базата данни, която и без това архивирате.

Колко части трябва да се върнат? Повече, отколкото подсказва интуицията. Оценката на Anthropic сравнява подаването на топ 5, топ 10 и топ 20 части към модела и открива, че топ 20 работи най-добре от трите. Търсенето е евтино, а генерирането е снизходително, така че си струва да подадете в повече контекст, вместо да залагате, че единственото най-близко съвпадение наистина е най-доброто.

Повечето реални системи пускат и хибридно търсене: векторна близост за смисъла плюс класическо търсене по ключови думи (BM25) за случаите, в които точният низ има значение. Продуктови кодове, номера на фактури, имена на модели и български адреси са неща, които индексът по ключови думи хваща надеждно, а embedding-ът понякога заглажда.

Стъпка четири: моделът написва отговора от намереното

Едва сега се включва езиковият модел. Намерените части се сглобяват в промпт заедно с въпроса на клиента и системна инструкция, която задава правилата: отговаряй само от подадения контекст, посочвай от кой документ идва всяко твърдение и казвай, че не знаеш, когато контекстът не покрива въпроса.

Последното правило вълнува клиентите най-много и е въпрос на настройка, а не свойство на модела. Бот, който си признава, че не знае, и предлага прехвърляне към човек, си върши работата. Бот, който си измисля правдоподобен гаранционен срок, е риск с чат балонче.

На посочването на източници си струва да настоявате дори когато интерфейсът ги скрива. По време на разработката те са начинът да различите провал в търсенето от провал в генерирането, а след пускането са начинът ръководителят на поддръжката да провери оплакване за грешен отговор за деветдесет секунди.

Къде всъщност се чупи всичко

Когато RAG чатбот даде лош отговор, рефлексът е да обвиним модела. Провалът обикновено е един етап по-рано. Ако правилната част така и не е стигнала до промпта, никакво пипане по промпта няма да я извика обратно.

Публикуваните числа на Anthropic показват колко запас има точно в този етап. При базовата им конфигурация правилната част липсва в топ 20 в 5,7% от случаите. Добавянето на контекст към всяка част преди векторизирането сваля това до 3,7%. Комбинирането на контекстуални embeddings с контекстуален BM25 го свежда до 2,9%, тоест 49% намаление. Допълнителен етап на преподреждане го смъква до 1,9%, или 67% намаление спрямо същата база. Същият модел, същите документи, същите въпроси, три пъти по-малко пропуски.

Провалите, които виждаме най-често при реални бази от знания:

• Изходните документи си противоречат, защото ценоразписът от 2023 г. никога не е изтрит. Търсенето добросъвестно връща и двата.
• Отговорът съществува само в таблица или изображение в PDF, а етапът на извличане го е превърнал в неизползваем текст.
• Част е загубила заглавието си и „тази отстъпка важи за поръчки над 100 евро“ вече не казва коя отстъпка.
• Въпросът е сравнителен („кой план излиза по-евтино за двама потребители?“) и отговорът изисква разсъждение през няколко части, а не намиране на една.
• Никой не е направил набор за оценка, така че качеството се мери по впечатлението на последния, който е пробвал.

Последното тежи повече, отколкото звучи. Петдесет реални клиентски въпроса с известни верни отговори, пускани след всяка промяна, са разликата между система, която можете да подобрявате, и система, за която можете само да се надявате.

RAG, дообучаване или просто по-голям контекстен прозорец?

За един и същ проблем се предлагат три решения, а те решават различни неща. Дообучаването нагласява теглата на модела върху ваши примери. Добро е за усвояване на тон, формат на отговора и специфична терминология, и слабо за вграждане на факти, защото дообученият факт е също толкова непроверим и труден за обновяване, колкото всяко друго тегло. Когато цените ви се променят, ще преобучавате.

Другото изкушение е да поставите всичко в дълъг контекстен прозорец. Работи за наръчник от 30 страници и спира да работи при 3000. Плащате за всеки токен при всеки въпрос, забавянето расте с обема на входа, а разпознаването се влошава, докато нужното изречение потъва сред десетки хиляди ненужни.

RAG стои по средата: фактите остават в хранилище, което контролирате, до модела стига само относимата част при конкретния въпрос, а обновяването на базата от знания е операция с файл, а не обучение. На практика трите се комбинират добре. RAG носи фактите, кратък промпт или леко дообучаване носи гласа.

Как изглежда това в реален проект

За Houzez, българската платформа за имоти, разработихме Боро — двуезичен асистент, който приема заявка на човешки език от рода на „двустаен в Лозенец до 250 000 евро“ и връща подходящи обяви, а покрай това отговаря и на процесните въпроси, които преди идваха през формата за контакт в единайсет вечерта. Слоят за търсене стои върху данните с обявите и върху разясненията в самия сайт, а моделът се грижи за формулировката — на български или на английски, според това с кой език е започнал посетителят.

Формата на тази работа е типична. Около две трети от усилието отива в поглъщането на данни, разделянето, качеството на търсенето и оценката. Чат интерфейсът, тоест частта, която всички си представят при думата чатбот, е малкият край на задачата. Нашите RAG чатбот проекти започват с двуседмичен прототип върху реалните ви документи, за да видите измерено качество на отговорите, преди да се обвържете с производствена система, а страницата с цени описва как се остойностява това.

Ако проблемът ви е по-малко в отговарянето на въпроси и повече в местенето на данни между системи без човек да ги преписва, това е друг инструмент. Погледнете AI автоматизация и пропуснете слоя за търсене изцяло.

Присъдата

RAG чатботът работи, като първо търси и чак после говори. Разделяне, векторизиране, търсене, генериране. Нищо в тази верига не е екзотично и всеки етап подлежи на проверка, което е точно причината мястото ѝ да е в бизнес среда, където грешният отговор струва пари.

Честната ни позиция след няколко такива проекта: моделът е най-безинтересното решение, което ще вземете. Който и от челните модели да изберете, ще напише свестен абзац при добър контекст. Разликата между чатбот, на който хората вярват, и чатбот, който спират да ползват, се крие в неефектната работа по документите, разделянето и търсенето, плюс набор за оценка, който ви казва дали промяната от миналата седмица е помогнала. Ако някой доставчик иска да говори основно за това кой модел използва, показва ви лесната част.

Често задавани въпроси

Как работи RAG чатбот в едно изречение?

Превръща документите ви в търсими вектори, намира пасажите, най-близки по смисъл до зададения въпрос, и кара езиков модел да отговори само въз основа на тях.

RAG чатботът все още ли си измисля?

По-малко, но не никога. Обвързването на отговора с намерен текст премахва повечето измислени факти. Останалото обикновено е проблем в търсенето: правилният пасаж не е намерен и моделът е запълнил тишината. Посочването на източници и инструкцията да откаже при беден контекст свалят остатъка още.

Колко данни са нужни, за да има смисъл от RAG?

Достатъчно, че човек да не ги побира в главата си, и достатъчно последователни, за да си струва да се търси в тях. Двайсет въпроса и отговора не се нуждаят от търсене — добре написана страница с ЧЗВ ще се справи по-добре от чатбот. Няколкостотин страници правила, продуктови детайли и процедури е мястото, където RAG започва да си заслужава.

Работи ли на български?

Да, и в двете посоки. Съвременните многоезични embedding модели се справят с българския, а големите доставчици генерират плавен български текст. Посетител може да пита на български и да получи верен отговор от документ на английски. Истинското ограничение е качеството на документите, не езикът.

Колко време отнема изграждането на RAG чатбот?

Две седмици за прототип върху реалните ви документи, после обикновено още четири до осем за производствена система, според това от колко системи трябва да чете и колко чист е изходният материал. Разхвърляните PDF-и удължават първото число повече от всичко останало.

Колко струва поддръжката на месец?

Две пера: използване на модела, което се таксува на токен и зависи от обема разговори, и хостинг на векторното хранилище, който е близо до нулата, ако ползвате pgvector в съществуваща база данни. При умерен обем запитвания повечето наши клиенти са в рамките на ниски стотици евро месечно.

Може ли да чете от CRM или ERP вместо от документи?

Може и често трябва. Живите записи се извличат през API в момента на въпроса, а не се векторизират, защото наличностите и статусите на поръчките се променят по-бързо, отколкото се обновява какъвто и да е индекс. Реалният асистент обикновено смесва двете: търсене за стабилното знание, директни справки за всичко текущо.