Розумніше, а не просто більше: як зробити так, щоб ваш ШІ дійсно розумів ваші дані

Розумніше, а не просто більше: Як змусити ШІ читати ваші документи, а не просто їх ковтати

Ви колись замислювалися, коли вперше почули про штучний інтелект? Здавалося, це щось із наукової фантастики, як у фільмах про роботів. А зараз? Він уже розпізнає обличчя на фотографіях, пише листівки, і, здається, скоро почне каву варити, аби “знати” ваші смаки. ;)

Найбільшою силою цього “розумника” є його здатність не просто запам’ятовувати, але й розуміти те, що ви йому надаєте. Особливо це актуально для наших величезних обсягів документів: звітів, листів, аналітичних матеріалів та багато іншого. Саме тут на арену виходить Retrieval Augmented Generation, або коротко RAG. Звучить трохи космічно, чи не так? Насправді, це як дати вашому ШІ окуляри, щоб він краще бачив, або карту, щоб він не блукав у ваших знаннях.

Проблема в тому, що таких “окулярів” та “карт” існує, здається, безліч. І ось ви сидите, намагаючись обрати найкращий варіант для вашого проєкту, а мозок вирує від кількості стратегій, їхніх комбінацій та потенційних труднощів. Це як збирати меблі з IKEA, але інструкція написана санскритом. Знайомо, правда?

Тому я тут. Не для того, щоб закидати вас сухою технічною термінологією, а щоб розказати про RAG простими словами, ніби ми п’ємо каву, і друг пояснює, як зробити так, щоб мій інтелектуальний помічник не просто повторював факти, а дійсно їх розумів. Розглянемо всі ці стратегії, як скарби, що приховують в собі великі можливості. Хто знає, можливо, ви знайдете свій унікальний рецепт, котрий перетворить вашого ШІ з балакучого папуги на мудрого порадника. Тож, тримайтеся, бо інформації буде чимало, але вона – той самий золотий пил, що вам допоможе.

Хто такий RAG і чому він робить ШІ розумнішим?

Уявіть, що ви навчили робота-пилососа прибирати пил. Він відмінно з цим справляється. Але якщо ви додасте до цього інструкцію: “Пилосось тільки там, де видно бруд, і уникай крихких предметів”. Це вже значно більше, ніж просто “пилосось”. RAG – це приблизно те саме, тільки для великих мовних моделей (LLM).

Якщо ШІ – це наш робот-пилосос, котрий вміє говорити (LLM), то RAG – це інструкція та додаткові дані, що допомагають йому формулювати відповіді правильно, доречно і на основі фактів, а не просто вигадувати.

Стандартний ШІ (без RAG) – як студент, що вивчив підручник. Він може відповідати на питання, що є в ньому. Але якщо запитати щось складніше, що вимагає взаємозв’язку між різними частинами знань, або інформації поза підручником – він розгубиться.

RAG додає два важливих етапи:

1. Підготовка даних (Data Preparation): Ми беремо наші документи (ту саму “базу знань”) і “нарізаємо” їх на менші частини, щоб ШІ міг їх обробити. Ці фрагменти потім перетворюються на “ембединги” – цифрові відбитки, що зберігають сенс тексту. Всі ці відбитки ми поміщаємо в спеціальну “векторну базу даних” – щось на зразок надзвичайно розумного холодильника, де все зберігається і швидко знаходиться.
2. Генерація з доповненням (Retrieval Augmented Generation): Коли користувач ставить запитання (наприклад: “Які рішення були прийняті на зустрічі минулого тижня?”), цей запит також перетворюється на “ембединг”. Ми знаходимо в нашій базі даних ті частини інформації, “відбитки” яких найбільше схожі на “відбиток” запиту. Ці знайдені частини (це і є Retrieval) ми передаємо нашому ШІ разом із запитом. Тепер ШІ має не тільки власні “знання”, але й конкретний контекст з ваших документів, щоб дати точну відповідь (це вже Generation).

Тобто, RAG – це як надати ШІ “додатковий матеріал” перед іспитом. І від того, наскільки добре ми підготуємо цей матеріал та як ефективно ШІ зможе його використати, залежить якість його відповіді.

1. Ранжування: Перш за все – найважливіше!

