Чому виклик LLM — це не додаток: яке місце займає LangChain у потоці обробки RAG

Викликати велику мовну модель легко: надішліть запит, отримайте текст у відповідь. Але створити щось корисне на основі цього виклику — нелегко. Справжнє застосунок має здатність обробляти документи, знаходити важливі фрагменти, вести облік розмови, складати запити та представляти все це через інтерфейс, причому модель є лише однією з елементів цього механізму. У цій статті пояснюється, що таке LangChain, шляхом детального опису всіх цих складових, з використанням помічника для читання документів як прикладу. Після прочитання ви зможете описати кожен етап процесу пошуку інформації, сказати, які завдання бере на себе фреймворк на кшталт LangChain, та вирішити, чи підходить він або його альтернативи вашому проекту.

Що таке LangChain, у одному абзаці

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

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

Карта території

Допомагає подивитися на всю картину перед тим, як збільшити масштаб. Вивчення LangChain зазвичай поділяється на три сфери, кожна з яких ґрунтується на попередній.

Основи

Це елементи, з якими працює кожен додаток на базі LangChain:

• загальна модель компонентів
• моделі, тобто обгортки навколо API для чату та завершення тексту
• запити та шаблони запитів
• парсинг результату, щоб текст у вільному форматі перетворювався на структуровані дані

Runnables та мова виразів LangChain (LCEL) – шар композиції

ланцюги, які об’єднують кроки в робочий процес

пам’ять для зберігання контексту між етапами

Генерація з підтримкою пошуку даних

RAG – це спосіб, яким дозволяється моделі відповідати на запитання на основі власних документів. Основні компоненти:

• завантажувачі документів
• розділювачі тексту
• ембеддинги
• хранилища векторів
• механізми пошуку
• об’єднання всього вищезазначеного у функціональний додаток RAG

Агенти

Агенти дозволяють моделі вирішувати, які дії виконати. Основні теми:

• інструменти та набори інструментів
• виклик інструментів
• створення агента, який їх використовує

Решта цієї статті присвятована першим двом аспектам, оскільки саме вони пояснюють, чому взагалі існує ця платформа.

Проблема, яку вирішує LangChain

Система LLM у продакшені рідко складається з однієї лише запиту. Подивіться, з чим мусить впоратися навіть простий асистент:

• прийом документів
• здійснення семантичного пошуку
• створення та зберігання ембеддингів
• виконання генерації з підсиленням за допомогою пошуку
• керування контекстом та станом розмови
• оркестрування одного або кількох викликів LLM
• надання інтерфейсу чату

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

Приклад реалізації: читач книг з ШІ

Уявіть собі додаток, у якому користувачі завантажують книги чи PDF-файли, читають їх у вбудованому читачі та ставлять асистенту запитання щодо прочитаного. Уявіть підручник з машинного навчання: студент може запитати про баланс між упередженням та дисперсією, про структуру певної архітектури CNN, про те, що робить бекпропагація, як працюють механізми уваги чи який алгоритм оптимізації підходить для конкретної проблеми.

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

У цьому додатку LangChain би виконував наступні завдання:

• завантаження та обробка завантажених документів
• під’єднання інтерфейсу чату до LLM

керування шаблонами запитів

збереження контексту розмови між запитаннями

створення системи пошуку, яка вибирає релевантний текст

Це найясніше пояснення того, чому сама лише ШІ не може створити додаток. Модель забезпечує мовні можливості; все, що робить відповідь стосовно цієї конкретної книги, походить від супутніх компонентів.

Семантичний пошук: пошук тексту за значенням

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

Простий приклад

Припустимо, запит звучить як «Яка столиця Франції?» Система семантичного пошуку не шукає документи, які лише мають спільні токени з запитом. Вона шукає уривок, значення якого найбільш близьке — а саме абзац про Париж, а не уривки про Берлін чи Мадрид, хоча ті також стосуються європейських столиць та можуть мати високий рейтинг за кількістю спільних слів.

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

Чому це важливо для застосувань LLM

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

• кращого пошуку документів

більш точні відповіді

розумніші рекомендації

асистенти, які відповідають, беручи до уваги контекст користувача

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

Як тільки документи стають доступними для пошуку, відповідь на запитання формується за певною послідовністю:

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

Вхідні дані об’єднуються. Отримані уривки та початкове запитання з’єднуються у запрошення для моделі.

Модель обробляє його. Повне запрошення, контекст та запитання надсилаються до LLM.

Повертається обґрунтована відповідь. Оскільки модель аналізує надані тексти, а не лише пам’ять, відповідь є більш точною та легше відстежується до її джерела.

