RAG проты агентнага RAG проты Graph RAG: як выбраць правіярхітектуру пошуку.
Дазвольце даклэ наўінаму RAG не выконвае сваёй задачы пад час адпаведзення на запытанні з кальцамі та структураванымі дадзеннямі, і як агентныя циклы та пошук на основе графа кожны з іх усунуў разныя слабасці.
Проблема, якую прагне рашыць RAG
Кожная большая модель мовы выкармчваець знанні, якія перестаюць накаплівацца пасля завершэння трэйнінгу, і яна можа рассуждаць толькі над тым, што пасвячаецца ў ерэю контексту. Метод Retrieval-Augmented Generation рашытае гэту проблему паляганнем на зовнішняй памяці, яюю модель можа выкарыстоўваць пад час адпаведзення на запытанне. Уместо таго, каб завісіць выключна ад таго, што яна выучыла пад час трэйнінгу, модель запоўняецца релевантным тэкстам з калекцыі дакументаў і выкарыстоўвае гэты матэрыял для формування свайго адпаведзення.
Основныя крокі, верагодна, вам вядомы ўжо:
- Дакументы-выхаднікі дзеляцца на меньшыя часткі і ператвараюцца ў векторные эмбедынгі.
- Гэтыя эмбедынгі зберагаюцца ў векторной базе дадзенаў — популярныя выбары — Pinecone, Weaviate, pgvector і падобныя інструменты.
- Калі корыстувач адправляе запытанне, яно таксама ператвараецца ў эмбедынг за дапамогою таго ж методу.
Весь гэты процес выконваецца адначасова, з самага пачатку да канца: адна процедура пошуку, адна генерацыя. Гэта недорага, яго працаванне лёгкае для разумевання, і ў шырокім спектре сцэнарыяў — пошук у внутраніх дакументах, адпаведзеныя на запыты падтрымкі на адной базе знанняў, або обработка запытаў і адпаведзэнняў на статычныя дакументы — ён парадна працюе.
Дзе просты падход RAG не функціонуе
Калі гэты просты пракцэс збываецца, неудачы зазвычай падпадаюць пад калькі вядомых катэгорыяў:
- Запытанні, які вымагаюць з’едначэння калькольных фактов. Напрыклад, запытанне "якія прадаўцы падновілі контракты пасля адкорэктавання політыки у трэцьму квартале?" вымагае двух адзінаковых фрагментоў інфармацыі, якія па большай частцы знаходзяцца ў разных частках тэксту. Метод адпоўненасці векторав выявляе фрагменты, якія сэмантычна падобные да запытання, а не конкрэтную комбінацію фактов, якая на самай працэ патрэбна для ўтварэння адпаведзення.
- Няма вбудованага умовы завершэння. Сістэма завжды вяртае сваія топ-к фрагменты, незалежна ад таго, чыі ў яных дзейсна знаходзится адпаведзенне. Калі рэальнае адпаведзенне не ўходзіць у групу топ-к, модель альбо стварае штось прыемнае, альбо дае неясны, некорисны адказ.
- Няма цыклу зворотнага зв’язку. Якщо пачатковы пошук не дае рэзультатаў, ніч гэтым пракцэсам не дапамагае выявіць гэта і спробаваць запытанне, сформульаванае краща. Сістэма проста продовжвае работу з тым, што ў яе є.
Нічыя з гэтых проблем не ёсць справжнімі багамі; гэта природныя наследкі основнай прыпуску, закладанай у архітектуру — што пошук за сэмантычнаю схожасцю між нез’ўязанымі фрагментамі тексту є достатнім заменітелем для практычнаўажлівай релевантнасці. Agentic RAG та Graph RAG нарадзіліся для усунення разных слабых месцаў у гэй прыпуску.
Agentic RAG: Стварэнне цыклу прыняцьбы рашэнняў у процесе адзысквання інфармаціі
Agentic RAG заменяе жорсткую сэрію дзеянь «адзыскваць — стварыць» на цыкл, у якім LLM выступае як кансультант — выбіраючы, што саме адзыскваць, чы рэкламуецца ўтратаўшы іншую інфармацыю, і калі вже з’яўілася достатня колькасць даных для стварэння адпаведзення.
У зменшэнні на адзин крок запошук, процес выглядае так:
- Модель чытае запит і выявляе, якую самэўсёлку інфармацыю ёй насправды трэба.
- Ён выявляе, чы рэальна патрэба ў запошуку адначасова, і якщо так, стварае запит на пошук — можліва, разбиваючы складны запит на меншыя падзапыты.
- Ён запошукае рэзультаты, ацэнюе, чы яны адпаведны, і якщо ні, перапісвае запит і зноў запошукае.
- Па патрэбе ён можа выкарыстоўваць кілька разных источнікаў — хранілішча вектароў, базы дадзенаў SQL, API для пошуку ў інтэрнете, внутраніяя службы — залежна ад таго, чаго трэба для адпаведзення на запыт.
- Толькі пасля таго, як ён выявіць, што у яго є достатня колькасць доказаў, ён дае гэтычны адпаведзення.
Парадоксальна рэч у тым, што гэта паказвае RAG унутрь ціклу агента, выкарыстоўваючы той самы патэрн вызывання інструментаў, які викорыстоўваюць асистэнты для напісання коду: планаванне, дзеянне, аналіз рэзультата, а потым выбір, чы хацецца продаваць далей. Вызыванне інформацыі больш не ёсць обавязковым першым крокам, а стае толькі адним з каналоў, якія выкарыстоўваюцца на выбар, а не автаматычна з кожнага запиту.
Рэзультатам яе є гнучкасць. Просты запит спрыяе адзінаму вызыванню інструмента; запит, які трэбуе троха последовных вызыванняў у розныя системы, атрымвае самэ гэта. Такая структура таксама падтрымляе самакорэкцыю — якщо атрыманы фрагменты інформацыі явна некоректныя, агент можа гэта распазнакаць і выдаты іншы запит у замест на тое, каб адпаведаць на падставе ненадзейных даных.
Такая гнучкасць караецца рэальнымі затратамі. Кожны крок планавання і кожны крок адзынакоўвання ёсць сама по сабе окремым вызовам модэлі, таму за кожны запит вы патрапляеце да большага колічына вызоў LLM, вышэйшай затрымкі і такога профілю затрат, які значна сложней прадваротна прырачыць. Агентны RAG добра работае, калі складнасць запыта сильна разніцяецца ад запыту да запыту, адтуды ўстановленая паэтапная схема або марнаваць зусілля на простыя запыты, або не справляецца з складнымі. Гэта слабейшы варыянт, калі вам патрэбна стабільна низкая затрымка, або калі вашы запыты настолькі конкрэтныя, што рэтельна налаштаваны апранкер для адзінаго запыту вже добра іх обрабоўвае.
Graph RAG: Вярнэнне структуры, якую разбіванне на часткі нішчыць
Graph RAG нацэлёваны на абсалютна іншую проблему: звычны пошук у вектарах сярод частак не мае вбудованага розуміння таго, як аб’екты адносяцца адзін да другога.
У працы Graph RAG замест таго, каб паследовваць выключна вектарнаму індэксу (хоць ён таксама можа выкарыстоўваться разам з ім), стварае граф знанняя прычыму з самага выхіднага матэрыялу. Гэта паводзіцца да выкарыстоўвання аб’ектаў — людзей, продуктав, організацыяў, паняв — а таксама зв’язкаў, якіе іх спаяваюць, такіх як працуе-у, залежыць-ад, вызвана-бы, альбо ёсць-версія-дзе. Тады процес адналёгання перестае быць чыстаю пошукам сэмабільнасці і становіцца часткова задачай праходжэння па графе: выйшоўшы з релевантнага аб’екта, система може перейсці да супакояных аб’ектаў і запрашыць інфармацыю, якая ніколі не з’явілася бы за дапамогою толькі падбору ключоўых слоў або эмбеддынга, проста таму, што яна знаходзіцца за калькома зв’язкаў у абсалютна іншым дакументе.
Даследжэння Microsoft GraphRAG ёсць найбольш апрацоўваным варыянтом гэтага падходу, і ён адкрывае дапаможны функцыянал, які ўзначальна ценны для аднаго типу запыткаў — выявлення камюнітэтаў. Система групавае граф у кластэры з тычуццаеся адносамі ентытаў і заздалегідь вырахоўвае статыстыку для кожнага кластэра. Гэта дае Graph RAG рэальную перадчыну ў разв’язванні шырокіх запыткаў, якія абходзяць весь корпус дакументаў — напрыклад, «Каліяя ўзвортныя тэмы ў всім гэтым наборе адчынакоў?» — што якраз ёсць тая категорыя запыткаў, з якойімі страждае простае RAG, адтолькі што жаданы частака не мае цэлага адказу; адказ з’яўляецца толькі праз сынтэзу всіх дадзеных.
Ціны тут є структурнымі, а не випадковымі. Створэнне графа ўскладнена, адколі для цього патрэбна обработка всего корпусу дакументаў з метой выявлення аб’ектаў і ўзаінтэресаванасцяў, якая зазвычай адбываецца за дапамогою LLM, плюс додатковы крок стварэння апূরкі інформацыі пра групы дакументаў. Гэты падход таксама не падходзіць для корпусаў, якія часта змінююцца, адтуды граф патрэбна перзбудаваць або поступова апдэйтаваць кожны раз, калі змінююцца дакументы — гэта значна сложнейшая операцыя, чым проста дадаць новы вектар у індэкс эмбедінгаў.
Порэванне трох апрантакоў
Варта згадаць, што гэтыя падходы не ўзаемна выключаюць адзін другога. Частыя патэрны ў практыцы — это агентскі цикл, які распаўнены як вектарным, так і графічным механізмамі пошуку як доступнымі інструментамі, чыяму агент можа выбраць адны з іх або вжыць оба, залежна ад таго, калі якія даныя запрашваецца. Агентскі слой на самай працэ ёсць стратэгіяю оркестрацыі, якая знаходзится вышэй за будзь-кі механізм пошуку, таму ён практычна додаецца да Graph RAG, а не конкуруець з яным.
Практычная рамка прыняцтва рашэнняў
Уместна не выбіраць падход за тым, што ён наразе популярны, а працаваць за конкрэтным процесам прыняцтва рашэнняў:
- Пачніце з простаг RAG. эта самая недорогія аптака для стварэння та адрабаткі проблем, і для большай часткі практычных застосоўваń яна вже дастаткова. Іхніце дадаваць складнасць, пакуль у вас няма доказаў, што яна насправды патрэбная.
- Апградаваце да Agentic RAG, калі з’явяцца адзінаковыя патэрны неудач: запиты, якія вымагаюць абробкі інфармацыі з кальколькох джэраў, адпаведзі, якія выходзяць некоректнымі таму, што модэлю трэба было шукать, ацэніць знайдзеное і зноў шукать, або завантажэння, якое сумішвае простыя та складныя запиты так, што адзін фіксаваны прайсепт стае або занадта сложным, або недастатковым.
Галоўны вывад падтверджвае законамернасць, якая спостыраецца ў дизайне систем: болей сложная архітектура не є прыродна вышэйшая, яна вышэйшая толькі для певнага типу проблем. Просты RAG не справляецца з запыткамі, якія выкалікаюць неабходнасць багацых крокаў ухвалення рашэння чыстаў асоціяцый. Agentic RAG усуне гэтыя проблемы за дапамогою ітерацый. Graph RAG усуне проблемы, якія стосуюцца асоціяцый, за дапамогою структуры. Правильная діагназа таго, з якай проблемай вы насправдзе сталкнуліся, — гэта сама галоўная задача.
Спадневаная літэратура
- Чаму вартасць агентных AI-сістэм растае: модель калькуляцыі вартасці на адміністрацыю — Апяшвае, чаму вартасць агентных LLM-сістэм трэба вылічваць за кожны завершаны задачы, а не за кожны вызов, і паказвае архітектурныя способы, такія як маршрутызацыя модэляў, бюджеты контексту і кэшаванне, для контролю витакоў.
- Second Brain: Ператварэнне стенографіяў з сабеседаў у граф знанняў, які можна запытваць — Апяшвае, як агентная сістэма выкарыстоўвае стенографіяў з сабеседаў для выкарыстоўвання ентытаў і хранення іх у Cosmos DB, што дазволяе адкрываць знання на аснове нейтаральнай мовы і дакладна ісследаваць граф знанняў.