Пригадайте, як буває, коли ви просите друга знайти щось у його невпорядкованому комп’ютері? Він довго нишпорить, відкриває безліч папок і зрештою видає вам те, що, на його думку, найближче до вашого запиту. З RAG може бути так само: система знаходить десятки, а то й сотні шматків тексту, що якось пов’язані з вашим запитанням. Але чи всі вони корисні?

Ранжування (Reranking) – це ніби ви просите друга: “Так, добре, ти знайшов 50 файлів. А тепер, будь ласка, вибери з них 5 найкращих, що найбільше стосуються того, що мені потрібно.”

Як це працює? Спочатку ми робимо двоетапний пошук:

• Перший етап: Ми витягуємо велику кількість потенційно релевантних шматків тексту з нашої бази даних. Це як кинути сітку якнайширше.
• Другий етап: Тут вступає в дію спеціальна “модель-реранжувальник” (часто це так званий “крос-енкодер”). Вона аналізує кожен знайдений шматок разом із вашим вихідним запитом і визначає, наскільки він дійсно відповідає запиту. Це як досвідчений редактор, котрий з низки чернеток відбирає найкращі варіанти.

Чому це так добре? Тому що ми не перевантажуємо наш основний LLM (той, що дає відповідь). Він отримує лише кілька найкращих частин інформації, які йому потрібні. Це як дати учневі не всю бібліотеку, а лише кілька ключових сторінок з підручника.

Кому це підійде? Майже всім! Якщо ви бажаєте, щоб ваш ШІ надавав точні відповіді, а не просто “щось схоже”, ранжування – найкращий помічник. Це збільшує точність і зменшує ймовірність, що ШІ “вигадає” інформацію, бо отримав надто багато “шуму”.

Цікаво знати: Ця стратегія достатньо ефективна і не дуже дорога, адже другий етап пошуку працює лише з уже відібраною інформацією.

2. Агентний RAG: Розумник, який знає, коли запитати, а коли – пошукати

Знаєте, як буває, коли ви самостійно плануєте щось? Спочатку ви дивитеся на загальну картину, потім можете заглибитись в деталі або звернутись до когось за порадою. Агентний RAG (Agentic RAG) – це про гнучкість. Ми даємо нашому ШІ можливість самостійно вирішувати, як саме шукати інформацію.

Уявіть, що ваш агент – детектив. Його завдання – розслідувати справу (запит користувача). Що він може робити?

• Зібрати всі документи, що стосуються справи: Це схоже на стандартний пошук у векторній базі.
• Прочитати один конкретний документ від початку до кінця: Іноді вся відповідь може бути в деталях одного документа, і тоді глибинний пошук кращий за поверхневий.
• Шукати та комбінувати інформацію з різних джерел: Детектив може спілкуватися зі свідками, вивчати докази, шукати інформацію в архівах.

Як це реалізується? Ми можемо застосовувати різні види пошуку: або класичний семантичний (схожість за змістом), або ж повнотекстовий пошук по одному документу, або навіть гібридний пошук (поєднання різних методів).

Де це ефективно? Коли ваші дані різнорідні, і вам потрібна гнучкість. Наприклад, ви можете мати базу даних з короткими нотатками, а також повні тексти книг чи статей. Агентний RAG дозволить ШІ обрати найкращий спосіб отримання необхідної інформації.

Але є одне “але”: Чим більше варіантів у агента, тим менш передбачуваний його шлях. Саме тому важливо чітко йому прописати правила, коли та який метод пошуку використовувати.

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

3. Графи знань: Де все пов’язано

Уявіть, що ваші документи – не просто купа паперів, а ціла мережа переплетених ниточок. Кожна ниточка – це якась сутність (людина, компанія, подія, концепція), а зв’язки між ними – це як “цукерки, які люблю”, “працює в”, “відбулася після”. Графи знань (Knowledge Graphs) – це саме про візуалізацію та обробку таких зв’язків.

Традиційний RAG шукає схожість за змістом (семантичний пошук). А графи знань дозволяють ШІ не просто знаходити схожі тексти, а й розуміти стосунки між сутностями.

Як це працює?