Кожна стрілка в цьому списку позначає передачу даних між компонентами, і саме цим й призначений LangChain — керувати цим процесом. Він спрощує канал отримання даних, поєднує кроки формування запитів, керує пам’яттю, вставляє контекст у запити та організовує виклики до моделі. Цей шестикроковий процес є основою будь-якої системи RAG. Якщо ви хочете детальніше дізнатися про сам процес отримання даних, наша стаття пояснює, як RAG отримує актуальні знання за потреби.

Повна архітектура RAG

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

Підготовка документів до пошуку

Перш ніж хтось зможе поставити запитання, кожен документ має бути перетворений на щось, що можна шукати:

• Завантаження. PDF-файл зберігається у сховищі, наприклад у бакеті AWS S3.
• Зчитування. Завантажувач документів читає файл та витягує з нього текст у потік обробки.
• Розділення. Функція розділення тексту розбиває його на менші частини або сторінки. Це важливо, тому що вбудовування цілої книги як одного вектора призведе до змішування всіх її тем, а крім того у моделей обмежені вікна контексту.
• Вбудовування. Кожна частина проходить через модель вбудовування та перетворюється на вектор.
• Зберігання. Вектори разом із текстом, який вони представляють, зберігаються у базі даних векторів.

На завершення цього етапу документ готовий до пошуку. Цей процес зазвичай виконується один раз під час кожного завантаження, а не з кожним запитанням.

Відповідь на запит

Коли надходить запит, запускається другий процес:

• Вбудовування запиту. Запит перетворюється на вектор за допомогою того самого моделі ембеддингу, щоб він знаходився у тому ж просторі, що й збережені фрагменти.
• Пошук. Пошук схожості знаходить фрагменти, які найбільш близькі до запиту.
• Отримання контексту. Ці фрагменти завантажуються з бази даних векторів.
• Складання запрошення до моделі. Отриманий текст та запит користувача об’єднуються у системне запрошення.
• Виклик моделі. Готове запрошення надсилається до API LLM.
• Відповідь. Модель повертає відповідь, засновану на отриманому матеріалі.

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

Що б ви інакше написали самі

Без фреймворку команда, яка розробляє таку систему, мусила б вручну реалізовувати керування запитами, логіку пошуку, вставку контексту, багатокрокові ланцюги обробки, механізми пам’яті, інтеграцію інструментів та координацію всього цього. Жоден з цих елементів по суті не є складним, але разом вони значно ускладнюють розробку та змушують код сильно залежати від однієї моделі та однієї бази даних. Завдяки повторно використовуваним абстракціям LangChain для кожного з цих елементів ви можете швидше розробляти та згодом змінювати компоненти, мінімізуючи кількість переписування коду.

Що пропонує фреймворк

Чотири переваги постійно згадуються.

Ланцюги як модель композиції

Ланцюг етапів, такий як шаблон запиту, виклик моделі та парсер результату, об’єднує їх у єдиний робочий процес, який можна запустити, протестувати та повторно використовувати. У поточних версіях це реалізується за допомогою Runnables та LCEL, які дозволяють поєднувати компоненти між собою.

Код, незалежний від моделі

Оскільки LangChain підтримує основних постачальників LLM через спільний інтерфейс, ваше застосування не прив’язане до одного постачальника. Зміна моделі стає лише зміною конфігурації, а не переписуванням коду, що корисно як для контролю витрат, так і для тестування новіших моделей.

Широка екосистема

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

Пам’ять та стан

Додатки для розмов потребують зберігання інформації про те, що було сказано раніше. LangChain пропонує способи керування контекстом розмови, пам’яттю та станом під час різних взаємодій. Рекомендований підхід змінювався з версією на версію, причому новіші інструкції рекомендують використовувати LangGraph для роботи зі станом у завданнях, тому перевірте поточну документацію для вашої версії.

Що можна створити за допомогою цього інструменту

До поширених типів додатків належать:

• Чат-боти для розмов, у яких користувачі спілкуються з ШІ мовою природи.
• Асистенти знань, які допомагають людям знаходити та розуміти інформацію у власних документах чи базах знань.
• Агенти ШІ, які виконують багатоетапні завдання та вирішують, які інструменти використовувати під час їх виконання.
• Автоматизація робочих процесів, де LLM є одним із етапів у більшому автоматизованому процесі.

Інструменти для стиснення та пошуку інформації, які скорочують матеріал та допомагають у дослідженнях.

Коли варто розглянути альтернативу

