Розкриваючи Магію LightRag: Як Перетворити Ваших AI-Агентів на Експертів
Привіт, друзі! Ліла Гарт з вами, і сьогодні ми поринемо у захопливий світ AI-агентів та регенерації з розширеним контекстом (RAG). Мене часто запитують: “Як зробити мої RAG-агенти більш точними?” І це саме те питання, яке ми детально розглянемо. Адже RAG досі залишається надзвичайно актуальним способом інтегрувати зовнішні знання у наших агентів, перетворюючи їх на справжніх експертів у наших документах та даних.
Не зважаючи на те, що великі мовні моделі (LLMs) вже можуть обробляти мільйони токенів в одному запиті, RAG продовжує відігравати ключову роль. Зазвичай, RAG працює досить добре: ми ставимо запитання агенту, він шукає в наших документах, використовуючи RAG, і цей додатковий контекст зазвичай допомагає дати нам кращу відповідь. Але чи варто зупинятися на “достатньо добре”?
Деякі бенчмарки показують, що базовий RAG має 75% точність у витягуванні релевантної інформації, а інші вказують на цифри між 35% та 45%. Якщо ви хочете створити справжнє AI-рішення, цієї точності буде недостатньо. Сьогодні я покажу вам потужне рішення цієї проблеми. Адже, очевидно, що не можна просто зайти в такий інструмент, як N8N чи Langchain, створити простого RAG-агента і вважати, що на цьому все. Існує набагато більше, ніж здається на перший погляд, у створенні RAG-рішень, які дійсно працюють.
Я провів останні тижні, пірнаючи у глибини різних RAG-стратегій. І найбільше вражало мене вдосконалення RAG за допомогою графів знань. Зокрема, мене вразив потужний open-source фреймворк під назвою LightRag. LightRag не тільки векторизує ваші документи, як традиційний RAG, але й будує важливий граф, який з’єднує теми, ідеї та концепції з ваших документів. Це дозволяє підняти контекстне розуміння вашого AI-агента на новий рівень. Найкраще те, що з ним досить легко почати працювати.
Отже, дозвольте мені зараз трансформувати вашу RAG-стратегію за допомогою простої, але потужної імплементації LightRag. Ми навіть порівняємо її з базовою RAG-установкою, щоб побачити, як вона працює. Отже, у нас є код, у нас є докази – давайте зануримося!
LightRag: Ваш Ключ до Більш Точних RAG-агентів
Насправді, LightRag – це справжня знахідка. Якщо ви дійсно хочете заглибитися у технічні деталі цього фреймворку, ви можете ознайомитись із дослідженнями, які додаються до репозиторію GitHub. Звісно, я не хочу зосереджуватися на всіх технічних аспектах сьогодні, оскільки це дуже глибоко. Але я зосереджусь на тому, щоб допомогти вам почати працювати з LightRag, тому що, на мою думку, це найбільш практично.
Працювати з LightRag неймовірно просто. Ви просто встановлюєте його як пакет Python і потім, скориставшись інструкціями по швидкому старту, зможете зрозуміти, як працювати з LightRag. LightRag можна уявити як три окремі частини:
- Налаштування інстансу RAG-конвеєра: Тут ми визначаємо такі параметри, як модель вбудовування та велика мовна модель, які хочемо використовувати. Це дуже гнучка система, де ви можете налаштовувати всі ці речі.
- Вставлення даних у ваші граф знань та векторну базу даних: Ми робимо обидва ці кроки одночасно, використовуючи
rag.insert()і просто передаючи будь-який рядок з будь-яких документів, які потрібно розібрати. LightRag автоматично розбиває дані на частини та вставляє їх оптимальним способом. Таким чином, він піклується про багато чого сам. - Запуск фактичного запиту: Це просто
rag.query()з нашим запитанням та режимом пошуку. Існує багато різних способів, як ми можемо шукати у нашій базі знань з LightRag. Ми можемо виконати наївний пошук, який є просто базовим RAG, ми можемо зробити щось на зразок гібридного пошуку, і ми навіть можемо зробити змішаний пошук, що круто, оскільки це використовуватиме векторне вилучення, базовий RAG і здійснюватиме пошук за графом знань.
Отже, ми не втрачаємо жодних переваг від базового RAG, тому що ми маємо його та ще більше з LightRag. Саме це робить його таким потужним. Також є багато можливостей для налаштування. Як я вже згадував, ви можете змінити LLM та модель вбудовування, які ви хочете використовувати.
Ви можете використовувати будь-який API, подібний до OpenAI. Якщо ви хочете використовувати щось на зразок Gemini або Open Router, ви можете використовувати Olama. У них є пряма підтримка Olama для локальних LLM. У них також є багато прикладів у прикладах використання цих різних опцій. Сюди входять такі речі, як AWS Bedrock або Azure OpenAI. Отже, у них є приклади майже на все, щоб допомогти вам швидко почати роботу.
Щодо налаштування бази даних, яку ви використовуєте для зберігання всієї вашої бази знань, у них є кілька варіантів. Ви можете використовувати Neo4j для графа знань, а також Postgress. Вони додали це нещодавно. Ви можете використовувати Postgress як для векторної бази даних, так і для графа БД з Apache Age.
Одна річ, яка не входить у рамки цього відео, але яку я обов’язково хочу розглянути пізніше – це використання Neo4j тільки для графа знань, а потім Postgress тільки для векторної бази даних, поєднуючи їх разом, щоб дійсно використовувати їх сильні сторони. Я працюю над цим дуже активно.
Але давайте почнемо з огляду, як швидко розпочати роботу з базовою та потужною реалізацією LightRag. Внизу репозиторію вони також показують, як LightRag порівнюється з тим, що вони називають наївним RAG. Це просто базовий або традиційний RAG. Просто подивіться на відмінності у цих відсотках, як LightRag працює на всіх цих наборах даних. Вони дають вам інструкції, як ви можете самостійно запустити всі ці тести, якщо ви хочете відтворити ці результати. Вони доклали багато зусиль, щоб дійсно надати вам підтвердження ефективності LightRag.
Вони також порівнюють його з купою різних наборів даних. Вони навіть порівнюють його з GraphRag. Це була більш складна реалізація чогось подібного від Microsoft. LightRag простіший, швидший і демонструє ще більшу потужність. Отже, на мою думку, це дійсно найкращий фреймворк графів знань, ось чому я показую його вам сьогодні.
Швидкий Старт: LightRag у Дії
Перше, що я хочу зробити – це пришвидшений огляд, щоб показати вам, як швидко почати працювати з LightRag, використовуючи три компоненти, які ми бачили в репозиторії GitHub. Потім я занурюсь у побудову агентів, і ми навіть порівняємо його з традиційним RAG, щоб побачити, наскільки добре він працює.
Отже, перш за все, нам потрібно створити ініціалізацію нашого RAG-інстансу, дотримуючись того, що ми бачили в репозиторії GitHub. Ми визначаємо робочий каталог, де ми створимо граф знань локально, а потім вибираємо модель вбудовування та велику мовну модель, які ми хочемо використовувати. Ми просто використовуємо OpenAI для обох.
Далі ми ініціалізуємо наше сховище та конвеєр, щоб ми могли вставити дані у нашу базу знань. Це ми і робимо наступним кроком. Ми просто використовуємо асинхронну функцію insert, щоб вставити всю інформацію, яку ми хочемо, у нашу базу знань. Це може бути файли, якщо хочете. Ви можете підтягувати файли локально або з хмари, перетворювати їх на рядки та вставляти їх точно так само. LightRag подбає про розбиття на частини та оптимізацію вставлення для нас.
Після того, як у нас є все у нашій базі знань, ми можемо запустити запит. Я можу сказати rag. а потім використовувати асинхронну функцію query. Я даю йому своє запитання, а потім прошу його використовувати змішаний режим пошуку. Отже, він використовуватиме як векторну базу даних, так і граф знань, щоб знайти відповідь для мене. Потім, нарешті, я просто виведу результат на екран.
Отже, тепер я можу перейти до свого терміналу та виконати цей скрипт Python. Отже, він створить RAG-конвеєр, вставить все в нього, а потім виконає запит на основі запитання, яке я визначила внизу скрипту. Це так просто налаштувати все для LightRag. І, очевидно, є більше, що стоїть за інтеграцією з агентом, але саме це я збираюся показати вам у цьому відео.
І ось наша відповідь. У ній говориться, що Python – це вибір для нас, і так, це безумовно правильно, враховуючи те, що я вставила в базу знань. Отже, це виглядає дуже добре. Щоб розширити це далі, у мене є щось особливе, щоб показати вам.
Практичний приклад: LightRag проти Традиційного RAG
Щоб показати вам, як використовувати LightRag і наскільки він потужний, я створила для вас цей ресурс, який можна завантажити. Ви можете перейти за посиланням GitHub в описі, взяти це прямо зараз і використовувати для себе, щоб почати роботу з LightRag дуже швидко.
Я покажу вам у цьому відео, як я все налаштувала. Але структура цього проекту така: у нас є два RAG-агенти. У нас є одна традиційна реалізація RAG, яка використовує Chroma DB для швидкої та локальної векторної бази даних. І у мене є другий AI-агент, побудований з LightRag. Обидва ці агенти платні. Я використовую одну й ту саму базу знань для кожного.
Отже, ви можете протестувати їх бік до боку. Зокрема, база знань, яку я створила для кожного з них, така: я взяла всю документацію Pydantic AI. Це мій улюблений фреймворк Python-агентів зараз. Я просто використовую його документацію як приклад для цього відео. Якщо ви перейдете за посиланням /lms.ext з їх базовим URL ai.pydantic.dev, ви отримаєте цей масивний текстовий файл. Це вся документація Pydantic AI, зібрана в один текстовий файл, спеціально для RAG AI-агентів.
Отже, я взяла це і вставила це як у Chroma DB для нашого традиційного RAG-агента, так і у граф знань, просто налаштований локально для LightRag. Обидва ці агенти працюють як користувацькі інтерфейси Streamlit. Отже, виглядає це абсолютно однаково. Але кожен з них спілкується з одним з AI-агентів, конкретно.
Отже, я можу поставити те саме запитання обом, і ми можемо побачити, які результати ми отримаємо, тому що під капотом все виглядає зовсім по-іншому, як агент насправді отримує доступ до бази знань.
Одне з основних обмежень LightRag і, власне, RAG як таких, полягає в тому, що з даними реального часу досить важко працювати, тому що щоразу, коли ви хочете оновити свою базу знань, вам потрібно повторно вставляти документи у свою векторну базу даних та перераховувати свій граф знань. Це не швидкий процес.
Отже, як же ви повинні створювати AI-агентів, які інтегруються зі складними даними, що постійно змінюються, наприклад, взаємодією з користувачами та часовими метриками? Рішенням є потужна open-source платформа для створення графів знань реального часу під назвою Graffiti. Graffiti спонсорує цей сегмент, але я спеціально чекала, щоб помістити їх у це відео, тому що вони є ідеальним рішенням для вас, коли вам потрібно щось на зразок LightRag, але для даних, що постійно змінюються. І це живлює ядро шару пам’яті Zep, тобто це справді реально.
Ось репозиторій GitHub для Graffiti. Оскільки він з відкритим кодом, ви можете почати з ним прямо зараз, абсолютно безкоштовно, щоб створити потужні RAG-агенти на Python. Те, що дійсно виділяє Graffiti, – це спосіб, яким він може підтримувати постійно змінювані відносини в графі знань. Він може підтримувати історичний контекст. Отже, ваш AI-агент може знати, як ці відносини змінилися з часом. Це дуже унікально.
Я залишу посилання на Graffiti в описі, якщо ви хочете створити AI-агентів, які працюють з інформацією, що постійно змінюється, тоді Graffiti – це рішення для вас, і я настійно рекомендую їх перевірити.
Щоб почати з простого тесту, я просто хочу, щоб обидва агенти використовували документацію Pydantic AI для створення повної реалізації AI-агента для агента, який може шукати в Інтернеті з Brave. Це просто гарний і простий тест, який мені подобається запускати багато разів, коли я намагаюся змусити помічника з кодування AI створити AI-агента для мене, як я це роблю з Archon, моїм конструктором AI-агентів.
Отже, я візьму цей запит, надішлю його агенту LightRag, а потім перейду до користувацького інтерфейсу Streamlit і надішлю той самий запит агенту Chroma DB. Оскільки Chrom тільки має шукати у векторній базі даних, а не в графі знань, він дасть нам швидшу відповідь. Так, я просто побачила, що тут блимає.
Подивіться на це. З якоїсь причини він вирішив використати інструмент пошуку DuckDuckGo, наданий Pydantic AI, замість того, щоб щось робити з Brave. І це класична галюцинація, коли з документації витягується неправильний контекст, що змушує його думати, що він має використовувати щось зовсім інше для реалізації агента. Отже, він використовує зовсім інший інструмент пошуку замість Brave. Напевно, через те, що було повернуто з RAG, і я не знаю цього точно, але я бачила такі галюцинації багато з традиційним RAG.
Отже, давайте перейдемо до того що ж було створено для LightRag. Дозвольте мені прокрутити нагору, щоб переглянути верхню частину результатів. Так, це виглядає набагато краще. Я маю на увазі, вам не потрібно розуміти код Pydantic AI, це просто приклад, який я використовую. Але я дуже добре знайома з цією структурою, і це виглядає як чистий код Pydantic AI, і він використовує Brave для інструменту веб-пошуку. Отже, це виглядає набагато краще.
Він не повністю реалізує пошук Brave, що має сенс, оскільки агент має лише документи Pydantic AI, а не документи Brave. Отже, він просто імітує цей запит, і я поважаю це. І це просто має місце для моделі тут, тож це не ідеальний код, наприклад, я не змогла б просто запустити його таким, як є. Але він безумовно має кращий контекст навколо того, що я намагаюся створити, і пов’язує це конкретно з документацією в Pydantic AI для цього. Отже, це виглядає добре. Я скажу, що LightRag перемагає.
І ви побачите, що загалом LightRag майже завжди перевершуватиме традиційний RAG, особливо з експоненційним зростанням вашої бази знань. Отже, якщо у вас тисячі або сотні тисяч документів, саме тоді звичайний RAG дійсно починає розвалюватися. Але LightRag буде рухатися, тому що у нас набагато більше контекстного розуміння наших знань, тому що у нас також є граф знань. Можливо, я зроблю більше тестувань пізніше. Але зараз я хочу показати вам, як саме я створила цього агента LightRag, щоб ви могли створити їх для себе.
Як Створити Свого LightRag Агента: Покрокова Інструкція
Добре, нарешті, повертаємося до нашого репозиторію GitHub, тому що тепер ми знаємо, як працює LightRag, чому він такий потужний, і ми протестували його проти традиційного RAG. Отже, тепер я хочу показати вам, як ви можете створити власного агента LightRag, базуючись лише на коді, який у мене тут є, як безкоштовний ресурс для вас. Отже, ви можете подивитися на це прочитання в корені репозиторію, і ви можете пройти ці інструкції, щоб налаштувати все самостійно, або ви можете просто взяти цей код і перенести його у свій власний проект. Я не проти. Я просто хочу надати якомога більше цінності.
Але я хочу дуже швидко розглянути кілька важливих файлів для налаштування нашого агента LightRag. Спочатку у нас є цей файл. Ось наш скрипт Python, який відповідає за витягування документації Pydantic AI та створення нашої бази знань LightRag. І все це буде зберігатися локально в цій папці pyantic docs. Отже, всі ці файли JSON представляють нашу векторну базу даних та граф знань. Пізніше я, можливо, додам Neo4j або Postgress для зовнішнього зберігання, але зараз я все спрощую, використовуючи графі знань.
Отже, в цьому скрипті спочатку ми імпортуємо всі наші бібліотеки та завантажуємо наші змінні середовища. Потім у головній функції є лише дві речі, які мені потрібно зробити. Спочатку я повинна ініціалізувати RAG-конвеєр, як ми бачили в прикладі швидкого запуску в репозиторії LightRag.
Потім я хочу отримати всю документацію Pydantic AI та просто вставити її в нашу базу знань. Це все, що має робити цей скрипт. Досить просто. Отже, ми просто реалізуємо ці дві функції прямо зараз, починаючи з функції для ініціалізації нашого RAG-конвеєра.
Отже, для цього я просто виконала документацію з LightRag. Це все досить стандартно, це просто, ми спочатку створюємо наш RAG-екземпляр тільки на основі нашого робочого каталогу, який ми визначимо за секунду, а потім ми вибираємо нашу модель вбудовування та велику мовну модель. Отже, я просто використовую OpenAI для обох, зокрема GPT4 mini для моєї великої мовної моделі. Це те, що я також використовую для Chroma DB-агента. Потім мені потрібно просто ініціалізувати сховища й стан конвеєра. Тепер я можу повернути цей RAG-екземляр, щоб ми могли тоді використовувати його для вставки всіх записів.
Отже, на цьому все для ініціалізації. Тепер ми можемо створити функцію для отримання документації Pydantic AI. Спочатку я додала цю частину, щоб визначити робочий каталог, тому що це важливо, тому що це говорить скрипту, що вам потрібно створити граф знань у цій папці. Ось, як ми бачимо, тому що я вже запустила цей скрипт. Отже, ми це визначили.
Ми створили цю папку, якщо її не існує. Потім я вибираю URL-адресу для документації Pydantic AI. У цьому краса наявності LLMs.ext. Весь цей скрипт повинен отримати лише з однієї URL-адреси, щоб отримати всю документацію для Pydantic AI для RAG. Це дуже дуже акуратно.
Отже, у моїй функції для отримання документації Pydantic AI все, що мені потрібно зробити – це використати HTTP-клієнт, щоб отримати цю окрему URL-адресу, а потім повернути текст для неї, а також просто обробити будь-які інші помилки. І на цьому все. Отже, тепер цей виклик дає мені всю документацію Pydantic AI у вигляді одного рядка, який я потім можу вставити у свою базу знань, оскільки LightRag подбає про розбиття на частини, вставлення та все інше.
Отже, у 53 рядках коду ми тепер маємо цей скрипт, який ми можемо запустити, коли захочемо оновити нашу базу знань за допомогою останніх документів Pydantic AI. І тоді майте на увазі, як тільки ви запустите цей скрипт, щоб створити свою базу знань, це займе деякий час, тому що йому потрібно створити векторну базу даних і граф знань і обчислити все це.
Отже, щоб створити всі ці файли, вам, можливо, доведеться почекати щонайменше 20 хвилин, тому що він імпортує всю документацію Pydantic AI. Але ви просто запускаєте це один раз, і тоді вам ніколи не доведеться запускати його знову, якщо ви не захочете оновити свою базу знань.
І отже, ви маєте справу з цим довгим запуском перший раз, і тоді, коли ми запускаємо нашого агента в майбутньому, буде дуже швидко розгортати цей екземпляр нашої бази знань RAG. Саме так, отже, тепер ми переходимо до нашого агента. Я збираюся імпортувати всі бібліотеки, які нам потрібні, а потім визначити той самий робочий каталог, тож ми посилаємося на базу знань, яку ми створили за допомогою іншого скрипту.
Потім я хочу викинути помилку, якщо у нас не встановлено API-ключ OpenAI. Очевидно, нам це потрібно для нашого агента, а потім я збираюся ініціалізувати наш RAG так само, як я це робила в іншому скрипті. Отже, визначення робочого каталогу, нашої моделі вбудовування та нашої великої мовної моделі. Тоді я ініціалізую сховища, і мені не потрібно ініціалізувати стан конвеєра цього разу, тому що ми робимо це тільки тут, оскільки ми вставляємо у векторну базу даних. Тож тепер я можу просто повернути rag, і тоді, бум, у нас є екземпляр RAG, який ми можемо потім інжектувати у нашого агента, щоб він міг виконувати RAG.
Тож ми визначимо залежності для нашого агента. Це екземпляр LightRag, який ми збираємося інжектувати у нашого агента, використовуючи класичні Pydantic AI залежності. Потім ми визначимо самого агента, який повинен виглядати дуже знайомим з агентом, який ми щойно створили в Streamlit. Ми використовуємо GPT4 міні, як ми використовуємо з LightRag.
Ми налаштовуємо наші залежності, а також ми даємо йому чудовий системний запит. Також для нашого єдиного інструменту, який ми надаємо нашому агенту, щоб все було просто, ми даємо йому можливість, виходячи з пошукового запиту, який агент визначає сам, він викличе цей tool для пошуку по базі знань. Отже, ми даємо йому чудову документацію. Це надається як частина запиту до LLM, щоб повідомити йому, коли і як використовувати цю функцію пошуку.
І це дуже просто. У нас є три рядки коду, які ми беремо з нашого екземпляра LightRag, що ми поміщаємо у нашого агента, ми викликаємо асинхронну функцію query, даючи їй пошуковий запит, а також ми використовуємо змішаний режим пошуку, отже, він буде шукати, використовуючи як векторне вилучення, так і він шукатиме граф знань. Тож у нас є найкраще з обох світів.
Потім у мене також є ця головна функція, якщо ви хочете запустити агента як окремий скрипт. Я не збираюся цього розглядати, тому що більш важливою частиною є цей додаток Streamlit, який я створила, тож ми можемо взаємодіяти з ним за допомогою інтерфейсу в браузері.
Streamlit не є центром цього відео, тому я не збираюся детально це висвітлювати. Але ви можете подивитися на це, якщо хочете побачити, як ми налаштовуємо LightRag як залежність. Ми інжектуємо це у нашого агента, коли ми його виконуємо тут. І саме тут ми викликаємо нашого агента для кожного повідомлення, яке ми надсилаємо в інтерфейс.
І ми потоково передаємо цю відповідь з генератором тут, щоб ми могли отримати результат в стилі друкарської машинки в інтерфейсі, як ми бачили раніше. Це наш повний агент LightRag. Звичайно, дайте мені знати в коментарях, якщо у вас є будь-які запитання щодо цього, якщо ви хочете, щоб я розширила його певним чином, щоб зробити його більш надійним, додала зовнішнє сховище.
Я обов’язково хочу розглянути ще кілька речей у майбутніх відео для LightRag, тому що я справді думаю, що це велика справа. І тоді для нашої базової реалізації RAG мені навіть не потрібно це висвітлювати, тому що вона в основному така ж. Одна річ, яку справді круто спостерігати, це подивитися на те, якою довгою є сцена цього скрипта, щоб імпортувати документацію Pydantic AI порівняно з тим, що для LightRag, тому що нам потрібно виконувати все.
Тож скрипт на 177 рядків коду. Якщо ми перейдемо до того ж скрипту для LightRag, їх лише 53. Тож у вас може бути трохи більше контролю, якщо ви робите все розбиття на частини та вставлення самостійно, так що можуть бути переваги. Робити все це самостійно з векторною базою даних, як-от Chromadb, але, безперечно, приємно, що LightRag піклується про стільки для нас, і він також оптимізує так багато за лаштунками, що мене насправді не хвилює.
Це, безумовно, більший рівень абстракції порівняно з Chromadb. Зазвичай я не найбільший шанувальник абстракції, але через те, наскільки технічно розроблений LightRag, для мене це не велика проблема. Я поважаю це. І так, ось вставлення документів Pydantic AI для Chroma DB, а потім налаштування агента майже ідентичне.
Де у нас є наші залежності з усім, що нам потрібно для Chroma. Тоді у нас є наш єдиний інструмент пошуку, який просто буде використовувати ChromaDB замість LightRag, а потім програма Streamlit є найбільш схожою з усього, тому що інтерфейс налаштований точно так само, навіть те, як ми взаємодіємо з агентом, ми налаштовуємо однаково.
Практичні поради та Подальші Роздуми
Остання заключна порада для вас: я заохочую вас поекспериментувати з цими різними рішеннями. Завантажте цей репозиторій, запустіть усе самостійно, просто під’єднайте свій API-ключ OpenAI. Це єдине, що вам потрібно. Тоді ви можете спробувати ці різні налаштування з тими самими запитаннями, оскільки все це використовує документацію Pydantic AI під капотом.
Отже, ви можете погратися з купою різних запитань. Подивіться, чи отримаєте ви різні результати з базовим RAG порівняно з LightRag. І я скажу, що для більшості запитів ви отримаєте досить схожі результати, тим більше, що це менша база знань. LightRag переважно виділятиметься, коли у вас тисячі або сотні тисяч документів, але все одно весело бавитися з цими різними речами.
Ви можете пограти з різними режимами пошуку для LightRag, а також максимально оптимізувати його. Тож мені буде дуже цікаво почути, якщо ви спробуєте це самостійно, особливо якщо у вас більша база знань. Якщо ви отримаєте різні результати між цими різними рішеннями. Сподіваюся, це відео допомогло вам підвищити рівень ваших RAG-агентів за допомогою LightRag та графів знань.
І це не єдиний спосіб зробити RAG більш точним, навіть якщо це справжній прорив. У вас також є агентний RAG, розширення запитів, повторне ранжування. Є стільки стратегій, що я хочу продовжувати заглиблюватися на своєму каналі. Якщо вам сподобалося це відео і ви з нетерпінням чекаєте на більше інформації про AI-агентів та RAG-стратегії, я буду вдячна за лайк і підписку.
З цим, я побачу вас у наступному відео! До зустрічі!