Ми беремо ваші документи і за допомогою LLM витягуємо з них ключові “сутності” (наприклад, “Ілон Маск”, “Tesla”, “2023 рік”) та “відносини” між ними (наприклад, “Ілон Маск” є CEO “Tesla”, “Tesla” випустила модель X “у 2023 році”). Все це записується в графову базу даних.

Тепер, коли ви ставите запитання, ШІ може:

• Знайти схожі тексти (як у звичайному RAG).
• Пройтись по зв’язках у графі знань, щоб знайти відповідь. Наприклад, якщо ви запитаєте “Які машини Tesla були випущені після 2020 року?”, ШІ може знайти “Tesla” у графі, а потім прослідкувати зв’язок “випустила модель” до всіх моделей, що мають дату випуску після 2020 року.

Що це дає? Глибше розуміння, можливість відповідати на складніші запитання, які вимагають аналізу взаємозв’язків.

Але є нюанси:

• Створення графів знань (особливо якщо ви використовуєте LLM для вилучення даних) може бути повільним і дорогим.
• Структура графа залежить від того, наскільки добре ви зможете витягнути сутності та зв’язки.

Кому це підійде? Для проєктів, де дані дуже взаємопов’язані: фінансова аналітика, наукові дослідження, медицина, бізнес-логістика.

4. Контекстуальне збагачення: Кожен шматочок тексту – з паспортом

Ми вже казали, що RAG “нарізає” документи на шматочки. Але що, якби кожен такий шматочок знав, як він пов’язаний з іншими? Контекстуальне збагачення (Contextual Retrieval) – саме про це.

Ідея проста, але ефективна: Перед тим, як зберегти шматочок тексту (chunk) у векторну базу, ми використовуємо LLM, щоб додати до нього короткий опис його місця та ролі в загальному документі.

Уявіть, що у вас є великий документ про історію України. Ми його “нарізали”. Ось один шматочок: “Козацька рада в Переяславі”. Інший: “Березневі статті”. А третій: “Заснування Києво-Могилянської академії”.

Без контекстуального збагачення ШІ може розглядати ці шматочки ізольовано. А з ним – до кожного шматочка додається щось на кшталт:

• “Цей розділ описує ключові події, що призвели до…”
• “Ця частина документу деталізує політичні домовленості, укладені після…”
• “Цей абзац демонструє розвиток освіти та культури в період…”

Як це виглядає на практиці? Ми додаємо до кожного тексту кожного шматка префікс, що описує його контекст. Наприклад: [Цей розділ описує...] === [Козацька рада в Переяславі]

Переваги:

• Краще розуміння контексту: ШІ отримує більше зв’язаної інформації.
• Підвищення точності: Зменшує ймовірність неправильного тлумачення шматка.

Недолік:

• Додатковий час та вартість: Кожен шматочок потрібно опрацьовувати за допомогою LLM, що робить процес довшим та дорожчим, як і у випадку з графами знань.

Запитання до вас: Як ви вважаєте, наскільки важливим є контекст для розуміння будь-якої інформації? Чи дійсно можливо зрозуміти якусь подію, вирвавши її з історії?

5. Розширення запиту: Додайте трохи “перцю”

Інколи проблема не в тому, як ШІ шукає, а в тому, як ми його запитуємо. Ми можемо сформулювати запит так, що він буде надто загальним, і система отримає багато не зовсім потрібної інформації. Розширення запиту (Query Expansion) – це про те, щоби зробити ваш запит “розумнішим” ще до того, як він піде на пошук.

Як це працює?

Ми беремо ваш оригінальний запит (наприклад, “як працює реактивний двигун?”) і передаємо його LLM з інструкцією: “Розшир цей запит. Додай деталі, специфічні терміни або синоніми, які допоможуть знайти найбільш релевантну інформацію про роботу реактивних двигунів, включаючи ключові принципи та конструктивні особливості.”

LLM може повернути щось на зразок:

"Який механізм дії турбореактивного двигуна?", "Етапи функціонування струменевого двигуна: вхід, стиснення, згоряння, вихід", "Роль сопла у реактивному двигуні", "Відмінності між турбореактивним та ракетним двигуном"

Ці розширені запити потім використовуються для пошуку у векторній базі.

Переваги:

• Більш точні результати: ШІ отримує більш конкретні “підказки” для пошуку.
• Простота реалізації: Це одна з найлегших стратегій для впровадження.
• Заповнює прогалини: Допомагає, коли користувач не знає точної термінології.