LangChain — це один із кількох варіантів, і кожна альтернатива має свою спеціалізацію:

• LlamaIndex активно зосереджується на підключенні LLM до зовнішніх даних та створенні додатків на основі цих даних та технології RAG.
• Haystack орієнтований на пошук, відповіді на запитання, технології RAG та агентські додатки.
• Semantic Kernel — це SDK від Microsoft з відкритим кодом, який дозволяє інтегрувати моделі ШІ в існуюче програмне забезпечення та координувати багатоетапні робочі процеси з використанням ШІ.
• DSPy розглядає системи LLM як програми, які потрібно оптимізувати, замість того щоб вимагати від користувача ручної настройки кожного запиту.
• AutoGen створений для додатків, у яких кілька агентів співпрацюють та взаємодіють між собою.
• CrewAI призначений для координації команд агентів, які разом виконують завдання.
• PydanticAI — це фреймворк на Python для продакшн-застосунків та агентів, які забезпечують структуровані та типобезпечні результати.

Орієнтовне правило: якщо ваш застосунок переважно здійснює пошук у власних даних, варто порівняти LlamaIndex та Haystack. Якщо для вас найважливішими є типовані результати, зверніть увагу на PydanticAI. Якщо основною ідеєю є багатоагентна співпраця, то AutoGen чи CrewAI підходять для цього. Сильною стороною LangChain є його універсальність, що робить його розумним стандартом, коли ви ще не впевнені, якою буде форма вашого застосунку. Щоб побачити пряме порівняння двох найпопулярніших варіантів, перегляньте наше порівняння LangChain та LlamaIndex.

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

Елементи, які варто вивчити далі

Коли ми розуміємо загальну картину, наступним логічним кроком є окремі компоненти, з яких складається кожен додаток LangChain:

• Моделі — інтерфейси для взаємодії з різними AI-моделями.
• Запити — елементи, які впливають на те, як модель реагує на вхідні дані.
• Ланцюги — елементи, які об’єднують компоненти в робочі процеси.
• Індекси — елементи, які пов’язують додатки з зовнішніми джерелами інформації. У новішій документації ця сфера часто описується через завантажувачі, бази даних векторів та засоби пошуку.

Пам’ять — це елемент, який зберігає контекст під час багатьох взаємодій.

Агенти — це елементи, які поєднують міркування з інструментами для виконання завдань.

Розуміння того, за що відповідає кожен з цих елементів, значно полегшує читання коду LangChain та вирішення питання, які саме компоненти дійсно потрібні вашому власному додатку.

Основні висновки

• LLM є лише одним з компонентів додатку; завантаження даних, їх пошук, формування запитів, пам’ять та інтерфейс — це все інше, і саме створення цього «іншого» допомагає LangChain.
• Семантичний пошук ранжує текст за значенням з використанням ембеддингів, тому він знаходить абзац про Париж при запитанні про столицю Франції.
• Система RAG складається з двох каналів обробки: офлайн-каналу, який завантажує, розділяє, вбудовує та зберігає документи, та онлайн-каналу, який вбудовує запит, отримує контекст, створює інструкцію та викликає модель.
• Завжди вбудовуйте запити та документи за допомогою однієї й тієї самої моделі, інакше якість пошуку значно погіршиться.
• Основними перевагами LangChain є композиція на основі ланцюгів, незалежність від постачальників, широка екосистема інтеграції та інструменти для керування станом та пам’яттю.
• Альтернативи, такі як LlamaIndex, Haystack, Semantic Kernel, DSPy, AutoGen, CrewAI та PydanticAI, кожна акцентує увагу на чомусь іншому, і дуже проста функція може зовсім не потребувати жодної фреймворку.

Пов’язана література

• Мапування RAG: етапи пайплайну, основні компоненти та ландшафт варіантів — Дізнайтеся, як працює технологія Retrieval-Augmented Generation від початку до кінця, які компоненти потрібні системі RAG та як багато різних варіантів RAG уміщуються в одну карту.
• RAG пояснено: як системи ШІ отримують свіжі знання за потребою — Дізнайтеся, як працює Retrieval-Augmented Generation, від розділення інформації на частини та створення ембеддингів до векторного пошуку, щоб моделі ШІ могли відповідати на запитання без повторної підготовки.

П’ятнадцять концепцій LLM, проаналізованих через одне запитання від клієнта до бота підтримки — Простежте одне запитання клієнта через допомогу ШІ, щоб дізнатися, що насправді роблять моделі, токени, ембеддинги, контекст, RAG, агенти та механізми оцінки, і де кожен з них закінчує свою роботу.