Недолік:

• Додатковий виклик LLM: Знову ж таки, це додає обчислювальне навантаження і може трохи сповільнити процес.

Не робіть помилок, як я колись робив: На цьому етапі, якщо занадто сильно “розширити” запит, можна надати LLM забагато варіантів, які будуть віддалені від вашої початкової мети. Тут потрібен баланс.

6. Багатокроковий RAG: Запитуй багато разів, щоб отримати все

Якщо розширення запиту – це про те, щоб зробити один запит “кращим”, то Багатокроковий RAG (Multi-Query RAG) – це про те, щоб поставити кілька запитань одночасно, сподіваючись отримати ширший спектр відповідей.

Суть така:

Замість одного запиту від користувача, ми використовуємо LLM, щоб згенерувати декілька варіантів цього запиту. Потім усі ці версії одночасно надсилаються до векторної бази даних.

Наприклад, запит: “Які наслідки зміни клімату для сільського господарства України?”

LLM може згенерувати:

1. "Вплив глобального потепління на врожайність кукурудзи в Україні"
2. "Як засухи та повені впливають на фермерські господарства України?"
3. "Які нові шкідники з'являються в Україні через зміну клімату?"

Переваги:

• Більш повний пошук: Ми охоплюємо різні аспекти теми, зменшуючи ймовірність пропустити важливу інформацію.
• Компенсує різні інтерпретації: Різні запити можуть бути інтерпретовані пошуковою системою по-різному, що збільшує повноту результатів.

Недолік:

• Більше навантаження: Як і попередня стратегія, це вимагає додаткового виклику LLM для генерації запитів, а також більше запитів до бази даних.

Запитання до вас: Чи помічали ви, що коли питаєте про щось складне, то чим детальніше ви уточнюєте, тим краще вас розуміють? Ця стратегія працює за аналогічним принципом.

7. Контекстно-чутливе “нарізання”: Ріжемо так, щоб не втратити сенс

Ми вже багато говорили про те, як RAG “шукає” та “доповнює”. Але перед тим, як шукати, треба дані підготувати. І тут ключове – це “нарізання” (chunking). Якщо нарізати занадто великі шматки, то в них буде багато зайвої інформації. Якщо занадто дрібні – загубиться контекст. Контекстно-чутливе “нарізання” (Context-Aware Chunking) – це про те, щоб робити це максимально розумно.

Стандартний підхід: Просто розрізаємо текст кожні N символів або слів. Це просто, але неефективно.

Що робимо ми: Ми прагнемо зберегти природні межі документа. Це може бути кінець абзацу, розділу, або навіть логічного блоку тексту.

Як це реалізується?

Ми використовуємо моделі (часто ті ж, що генерують ембединги), щоб знайти “природні” розриви в тексті. Це може базуватися на темі, що змінюється, або на структурі документа.

Наприклад:

• Якщо ви вставляєте текст статті, то логічним розривом буде кінець речення, абзацу або секції.
• Якщо ви обробляєте програмний код, то розрив може бути після визначення функції або класу.

Переваги:

• Збереження контексту: Шматочки тексту мають більше сенсу самі по собі.
• Точніші вибірки: Система краще знаходить релевантні частини.
• Безкоштовно та швидко: Часто ці моделі для визначення меж є досить ефективними.

Простий лайфхак: Для Python існує бібліотека docstring, яка дозволяє реалізувати гібридне “нарізання”, що є формою контекстно-чутливого підходу. Вона робить процес дуже простим і ефективним.

8. Пізнє “нарізання”: Вже потім, коли все зрозуміло

А ось це вже цікавіше і, зізнаюся, складніше. Пізнє “нарізання” (Late Chunking) – стратегія, що йде проти звичного підходу. Зазвичай ми спочатку “нарізаємо” документ, а потім створюємо його ембединги (цифрові відбитки). Тут все навпаки.

Ідея:

1. Спочатку ми застосовуємо модель до всього документа (або великої його частини), щоб отримати його “глибинні” ембединги.
2. А вже потім, маючи ці “глибинні” ембединги, ми “нарізаємо” їх так, щоб зберегти найбільше контексту.

Що це означає? Кожен маленький шматочок, котрий ми отримаємо в результаті, все одно зберігатиме інформацію про зв’язок з рештою документа. Це як ви запам’ятали всю книгу, а згодом вирішили записати найважливіші цитати, знаючи, де кожна з них знаходиться в загальному тексті.

Переваги:

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

Недолік:

• Набагато складніша реалізація: Це не для новачків.
• Вимагає потужніших моделей: Треба використовувати моделі, що можуть аналізувати довгі тексти.

Це вже для професіоналів: Якщо ви відчуваєте, що стандартне “нарізання” не дає потрібного результату, і ви готові зануритись у складніші техніки, то пізнє “нарізання” може бути вашим наступним кроком.

9. Ієрархічний RAG: Від малого до великого, від великого до малого

Уявіть, що ви вивчаєте нову тему. Спершу ви читаєте короткий вступ, а потім заглиблюєтесь у деталі, далі, можливо, повертаєтесь до загального огляду. Ієрархічний RAG (Hierarchical RAG) – це про те, щоб дозволити нашій системі робити так само.

Ідея: Ми зберігаємо інформацію на різних рівнях деталізації.

• Низький рівень: Дуже деталізовані шматочки тексту (абзаци, речення).
• Вищий рівень: Цілі документи або їх великі частини.

Ці зв’язки (наприклад, “цей абзац належить до цього документа”) зберігаються як метадані.

Як це працює?

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

Що це дає?

• Точність + Контекст: Ми можемо бути дуже точними у пошуку, а потім отримати широкий контекст. Це як знайти потрібну цитату, а потім прочитати весь розділ, щоб зрозуміти, де вона стоїть.
• Баланс: Збалансовуємо пошук по дрібних деталях з можливістю бачити “велику картину”.

Чи схоже це на щось інше? Так, на “агентний RAG”, бо він теж дозволяє гнучко вибирати, як шукати. Але ієрархічний RAG більше зосереджений саме на структурі даних: ми маємо маленькі фрагменти, котрі пов’язані з більшими.

Практичний приклад: Ось як це може виглядати в Neon (платформа з Postgresql): ми знаходимо конкретний шматочок тексту. У його метаданих бачимо, з якого файлу він походить. Далі йдемо до таблиці з метаданими документів і витягуємо весь вміст цього файлу. Дуже зручно, коли хочеш знайти щось точне, а потім детально розібратись.

10. Саморефлексія: Чогось не вистачає? Спробуємо ще раз!

Буває, ви ставите запитання, отримуєте не зовсім ту відповідь, переформульовуєте, і тоді отримуєте кращий результат. Саморефлексивний RAG (Self-Reflective RAG) – це про те, щоби навчити ШІ робити це автоматично.

Ідея проста:

1. Система робить перший пошук.
2. Потім вона себе сама “оцінює”. Використовуючи LLM, вона аналізує знайдені шматки тексту та вихідний запит і дає собі “оцінку” (наприклад, за шкалою від 1 до 5).
3. Якщо оцінка низька (наприклад, менше 3), система розуміє, що їй не вистачає релевантної інформації. Тоді вона повторює пошук, але вже з “виправленим” запитом, щоб знайти кращі результати.

Це як цикл самокорекції:

• Пошук -> Оцінка -> (Якщо потрібно) Корекція -> Повторний пошук.

Переваги:

• Підвищення надійності: Якщо первинний пошук невдалий, система не здається, а робить спробу знову.
• Автоматичний процес: Немає потреби вручну переформульовувати запити.

Недолік:

• Більше викликів LLM: Кожен повторний пошук потребує додаткового виклику LLM, що збільшує час та вартість.

Тихо… Це вже межа магії: Ця стратегія робить ШІ більш “людяним” у його прагненні досягти мети.

11. Тонка настройка ембедингів: Вчимо ШІ вашим словам

Ми говорили про ембединги – цифрові відбитки тексту, які допомагають ШІ розуміти схожість. Зазвичай ці ембединги генеруються загальними моделями, котрі знають багато слів. Але якби ми могли навчити ШІ розуміти саме ваш специфічний словник? Тонка настройка ембедингів (Fine-tuned Embeddings) – це про це.

Як це працює?

Ми можемо взяти вже наявну модель для ембедингів (навіть відкриту, безкоштовну) і “дотренувати” її на ваших власних даних, специфічних для вашої галузі (наприклад, медичні терміни, юридичні документи, технічні специфікації).

Приклад:

Уявімо, що у нас є два речення:

1. “Мій заказ запізнився.”
2. “Товари завжди розпродані.”

Для загальної моделі ембедингів ці речення можуть бути схожими, бо обидва стосуються “замовлення” або “покупки”. Але що, якби для вас важливою була схожість за емоційним забарвленням?

Якщо ми “дотренуємо” модель на даних, де “запізнення” і “розпродані товари” асоціюються з негативним досвідом клієнта, то тонко налаштована модель може визначити, що “Мій заказ запізнився” значно ближче до “клієнт сердитий”, ніж до “топ товарів”.

Переваги:

• Набагато вища точність: Модель розуміє нюанси вашої галузі, що може дати приріст точності до 5-10%.
• Використання менших моделей: Навіть менші, відкриті моделі можуть перевершити великі загальні моделі на вашій специфічній задачі.

Недоліки:

• Потребує багато даних: Щоб добре дотренувати модель, потрібен значний обсяг специфічних даних.
• Додаткові витрати на підтримку: Це вже ваш особистий, кастомний інструмент.

Як ви вважаєте, що для вас важливіше: чи розуміє ШІ, про що йдеться, чи він “настроєний” на ваш емоційний тон?

Підсумки: Три основні стратегії, з чого почати

Отже, ми ознайомилися зі всіма цими цікавими RAG-стратегіями. Їх багато, і кожна має своє призначення. Але якщо ви тільки починаєте, і хочете, щоб ваш RAG-бот дійсно став розумним, я б радив зосередитись на трьох:

1. Ранжування (Reranking): Це як “фільтр якості” для вашого пошуку. Варто застосовувати завжди, щоб не перевантажувати LLM непотрібним сміттям.
2. Агентний RAG (Agentic RAG): Забезпечує гнучкість та дозволяє системі обирати, як саме шукати. Особливо ефективно, якщо ви використовуєте багато форматів даних.
3. Контекстно-чутливе “нарізання” (Context-Aware Chunking): Це основа. Якщо ви правильно “наріжете” свої дані, то й увесь процес буде набагато ефективнішим. Спеціально раджу звернути увагу на гібридне “нарізання” за допомогою бібліотек на зразок docstring.

Пам’ятайте, найчастіше ідеальне рішення – це комбінація 3-5 стратегій. Це як добре збалансований борщ: багато інгредієнтів, але кожен на своєму місці.

Тепер, знаючи про ці можливості, ви можете експериментувати, комбінувати і створювати системи, які дійсно розуміють та аналізують ваші дані, а не просто їх ковтають.

Що далі?

• Дослідіть GitHub-репозиторій: Як я вже казав, там є багато прикладів коду та детальніші описи. Не лінуйтеся зазирнути!
• Почніть з малого: Оберіть одну-дві стратегії і спробуйте їх впровадити. Додайте своїй системі “зору” за допомогою ранжування або “кмітливості” у виборі пошуку завдяки агентному RAG.
• Експериментуйте! Кращого способу навчитися, ніж спробувати самостійно, немає.

Світ RAG-стратегій величезний, але він відкриває неймовірні можливості для роботи зі штучним інтелектом. І я впевнений, що з цими знаннями ви зможете змусити його працювати на вас набагато розумніше.

Підсумовуючи все вищесказане, Retrieval Augmented Generation – це не просто модний термін, а потужний інструмент, що перетворює великі мовні моделі на справді корисних помічників. Вибір правильних стратегій – від ранжування до контекстно-дотичного “нарізання” та тонкого налаштування ембедингів – дає змогу отримати максимальний результат від цих технологій.

Заклик до дії: Нехай ваші ШІ-агенти не просто відповідають, а й розуміють. Почніть впроваджувати ці стратегії вже сьогодні, і ви побачите, як ваші дані оживуть у новому, розумнішому форматі!

Якщо вам сподобалось це занурення у світ RAG, поставте лайк, підпишіться на канал, бо ми тільки починаємо цю захопливу подорож у світ AI. До зустрічі у наступних відео!