Еволюція ботів з ШІ: використовуємо можливості агентів, моделей RAG і LLM

Усі статті, обговорення, новини про AI — в одному місці. Підписуйтеся на DOU | AI!

Вітаю, мене звати Демʼєн. Ця стаття є продуктом мого власного дослідження та синтезу знань про різноманітні інструменти для розробки ШІ-ботів. Вона слугує особистим довідником і має на меті описати шаблони високого рівня, конвеєри та архітектурні рішення, які широко використовуються у 2024 році.

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

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

Нижче надані URL-посилання на додаткові ресурси; однак прошу проігнорувати їх під час першого читання, щоб зосередити вашу увагу. Вся необхідна інформація міститься в цій статті, тому наразі нема потреби відкривати ці посилання 😉.

Я пропоную розділити розробку ШІ загального призначення на дві основні частини:

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

Навчання LLM: аналіз фінансової доцільності

Навчання нових LLM з нуля складне та дороге. Натомість ви можете досягти кращих результатів, розробляючи застосунки, які використовують дійсні моделі General-Pre-trained-Transformers (GPT) без їх модифікації. Цей підхід часто є економічно ефективнішим і усуває обмеження традиційних LLM, як-от обробка складної математики, останніх новин, комерційних даних або нових знань, які ще не були включені в модель, — ось тут на допомогу приходить RAG, але про це трохи пізніше.

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

Навчання маленьких моделей і використання загальних моделей, тонке налаштування

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

Щоб краще зрозуміти це, візуалізуйте графік нейронної мережі. Уявіть невелику нейронну мережу з вертикально вирівняними вузлами (колами): три зелені вузли ліворуч (вхідний шар), три набори з чотирьох синіх вузлів посередині (приховані шари) і два жовті вузли праворуч (вихідний шар). Ці вертикально вирівняні вузли називаються шарами. Сучасні LLM, на відміну від цього простого прикладу із пʼятьма шарами, мають значно більше вузлів, з’єднань і шарів.

Граф нейронної мережі з 5 шарами: один вхід ліворуч, 3 посередині та один вихід праворуч.

Машинне навчання (ML) і LLM працюють через низку рівнів і зв’язків. Значення у вхідному шарі впливають на наступний шар, доки останній прихований шар не створить результат. Приховані шари — саме тут відбувається велика частина «магії» — є найскладнішою та найменш зрозумілою частиною нейронних мереж.

Хоча ми можемо осягнути невеликі нейронні мережі, мільярди параметрів у великих моделях поза нашими можливостями. Ця складність створює «Вау-момент», коли, наприклад, зображення однієї літери, розбитого на менші фрагменти, обробляється моделлю для точної ідентифікації літери. Ми знаємо методи та інструменти для налаштування та маніпулювання цими прихованими шарами, тестування та вдосконалення моделі для покращення результатів.

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

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

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

Існують різні способи тонкого налаштування, залежно від того, чи хочете ви налаштувати модель Embeddings або «велику» модель Chat LLM. Для менших моделей, таких як Embeddings, цей процес недорогий. Однак для тонкого налаштування великих моделей із мільярдами параметрів потрібне спеціальне обладнання, яке може бути дуже затратним.

Щоб зменшити витрати, було розроблено кілька методів тонкого налаштування. Перший — «заморозити» модифікацію деяких вузлів та змінювати лише частку що не заморожена. І ще більш економічно ефективнішою є адаптація низького рангу (LoRA). Замість того, щоб змінювати всі або частину мільярдів параметрів, LoRA додає новий рівень до нейронної мережі. Альтернативи LoRA включають GaLore і DoRA.

Напрямки розробки та вдосконалення моделей

Розробку та вдосконалення LLM можна розділити на дві основні категорії:

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

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

Типи моделей

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

Проте, зростає тенденція до об’єднання цих можливостей. Зараз багато текстових моделей підтримують кілька мов, включаючи мови програмування. Крім того, деякі моделі можуть одночасно працювати з текстом і зображеннями як на вхід (Decoding), так і на вихід (Encoding), це відомо як мультимодальні моделі.

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

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

Loss Function

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

Loss function загалом поділяється на два типи: класифікація та регресія.

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

Еволюція: v1.0

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

Першим великим кроком стала розробка великих мовних моделей (LLM). Другий крок це створення застосунків Retrieval-Augmented Generation (RAG) навколо LLM для покращення відповідей шляхом додавання релевантної інформації як контекст, таким чином усуваючи слабкі сторони LLM за допомогою різних функцій та інструментів. Третій крок — це розширення RAG до Агентів, які можуть взаємодіяти з реальним світом і виконувати завдання за допомогою інструментів, а не просто відповідати на запитання в чаті.

На кожному з цих кроків існує гнучкість у тім, як саме створено ваш застосунок, що дозволяє експериментувати, та адаптувати його до задачі. Для спрощення я називатиму ці кроки версіями v1.0, v2.0, v2.5, v3.0 і v3.5. Хоча це не є офіційною термінологією, проте допоможе впорядкувати інформацію та структурувати цю статтю.

Inference: двигун, здатний запускати вашу модель що генерує результат. Не плутати із RAG-застосунком.
Serve: процес надання Inference як сервіса через API endpoint за протоколом HTTP.
Модель LLM: сприймайте це як папугу, здатного повторювати слова, переставляти їх або навіть відповідати на запитання. Це алгоритм нейронної мережі, який зберігається у вигляді файлу та виконується механізмом Inference. Коли модель виконується з вводом від користувача, вона може відповідати відповідним чином. LLM відрізняються своєю здатністю розуміння та генерування мови, отриманої шляхом вивчення статистичних зв’язків із документів під час навчального процесу.
RAG-застосунок — код, написаний найчастіше на python чи node.js. Він буде звертатись до inference-двигуна за допомогою API.

RAG: використання інструментів v2.0

LLM часто «галюцинують», дають неточні відповіді або просто чогось не знають. Ось чому було винайдено Retrieve Augment Generate (RAG) Pipeline: щоб направляти, перевіряти та вводити нову інформацію як контекст, що дозволяє досягти кращих результатів.

RAG можна називати «підхід», «методика», «Pipeline» або «шаблон», хоча я обмежусь термінами «RAG-застосунок» або «RAG-конвеєр», які буду використовувати як синоніми в цій статті. Якщо вам потрібно вставити посилання на оригінальні документи, LLM не здатна цього зробити, наприклад, подивіться на Bing/Copilot RAG, який не лише відповідає на ваше запитання, але й надає URL-посилання на документи, які він використав для створення кінцевої відповіді. LLM не знають комерційної інформації, останніх новин, знань, які не були включені в модель під час навчання. Ці недоліки можна виправити із допомогою RAG.

Цей шматок створений під впливом статті Олексія Гончара.

На зображенні вище ви можете побачити простий застосунок на основі RAG, який приймає запит користувача, витягує додатковий контекст, який має відношення до запиту, і передає LLM.

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

RAG може аугментувати LLM за допомогою:

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

LangChain: поєднання розробки та продуктиву, обробка даних

LangChain-фреймворк полегшує розробку, усуваючи необхідність запускати ресурсомісткі екземпляри баз даних, дозволяючи працювати безпосередньо з файлами бази даних. Виробничі середовища повинні використовувати запущені виділені застосунки бази даних, які взаємодіють через API з IP-адресою екземпляра БД, а не працюють безпосередньо з файлами бази даних. LangChain може генерувати та читати файли бази даних для розробки. У той час, як для виробництва ідеально використовувати повноцінний екземпляр бази даних. Звісно ж, у LangChain набагато більше застосувань.

Типи даних

Щоб додавати в контекст LLM за допомогою RAG релевантну корисну до запиту інформацію, вам доведеться по-різному опрацьовувати різні типи даних, по-різному їх зберігати та використовувати різні інструменти. Існує багато типів даних. Спочатку розберімось, які існують типи даних, а потім з інструментами, якими можна користуватись.

Високорівнево дані можуть бути: структуровані, неструктуровані та напівструктуровані. Попри те, що назва «Структурований» може здатися зрозумілою, вона не означає загального чи людського розуміння структури. Наприклад, файл TXT із книгою, яка добре відформатована з ідеальною структурою, вмістом або індексом сторінок і розділів ідеально форматування та з пронумерованими сторінками та чудовою граматикою і простотою розуміння для людини, цей файл НЕ є прикладом структурованих даних. У світі ІТ, з комп’ютерного погляду термін структурованих даних має дуже точне та конкретне значення.

Структуровані дані в ІТ означають табличний вигляд тексту, цей тип даних має принаймні одну таблицю із записами (рядками) і полями (стовпцями). Таблиця має відповідати певній схемі, тобто стовпці мають містити дані одного типу, а не просто випадковий текст, що зберігається в таблиці, наприклад, у стовпці із заголовком «Чистий дохід» кожен рядок має містити цифру, а не смайлик усміхненого обличчя. Приклади:

  • таблиці (наприклад, XLSX, CSV, Google Sheets, LibreOffice Calc);
  • реляційні бази даних такі як MySQL та PostgreSQL (SQL);
  • бази даних ключ-значення, такі як Redis (велика одна таблиця з кількома стовпцями);
  • якщо БД містить, скажімо, дані у форматі JSON, то ці дані є напівструктурованими. Якщо вона містить фрагменти тексту, то сам текст є неструктурованими даними.

Неструктуровані дані у світі ІТ також є дуже специфічним типом, наприклад: текстові документи та мультимедіа. Тобто, TXT-файли відносять до неструктурованих даних.

Текстові дані:

  • текстові документи (наприклад, DOCX, RTF, TXT, ePub тощо);
  • PDF-файли;
  • файли HTML/вебсторінок.

Мультимедіа:

  • зображення (наприклад, JPEG, PNG);
  • аудіо, голос (наприклад, MP3, WAV);
  • відео (наприклад, MP4, AVI).

Напівструктуровані дані:

  • електронні листи мають певну структуру: заголовки, текст і вкладення;
  • те саме з файлами JSON, XML і YAML;
  • бази даних NoSQL: MongoDB (MQL), Cassandra (CQL), Neo4j (Cypher), Nebula (GQL, Cypher).

Типи даних і інструменти для зберігання та обробки

Я хотів би підкреслити універсальність баз даних Knowledge Graph Databases (KGDB). Вона вміє працювати з різними типами даних, включно з неструктурованими, як-от книга, напівструктурованими та структурованими таблицями, як-от файли CSV. Крім того, деякі KGDB, як Neo4j, можуть функціонувати як векторна база даних, надаючи гнучкість та свободу використання для задач ШІ.

Порівняно з реляційними базами даних, KGDB може демонструвати кращу продуктивність, особливо коли очікуються численні операції з’єднання (такі як SQL Join). Наприклад, якщо необхідно отримати більш як п’ять рівнів глибоких ієрархічних операцій з’єднання зі зв’язками parent-child або якщо потрібно сформувати запити, які містять понад 500 ідентифікаторів в одному з’єднані, KGDB може бути більш ефективним вибором.

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

  1. Якщо ви плануєте зберігати лише структуровані дані, реляційна БД може забезпечити кращу продуктивність, універсальність і, найголовніше, мова SQL для запитів може бути більш знайомою, ніж Cypher чи щось інше.
  2. Деякі KGDB, такі як Neo4j, можуть служити векторним сховищем, але можуть не так швидко оброблювати дані, як спеціалізовані векторні бази даних, такі як Chroma, Milvus або Weavite. Крім того, Neo4j має обмеження розмірності у 4096 вимірів, що є досить великим і має бути достатнім для майже всіх завдань, хоча в деяких випадках може бути не зручним.
  3. KGDB може бути непридатним для мультимедійного вмісту, натомість краще використовувати векторну базу даних або щось інше.

Ви зберігатимете всі ці типи даних у різних місцях і на сервері, наприклад, файли YAML можна зберігати в кластері etcd, які будуть доступними через API k8s, а електронні листи та XML зазвичай зберігаються на якомусь сервері, і також доступні через API. Текстові файли розбиті на фрагменти ви, ймовірно, зберігатимете в KGDB або векторній базі даних. А от табличні дані ви, ймовірно, зберігатимете в реляційній БД.

RAG і типи даних

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

Неструктуровані дані можуть бути занадто великими, і вам може знадобитися розділити їх на менші фрагменти, а потім зберегти та проіндексувати у векторній базі даних. Напівструктуровані дані можуть підтягуватись через API, CQL, MQL, GQL або Cypher.

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

Структуровані дані та інструменти даватимуть найкращі результати. Напівструктуровані будуть кращими порівняно з загальними інструментами семантичного пошуку, такими як векторна БД, та неструктурованими даними. Хоча більшість даних є неструктурованими, тому на практиці вам можуть знадобитися усі ці інструменти.

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

На перший погляд, ці дані повинні зберігатися в реляційній БД і відповідно витягуватися за допомогою інструментів SQL, що в принципі правильно. Але якщо ви помітили, у нас ще є також такі речі, як скарга та відгуки пацієнтів, які найкраще витягти й обробити за допомогою семантичного пошуку (векторна база даних). Семантичний пошук корисний, коли вам потрібно відповісти на питання про враження пацієнта, почуття, сприйняття, настрої або будь-яку іншу якісну інформацію.

Цей підхід не буде дієвим для відповідей на об’єктивні запитання, які містять математичні функції, такі як підрахунок, відсотки, агрегації або перелік фактів. Наприклад, якщо запит користувача: «Чи задоволені пацієнти своїм постачальником послуг?». У цьому випадку вам, ймовірно, знадобляться обидва: реляційна база даних для витягування об’єктивної інформації за допомогою SQL-запита, а також векторна база даних із семантичним пошуком для отримання якісних даних.

WrenAI — гідний уваги і зручний опенсорс-продукт для генерації Text-to-SQL. Можна запускати як локально, так і у вас в k8s. Має UI та API, через який можна робити запити та отримувати відповідь як із згенерованим SQL під ваш запит, так і витягнуті данні. Що дуже спрощує роботу із структурованими даними.

Фази RAG

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

  1. Обробка, підготовка, індексування та розміщення інформації для зберігання в якійсь базі даних. Зазвичай це робиться розробниками одноразово, на вимогу або за розкладом.
  2. Ініціюється запитом користувача під час виконання. Отримання маленької частини релевантної інформації з БД, що супроводжуватиметься запитом користувача, для додаткового контексту.

Embeddings та векторні бази даних

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

Уявіть собі цифрову бібліотеку з величезною колекцією (наш набір даних). Кожна книга представлена ​​набором координат — числовим вектором, який відображає суть вмісту, жанру, стилю та інших особливостей книги за допомогою унікального «цифрового відбитка» для кожної книги.

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

Іншим найпростішим прикладом використання може бути те, що ви шукаєте синонім слова. Embeddings може допомогти вам знайти схожі або «близькі» слова, але, звісно, така технологія може набагато більше. Семантичний пошук — дуже ефективний спосіб швидкого пошуку інформації, пов’язаної з вашим запитом, і саме так працює пошукова система Google.

Дозвольте мені навести інший приклад. Це буде зрозуміліше в порівнянні з тим, як люди дивляться на дані: уявіть, що ви шукаєте на карті міста поблизу Києва. Якщо комп’ютер знає координати {50°40’19"N, 30°36’78"W}, то щоб знайти місто поблизу Києва, йому не потрібна карта, а лише список координат усіх інших міст! Серед міст ця точка {50°58’82"N, 30°43’29"W} є найближчою — м. Вишгород. Зверніть увагу, наскільки близькі координати широти та довготи.

Тепер ми можемо ще один додатковий «вимір» із розміром міста за чисельністю населення, і якщо користувач запитує знайти найближче до Києва місто враховуючи населення, відповідь може бути іншою для даного запиту. Ми можемо додати більше «вимірів». За допомогою цього алгоритму комп’ютери можуть знайти схожість у телевізійних комедіях, одежу чи будь-чого. Науковою мовою це було б сформульовано як «Розміщення семантично подібних запитів близько один до одного у векторному просторі».

Embeddings — це дуже потужний інструмент для модифікації запиту користувача, та збагачення його релевантною інформацією шляхом розміщення запиту користувача до категорій, до яких він належить, і пошуку подібної інформації за допомогою спільних категорій з інших джерел. Гарним прикладом, коли треба використовувати в Embeddings, можуть бути щоденні новини, про які наша LLM-модель ще не знає. Замість того, щоб щоденно навчати нову LLM-модель, ми просто отримуємо новини з інших джерел і надаємо найбільш точну та релевантну інформацію як додатковий контекст разом з оригінальним запитом користувача до моделі.

Чому нам потрібно кодувати та представляти наш набір даних у перетвореному стані як Embeddings та перетворювати запит користувача у вектори, а потім шукати вектори замість простого пошуку в оригінальному наборі даних безпосередньо використовуючи запит? Тому що саме таким чином компʼютери швидше оброблюють та краще розуміють зв’язок між інформацією. Іншими словами, вектори або координати, видані Embeddings-моделлю до якогось тексту, які чисельно подібні, також є семантично подібними.

У першій фазі RAG підготовлює інформацію з нашого набору даних, розбиваючи на фрагменти, що перекриваються, і зберігає в базі даних (називається векторна БД) із закодованими числовими представленнями (векторами), щоб пізніше, у другій фазі, ви могли швидко отримати маленький шматок релевантної інформації як додатковий контекст для запиту користувача.

Embeddings кодують текст із нашого набору даних в індекс у першій фазі та зберігають їх у векторній базі даних. Потім у другій фазі запит користувача також кодується за допомогою тієї самої моделі Embeddings, а індекс із векторами, згенерований запитом користувача, використовується для пошуку та отримання фрагментів тексту з векторної БД, так само як працюють пошукові системи. Для кодування тексту з числовими представленнями (векторами) використовується модель Embeddings, яка зазвичай набагато менша, ніж LLM. На сьогодні практично всі Embeddings-моделі є деякими варіантами від моделі BERT.

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

Розбивка (Chunking)

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

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

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

Але для початку розгляньте «простий» підхід із фіксованою довжиною у 500 символів із перекриттям 100 символів і продовжуйте далі, оскільки вам можуть знадобитися набагато менші чи більші фрагменти або, можливо, семантичне фрагментування буде кращим для вашої конкретної задачі.

А потім спробуйте, наприклад, рекурсивний розділ символів. Зокрема, існують інструменти для динамічного фрагментування на основі типу файлу, наприклад unstructured.

Векторна БД

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

Наприклад, ви можете мати три виміри в просторі та один додатковий вимір населення міста та міської площі, таким чином ми отримаємо п’ять вимірів плюс назву міста, що складається з шести стовпців. Ці розміри можуть представляти різні характеристики міста чи будь-якої іншої сутності, наприклад слова. І ми можемо знайти схожість або «близькість» або подібність одного слова до іншого.

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

Моделі Embeddings допомагають перетворити фрагменти нашого тексту на групу векторів і зберігати ці фрагменти з їхніми векторними представленнями у векторній базі даних. Коли модель Embeddings кодує ваш текст у вектори, вона виробляє «систему координат» в багатовимірному просторі, який є унікальним для цієї сигнатури моделі Embeddings.

Ось чому, якщо ви закодували ваші фрагменти інформації за допомогою однієї моделі Embeddings, ви зможете знайти схожі, тільки якщо ви використовуєте тут саму систему координат. Іншими словами, на практиці, якщо ви закодували купу файлів і зберегли їх у векторній БД за допомогою, скажімо, OpenAI text-embedding-ada-002 model, ви не можете закодувати запит користувача за допомогою будь-якої іншої моделі Embeddings для пошуку, бо це вже буде інша система координат.

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

Насправді ви можете мати набагато більше, ніж п’ять вимірів, у вас можуть бути сотні чи навіть тисячі вимірів. Зазвичай чим більше, тим краще з погляду якості (хоча це не завжди так), з іншого боку, пошук найближчих подібностей із більшою кількістю вимірів потребує більше обчислювальних потужностей, а також споживає більше пам’яті. Різні векторні бази даних можуть дозволяти різну кількість підтримуваних вимірів і алгоритмів пошуку подібності.

Станом на 2024 року поточна таблиця лідерів із десяти найпопулярніших моделей Embeddings досягає 4096 вимірів. Кожна модель Embeddings може кодувати дані в різну кількість вимірів, тому вам потрібно переконатися, що ваша векторна база даних може зберегти згенеровану систему координат.

Приклад моделей Embeddings та кількості вимірів (координат).

Модель, кількість вимірів. Приклад для OpenAI:

  • text-embedding-ada-002 — 1536;
  • text-embedding-3-small — 1536;
  • text-embedding-3-large — 3072.

Векторні бази даних і максимум вимірів, що підтримуються:

  • Chroma — не має обмежень на кількість вимірів;
  • Milvus — максимум 32 000;
  • Weavite — максимум 65 000;
  • Neo4j — максимум 4096.

Не так давно більшість LLM мали дуже короткий розмір контекстного вікна, але нещодавно він значно покращився завдяки стрибку з 4096 вхідних токенів до вражаючих 32 000, 128 000 або навіть більше. Дехто може подумати, що векторні бази даних більше не потрібні, хоча це дуже дискусійно, оскільки обробка 32 000 токенів тексту в LLM може коштувати значно більше, займати надто багато часу, і, що найважливіше, може сплутати LLM величезною кількістю інформації. Також моделі з великим вікном контексту зазвичай коштують дорожче за токен. Принаймні на даний момент LLM, як правило, краще відповідають із скороченою кількістю інформації, а менші фрагменти, додані до контексту, обчислюватимуться швидше та, ймовірно, дадуть кращі результати.

Дерево думок RAG: багатошарове міркування

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

То ж навіщо вам RAG? Щоб покращити якість результату, змусити LLM думати краще, поєднати результати кількох LLM, на виході отримати якіснішу відповідь.

Пам’ять: короткострокові та довгострокові міркування

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

Довгострокова памʼять: структуровані дані

Табличні дані можна зберігати в реляційній базі даних, тій як PostgreSQL, Oracle RDBMS, MySQL та інших. Подібно до векторів для отримання даних із БД ваш додаток має перетворювати запит користувача, але цього разу на мову SQL. Цей тип даних забезпечує, мабуть, найкращий можливий результат чим інші типи даних.

Конвертація запиту користувача Text-to-SQL наразі відносно проста задача якщо ви користуєтесь OpenAI GPT, є навіть моделі, які спеціально навчені лише наборам даних SQL, такі як sqlcoder, llama-3-sqlcoder, claude-3-opus, duckdb-nsql, starcoder2:15b-instruct, codeqwen:7b-chat та інші, які можна запускати на власних серверах локально, а також існують зручні інструменти, які допомагають створювати готові RAG pipelines для генерації SQL і отримання даних із вашої бази даних.

Довгострокова памʼять: графи знань і напівструктуровані дані

Одним зі способів полегшення пошуку взаємопов’язаної та релевантної інформації з додатковим контекстом для запиту користувача є використання Graph-бази даних, такої як Neo4j або Nebula Graph, яка збирає дані в повʼязані мережі.

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

Онтологія

Якщо ви знайомі з термінологією Schema з реляційної БД, то це схожий термін, але для вільного тексту для більш простої структури даних, ніж SQL.

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

Розглянемо цей приклад: «Andre летить у Париж». Тепер ми розділили це на три частини, у цьому прикладі:

  • «Andre» — це суб’єкт (Вузол/Node);
  • «летить у» є відношенням (Звʼязок/Relationship);
  • «Париж» — це об’єкт (Вузол/Node).

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

Тепер ми можемо потренуватися створювати категоризації для суб’єкта/об’єкта та відношення, щоб класифікувати та впорядковувати наші дані для полегшення пошуку. Розглянемо інший приклад: «У машини є колеса». Тож тепер ми можемо захотіти мати:

  • Субʼєкт може бути з міткою: Людина або Машина;
  • Звʼязок двох категорій: «ДІЄ» і «МАЄ»;
  • Об’єкт це: місто або машина.

Це наша схема — наша онтологія. Коли ви створюєте граф знань, вам потрібно створити онтологію для даного тексту. Ви можете побудувати онтологію з сутностями («Париж», «Andre», «Volvo V70») або концептами («Місто», «Людина», «Автомобіль»).

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

(Person: Andre) -[ACTING: Drives]->(Car: Volvo V70)
(Person: Andre)-[ACTING: Surgery]->(City: Cincinnati)
(Person: Andre)-[HAS]->(Car: Volvo V70)

Неповний граф

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

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

Вектор, граф та LLM

На перший погляд, можна подумати, що векторні бази даних і Graph DB несумісні. Цікаво, що їхнє поєднання може дати кращі результати.

Один із підходів — це збагатити ваш граф знань для першої фази RAG. Уявіть, що у вас є великий набір тексту, наприклад, повне зібрання творів сера Артура Конан Дойля. LLM може проаналізувати текст і створити онтологію або схему для його книг. Однак цей процес може призвести до створення синонімів вузлів і зв’язків, а також до непов’язаних сутностей, які виглядають схожими.

Щоб вирішити цю проблему, ви можете вставити всі сутності з вузлів і зв’язків у векторний простір. Модель Embeddings розташує схожі сутності близько одна до одної у векторній БД. Потім ви можете ідентифікувати близькі пари та порівняти ці пари за допомогою оцінки парної подібності (Pairwise) з LLM, щоб визначити, чи вони справді є синонімами. Повторюючи цей процес, ви можете ідентифікувати пари синонімічних сутностей, зменшуючи шум.

І навпаки, ви можете отримати інформацію з вашого вже існуючого графа знань, щоб використовувати його для збагачення метаданих до фрагментів у векторній БД. Ці метадані можуть допомогти відфільтрувати фрагменти, що стосуються запиту користувача. Наприклад, якщо запит користувача містить 2024 рік, а ваші фрагменти мають в метаданих тег «рік=2024», ви можете відфільтрувати та шукати лише фрагменти з указаним роком, а потім шукати подібності лише серед них, зменшуючи шум.

Агенти: багатофункціональний ансамбль інструментів v3.0

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

З погляду практики, важливо знати, що агенти покладаються на «виклики API функцій», і ваш механізм, що обслуговує inference, повинен мати можливість обробляти такі виклики API. Приклади Inference-двигунів, які підтримують виклик функцій, включають OpenAI, Ollama, LocalAI та xorbitsai/inference. Бібліотека LiteLLM дозволяє перевірити, чи підтримує ваш Inference-двигун виклик функцій. Крім того, сама модель повинна обробляти запити виклику функцій. Прикладами Inference-двигунів та моделей, які підтримують виклики функцій, є OpenAI/gpt-3.5-turbo, Mistral, LocalAI/llama3—8b-function-call-v0.2 та Ollama/mistral:v0.3.

Сприймайте агента як працівника, який може виконувати одне чи кілька завдань. Що робити, якщо вам потрібен більше одного працівника? Ви можете використовувати системи мультиагентних оркестраторів, такі як CrewAI (На базі з LangChain) або LangGraph, щоб розподіляти завдання між командою працівників для спільної роботи над вашим завданням.

ReAct Агент: спрощення складних запитів v3.5

Розум і дія (Reason & Action, ReAct) просуває агентів трохи далі. Це загальний дизайн, ідея якого — змусити LLM-модель виводити покроково потік своїх думок, таким чином декомпозуючи складні питання на спрощенні підпитання, щоб отримати вичерпну та якісну відповідь.

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

«Магічний соус» у структурі ReAct — це підказка в контексті запита до моделі, яка спонукає модель LLM використовувати наведений нижче процес мислення: запитання, дія, виконання дії та спостереження.

Answer the following questions as best you can. You have access
to the following tools:
{tools}
Use the following format:
Question: the input question you must answer
Thought: you should always think about what to do
Action: the action to take, should be one of [{tool_names}]
Action Input: the input to the action
Observation: the result of the action
… (this Thought/Action/Action Input/Observation can repeat N times)
Thought: I now know the final answer
Final Answer: the final answer to the original input question
Begin!
Question: {input}
Thought:{agent_scratchpad}
There are three placeholders {tool}, {input}, and {agent_scratchpad} in this prompt. These will be replaced with the appropriate text before sending it to LLM.

Генератор тексту в код та його виконання: автономні агенти

Існують спеціальні моделі LLM, навчені створювати код, наприклад Codestral, Codex, Code Llama, Codet5-open-code, AI2SQL і Starcoder2. Деякі багатоагентні системи, такі як OpenDevin, Devika і Microsoft AutoGen, просунулися далі, виконуючи та навіть тестуючи згенерований код. Що, з одного боку, є потенційною проблемою безпеки. Але з іншого боку може значно покращити якість вашої відповіді.

LLMs можуть «галюцинувати», відповідаючи на запитання, пов’язані з новинами чи математикою, і коли працюють зі специфічними задачами аналізу даних із великою структурою даних. Вони можуть мати труднощі з гнучкістю для виконання різноманітних потреб користувачів. Хоча RAG може вирішити першу частину, математика залишається проблемою.

Наприклад, якщо модель запитають: «Скільки буде 1/3?», LLM не завжди може дати правильну відповідь, якщо вона спеціально не була навчена відповідати на такі запити. Навіть просунуті LLMs, все ще стикаються з проблемами точних числових розрахунків. Вони можуть дати приблизні відповіді, якщо тому не були навчені.

Text-to-Code Generator and Executor

Вирішуючи завдання, що вимагають точних обчислень, як-от перетворення градусів Фаренгейта в градуси Цельсія, великі LLM можуть надавати приблизні значення на основі своїх навчальних даних. Для точних обчислень кращим підходом було б надати завдання, щоб LLM створила фрагмент коду, наприклад, у Python, для виконання обчислень.

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

Аугментація Inference API

Незалежно від того, чи запускаєте ви свої моделі локально за допомогою таких інструментів, як Ollama, LocalAI, LM Studio, Jan, Llamafile, GPT4all, або через платні служби, такі як OpenAI, Azure OpenAI Service, Groq, Anthropic, MistralAI, Cohere, Google Vertex-AI, Replicate.com, або HuggingFace Text-Generation-Inference, ви скоро зрозумієте, що ці API відрізняються. Ці відмінності можуть варіюватися від невеликих нюансів до великих розбіжностей, навіть серед API, які заявляють про повну сумісність.

Наприклад, ви можете мати доступ до моделі text-embedding-ada-002 OpenAI і моделі text-embedding-ada-002 LocalAI, але вони абсолютно різні та несумісні з погляду кількості вимірів та створені векторні простори матимуть не сумісні системи координат. Навіть якщо API сумісні, вони рідко сумісні повністю на всі 100%.

Використання кількох моделей від різних служб може бути більш рентабельним. Ви можете запустити невелику модель локально для таких завдань, як генерування запитів Text-to-SQL, що зробить її недорогою, водночас вибравши модель Groq для LLM Chat і модель HuggingFace для Embeddings, щоб досягти кращої продуктивності та економічності.

Щоб користуватись усіма цими варіантами та спростити майбутні зміни, подумайте про впровадження рівня абстракції між вашим додатком та inference API, таким як, наприклад, LiteLLM. Цей підхід забезпечує гнучкість і масштабованість в міру розвитку ваших потреб.

Тестування RAG/Agent, контроль показників

Ви створите свій застосунок, але це ще не кінець. На цьому етапі ви можете зрозуміти, що існує дуже багато змінних, які вам може знадобитися налаштувати, і те, як ви налаштовуєте свій застосунок: розмір фрагментації, застосування різних інструментів для фрагментації різних типів даних, вибір розміру фрагментів, вибір з різних алгоритмів векторного пошуку, скільки перших результатів (Top-K) поверне ваша векторна база даних, вибір моделі чату LLM, вибір моделі Embeddings, яка створює різну кількість вимірів, якість prompt engineering та конкретні тімплейти із підказками та інструкцією, тип RAG, вибір інструментів для витягування ваших структурованих і напівструктурованих даних, кроки, які може виконувати ваш RAG, як працює пам’ять вашого RAG, чи пам’ятає він останні 10 повідомлень, чи лише їхній підсумок?

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

Оцінка якості

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

Пам’ятаєте, як ми фрагментували та зберегли фрагменти даних у векторній БД? Створімо сценарії для вашого застосунку на основі цього процесу. Ось як працює RAG: спочатку ви розділяєте текст на фрагменти та вставляєте ці фрагменти у свою векторну базу даних. Під час виконання із кожним запитом користувача ваш застосунок шукає ці фрагменти, щоб підставити їх у контекст вашої моделі Chat LLM.

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

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

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

Швидкодія

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

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

Prompt Engineering

Якість контексту, отриманого через пошук Embeddings у вашій векторній базі даних, може не завжди бути ефективною для LLM Chat. Деякі моделі дотримуються інструкцій краще, ніж інші, і залежно від особливостей моделі певні підказки можуть працювати ефективно, а інші — ні. Тому вкрай важливо дібрати текст підказки та інструкцій, які найкраще підходять для вашої моделі LLM. Є спеціалізовані ресурси, які діляться прикладами підказок та інструкцій, які можуть бути ефективними.

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

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

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

Відгуки користувачів: для адаптації застосунку

Якщо ваш застосунок може оцінювати відгуки, ви можете збільшити якість та покращити взаємодію з користувачем, використовуючи такі реакції, як «подобається 👍» або «не подобається 👎» на відповідь. Крім того, якщо ви спілкуєтесь із чистими моделями, то можете помітити, що кожного разу, коли ви щось запитуєте, модель починає з чистого аркуша, немає жодної пам’яті, в них чиста амнезія. Тож RAG може допомогти виправити це, взявши до уваги відгук користувача із поточної історії розмови та додавши їх як контекст.

Локальне тестування за допомогою Docker Compose

Docker Compose дозволяє тестувати застосунок штучного інтелекту локально, маніпулюючи ним за допомогою змінних середовища. У багатьох проєктах, як-от LocalAI чи Ollama, майже повністю або частково використовують майже той самий API, що й OpenAI, що дозволяє запускати такі моделі, як Mistral або Llama локально, а потім легко перейти їх на ChatGPT.

Для початківців дуже простий та зручний продукт Flowise із UI для створення RAG та Агентів за допомогою drag-n-drop. Він дозволить краще закріпити та засвоїти описані принципи в цій статті та, що для багатьох важливо, візуалізувати pipeline застосунку. Будь-кому рекомендую почати вивчення RAG та Агентів саме із цього продукту. Він дозволяє використовувати як LangChain, так і Llamaindex-фреймворк. На жаль, не дуже підходить для продуктиву через брак багатьох функцій, як-от робота із Knowledge Graph, та зручність і простота роботи виливаються у брак глибоких налаштувань і усіх доступних можливостей, коли ви програмуєте код.

Розгортання: використання моделей та DevOps

Локальні моделі штучного інтелекту без графічного процесора чи спеціалізованого обладнання можуть відповідати із затримками, наприклад 1 хвилина, що може бути прийнятними для розробки. Якщо у вас є Apple Silicon (який використовує Metal GPU Framework) або ПК із графічними процесорами NVIDIA чи AMD, це може значно пришвидшити відповідь вашої моделі. Це також може бути стратегією для зниження ціни розробки вашого застосунку локально за допомогою докер-контейнерів і розгортання у виробничому середовищі, наприклад k8s чи пізніше, тому ви напевно захочете мати CI/CD, із такими GitOps-інструментами, як ArgoCD чи FluxCD, що може значно спростити цей процес.

Повертаючись до початку

Досконалості не існує, і якщо на цьому етапі вже все зроблено, ви можете повернутися до самого початку цієї статті: подумайте про навчання нових моделей для вашої конкретної задачі або зробіть тонкий тюнінг наявної моделі. І на цьому витку з новою моделлю ви, ймовірно, почнете краще розуміти, як покращити свій застосунок RAG/Agents ще раз... Так, коло життя. Або коло ШІ.

Резюме:

Розкладання запиту на простіші задачі та введення додаткового контексту, як правило, забезпечує кращі результати. Фреймворки LangChain & LlamaIndex мають на меті полегшити платформу для розробки RAG. Розуміючи та ефективно використовуючи конвеєри RAG і шаблони агентів, розробники можуть створювати адаптивні системи штучного інтелекту, які можуть виконувати дії в реальному світі, заточені на певні області та задачі.

Важливо розуміти свої дані та як з ними працювати. Тестування, оцінка, контрольні показники допомагають виміряти та покращити ваш застосунок. Аугментація API — важливий крок в правильному напрямку, щоб уникнути Vendor Lock-in та допомогти з локальними тестами та розробкою. Концепції RAG & Agents слугують платформою синергії між парадигмою ReAct, Embeddings, графом знань і LLM, що прокладає шлях для наступного покоління додатків із ШІ. Розуміння застосунку та продумані способи жонглювання вашими даними можуть знизити витрати.

Підтримка:

Якщо вам сподобалася ця стаття і ви хочете підтримати мене:

  1. Натисніть «Подобається 👍» та додайте «До обраного ⭐️» мою статтю; це допоможе мені.
  2. Слідкуйте за мною на DOU щоб отримувати останні статті.
  3. Поділіться цією статтею в соціальних мережах ➡️🌐
  4. Дайте відгук у коментарях нижче, навіть якщо це просте «дякую» — це допоможе мені розуміти, що моя робота була не марною.
  5. Якщо є помилки, скажіть де, а найголовніше як виправити, не претендую на роль всезнайки.
  6. Додайтесь до мого кола в LinkedIn.
  7. Шукаю ентузіастів та однодумців, що знаються на Python і хотіли б втілити описані ідеї у життя, і, можливо, навіть зробити сумісний проєкт: Напишіть мені в LinkedIn. На разі працю над PoC який використовує описані принципи у цій статті. Буду радий поділитись своїми напрацюваннями і знаннями.
👍ПодобаєтьсяСподобалось38
До обраногоВ обраному30
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую. Гарна робота. Цікаво. Вчасно. Якраз занурююся в цю тему. Хороший посібник для початківців.

Давайте занурюватись разом, напишіть мені у LinkedIn!

targeterpro.com/UW7

Хороша стаття, але вимагає певного бекграунду зі сторони читача.

Щойно опублікував наступну маленьку статтю фокусовану на конвертації моделей у GGUF формат

dou.ua/forums/topic/49295

Бачив на днях демку для трейдингу. Агенти, лазять по тематичним ресурсам, «дивляться» тематичних ютюберів (ну як транскриптують відео), шукають там торгівельні стратегії, потім пишуть пітон код для реалізації стратегій, потім роблять бектестінг (на минулих даних), і відбирають найбільш вдалі стратегії. Все повністю автоматизовано, можуть протестувати 100+ стратегій в день.

Інша демка, агент маркетолог. Наприклад у вас є todo list і треба впарити. Він лазить по тематичним ресурсам, редітам, шукає топіки де обговорюють тайм менеджмент, todo лісти, і рекламує ваш продукт. Не просто топорно як було до цього коли боти спамять однотипними повідомленнями «спробуйте он цей todo list», а максимально органічно і ненав’язливо, влазять в розмову, підтримують її, і продвигають ваш todo list, типу: а я вот спробував такий туду ліст, і там он ця функція зроблена он так, що набагато краще ніж у конкурентів"

Майбутнє вже тут. Це хто там, Цуцукевич вроді недавно написав про нову парадигму програмування — llm щось там. Люди і бізнеси хто її не освоюють, будуть програвати тим хто освоює.

Бачив на днях демку для трейдингу. Агенти, лазять по тематичним ресурсам, «дивляться» тематичних ютюберів (ну як транскриптують відео), шукають там торгівельні стратегії, потім пишуть пітон код для реалізації стратегій, потім роблять бектестінг (на минулих даних), і відбирають найбільш вдалі стратегії. Все повністю автоматизовано, можуть протестувати 100+ стратегій в день.

Marketing bullshit. Хотів би я подивитися як llm буде готувати данні для тренувального сету і тюнити overfitting моделі на test сеті коли він навіть rule-based programming в умовах максимально визначенних робить вірно без помилок в менш ніж половині кейсів.

Це ж ви яку модель використовували?
symflower.com/...​eness-in-code-generation

По-перше, в меншості випадках, а в останніх моделях типу gpt 4o в 10%
По-друге, з першого проходу, з другого-третьоого разу коректує як треба, особливо якщо вказати на помилку

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

Перечитайте статью, порсьорчать як роблять агентів які виконують специфічні функції з допомогою llm. По власному прикладу, який грався з подібним і перечитав купу топіків, скажу що це реально, важко, але реально, особливо якщо в якості llm щось типу gpt 4o.

Це ж ви яку модель використовували?
symflower.com/...​eness-in-code-generation

Про моделі які мають писати робочий алгоритм, а не java код що просто компілюється(схоже твій приклад саме про це).

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

побудова ші моделей і підготовка данних — залежить не від статистичної імовірності і якості промтингу, а потребує реальних когнітивних здібностей на рівні освідченої людини (чого у llm або будь якого іншого повністю автоматизованого рішення немає) щоб правильно сформувати параметри, щоб знайти потрібні данні з того, що там на ютубі якийсь фін експерт розповідає, підготувати і обробити train set , навіть коли тип моделі відомий на перед, ми ще дуже далекі до повної автоматизації побудови з нічого робочих аі моделей.

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

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

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

Ваша стаття мені здалося взагалі далека від цього прикладу(оглядовий набор інструментів задач рівня побудови чатботів максимум з тими ж агентами). що звучить куди більш приземленно і реалістично, без маркетингової складової для того об продавати/впарювати «повністю самодостатні» рішення з AI .

Будувати або вдосконалювати існуючу модель rag-додатком для цього зовсім не треба.

Це звичайно цікавий і перспективний підхід в дослідницькому ключі, але для отримання ефективних рішень тут і зараз достатньо просто динамічного knowledge-graph в добре продуманій агентній системі.

Грань між RAG та Агентами дуже тонка.
Обидва це високорівневі концепти, набір практик, а не статичний кінцевий дизайн додатку.

Різниця між RAG та Агентом високорівнево у тім, що останній може піти і щось зробити для вас: написати та відправити імейл, створити в календарі івент. В той час як RAG який би розумний не був і де б інформацію не черпав, нічого за вас робити не буде, а тільки поговорить із вами.

Тому казати що не треба будувати «складний» RAG а треба зробити «простий» Агент не вірно.

Технічно кажучи Агент це наворочений RAG, який не тільки «розмовляє» але ще і «робить». І ось тут починається тонка і заплутана грань, а в чому різниця між «робить» і «просто розмовляє» через те що ці дві сутності за їх визначенням це не чітко сформульовані концепти. Чи можна сказати що RAG який іде і витягує із Knowledge Graph інформацію «що він щось робить»? Так можна. Але не варто. Чи стає RAG Агентом від такої роботи? Ні не стає. Тобто RAG точно так само може працювати із Knowledge Graph як і Агент.

Я для себе це так формулюю: поки RAG не записує кудись інформацію він не Агент хоча непевно це не повноцінне формування, краще все ж-таки напевно залишити «виконує/діє». Або можна зробити іншу аналогію: Агент це аналог людини/співробітника, якому можна поставити задачу щоб він виконав, а RAG це інструмент або набір інструментів може наворочений і крутий, але без агенції без сутності що діє (людини чи машини) цей інструмент нічого не робитиме. Прочитав імейл, зробив висновки — це RAG. Прочитав імейл, зробив висновки і відправив відповідь на імейл — це Агент. Під дією чи виконанням не мається на увазі прочитав, подумав чи дав відповідь на задачу, а те що пішов і сам зробив цю задачу. Можна думати скільки завгодно «треба помити машину бо брудна і некрасіво», але від того машина не помиється. Факт того що додаток «простий» чи «складний» теж не означає що RAG став агентом чи навпаки. Відповідно є у додатку використання Knowledge Graph чи нема, не говорить нам що став наш додаток Агентом чи просто RAG бо обидва можуть використовувати будь-які джерела інформації.

Тому я не погоджуюсь із вашим твердженням «Будувати або вдосконалювати існуючу модель rag-додатком для цього зовсім не треба [...] для отримання ефективних рішень тут і зараз достатньо просто динамічного knowledge-graph в добре продуманій агентній системі.»

RAG ніяк не вдосконалює існуючу модель. RAG покращує *результат*, а не саму модель. Процес навчання та fine-tuning моделі це окрема тема до RAG не відноситься, тільки під час навчання чи fine tuning модель насправді чомусь вчиться і щось «запамʼятовує». Модель яка працює через RAG або просто сама LLM модель нічому ніколи не вчиться і нічого не запамʼятовує, навіть спілкуючись мільйон років.

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

RAG ніяк не вдосконалює існуючу модель. RAG покращує *результат*, а не саму модель.

Якщо що, то це саме кейс розробки моделі і використання її для трейдингу, найпростіший наприклад — регрессійної моделі.

Бачив на днях демку для трейдингу. Агенти, лазять по тематичним ресурсам, «дивляться» тематичних ютюберів (ну як транскриптують відео), шукають там торгівельні стратегії, потім пишуть пітон код для реалізації стратегій, потім роблять бектестінг (на минулих даних), і відбирають найбільш вдалі стратегії. Все повністю автоматизовано, можуть протестувати 100+ стратегій в день.

складно уявляю як ви пропонуєте використовувати rag + llm для торгів. хіба що ви сподіваєтесь щось заробити реактивно вводячі новивини llm моделі і запитуючи чи вам вже слід продавати/купувати — але трейдинг так не працює впринципі.

Історія із торгами промайнула один раз і не від мене. Не є суттю цієї статі і не є моєю особистою зацікавленістю. Особисто я не пропонував робити RAG для торгів на біржі. Моя стаття про основні підходи, tools та архітектури RAG. Не маю бажання продовжувати спілкування цю тему. То був просто приклад.

Ви знову неправі просто от по всім пунктам.

Про

когнітивних здібностей на рівні освідченої людини

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

Щодо трейдерських додатків — подивіться, наприклад, хто є основним та єдиним спонсором AI Math Olympiad з призовим фондом в мільйон доларів. Це можливо трошки натякає :)

Щодо трейдерських додатків — подивіться, наприклад, хто є основним та єдиним спонсором AI Math Olympiad з призовим фондом в мільйон доларів. Це можливо трошки натякає :)

я не заперечую використання ші в трейдинг як такого якщо що.

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

це те посилання яке вказує що LLM може майже завжди дати код що скомпілюється і сгенерити якийсь тест на кожний умовний стейтмент в коді? це ж не має нічого спільного навіть з видачею робочої реалізації алгоритму(не кажучи вже про кагнітивну складову) — це ж очевидно.

Я думаю Дмитро ви не зовсім зрозуміли цю статтю. Суть RAG це як раз знайти підхід, хак до будь-якої вузької задачі. В тому числі видачу робочої реалізації алгоритму, і когнітивному складову (щоб ви під цим не розуміли).

Дані вже є, якийсь дамп торгових сессій. Звісно там не все з допомогою llm робиться, якісь дані, скрипти будуть заготовлені руками.

Задача лише:
1. Знайти торгові стратегії з різних джерел, «якщо в такий момент часу таке, то продавай, а якщо таке то купляй»
2. Написати код для цих стратегій
3. Запустити на даних
4. Перевірити результати

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

Неправда, зовсім не marketing bullshit. Працюю зі сценаріями співставної скланості.

він навіть rule-based programming в умовах максимально визначенних робить вірно без помилок в менш ніж половині кейсів

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

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

В цьому і полягає суть RAG додатку: усілякими лайф-хаками покращити результат у вузькому домені.

Неправда, зовсім не marketing bullshit. Працюю зі сценаріями співставної скланості.

ну добре і як успіхи? вдалося переторгувати досвідченого трейдера ну або замінити такого хоч на одному підтвержденному прикладі?

Дмитро, я не хочу захищати усі на світі трейдерські додатки із АІ. Але те що каже Віталій має сенс і може бути реалізовано.

Але те що каже Віталій має сенс і може бути реалізовано.

Що саме? агенти/llm можуть end-to-end замінити людину для торгів?

Я особисто мав на увазі кейси, що приводив пан Дональд Трамп.
Ці сценарії використання мовних моделей насьогодні є цілком життєздатними навіть в рамках дрібних стартапів, не кажучи вже про біг-корп з арміями AI/ML-інженерів.

End-to-end замінити людину для торгів ніхто не казав.

Ага, казали замінити людину end-to-end щоб зібрати стратегії торгові з відео на ютубі, імплементувати і оцінити, щоб замінити людину end-to-end залишилось не дуже багато наче, ні? Але якщо так легче можем подивитись як rag + llm вирішать хоча б такий скоуп end-to-end

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

Як щодо RAG для написання RAG?

От звісно всі зараз кинулись освоювати нове кунгфу, але як повашому скільки протримаються ці навички на ринку?

Ідея до речі прикольна. RAG що пише RAG. До речі це скоріш вже таки не RAG а буде Агент що пише Агент. Може таки вийде Skynet? (Хоча я особисто сильно сумніваюсь) :)

Як на мене ці навички мають протриматись довго, того що у моделей як таких дуже багато приколів і проблем, які або неможливо вилічіти просто навчивши модель (от як наприклад новини, скільки ти не вчи, воно знати новини не може за визначенням) або воно покращується але повністю не вилікується, от як наприклад розмір контексту, він був малий, придумали infini-attention але всеодно у моделі проблеми із увагою і тому всеодно треба додаток-обгортку писати. В АІ сфері звісно що усе зараз міняється просто із неймовірною швидкістю і обіцяти тут щось дуже важко, але принцип RAG/Агента і ці навички як на мене мають протриматись довго. Але ви звісно праві, конкретика дуже швидко поміняється. Тому я намагався сфокусуватись на більш високій архітектурі, дизайнах і принципах в цій статті, а не конкретній реалізації із прикладами.

Та навіть не в скайнет справа

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

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

В принципі логічно. Першими мають попасти під роздачу ті хто найдорожчий із одного боку i там де швидше буде return of investments. Із іншого хтось всеодно це якось має контролювати і що важливо розвивати і відповідно значить не зовсім таки всі. Із іншого боку із недорогими людьми умовно із Індії, там теж є свої нюанси (із якістю, ну і з людьми є усілякі приколи, ми хворіємо, у нас свята, акцент на колцентрі незрозумілий та і взагалі нащо тепер колцентри?), відповідно вони теж не то що захищені. Тож замінити 10.000 індусів на один RAG теж може прийти комусь в голову.

Ну я от чомусь не вірю в автомтизацію саме недорогих професій

В нім та й багато де от в якійсь чебуречній власник запросто касою 20річної давнини може користуватися. Йому той ші глибоко до лампочки

Так само думаю до лампочки якимсь майкрософтам чи гуглам вартість якогось білкового програміста на спрінг емвісі — навпаки якраз замінити таких буде мати супутні ризики

А от дефіцитного моднемолодьожного ші-спеціаліста з хай глибоковузькими але легко автоматизованими скілами — запросто

не вартість фактор тут, а скоріше дефіцитність

І з іншого боку щоб розвивати ші з розмахом, треба щоб ші розвивав себе за допомогою ші-інструментів, і саме туди підуть перші інвестиції

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

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

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

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

Арт мертвий в 21 сторіччі. Ніхто не вміє вже ні малювати, ні писати ні співати. Все вже робиться на компʼютері. Залишилось декілька динозаврів. Щось я чесно кажучі не вірю що більшість мистиців за наявність душі будуть заробляти більше ніж бездушна модель яка може робити теж саме тільки краще і швидше, і ще із маркетинговим дослідженням щоб воно ще краще продавалось.
Арт мертвий. Немає більше його. Будь-яке мистецтво воно народжується щоби перерости в технологію. Цей момент вже настав. Видно по тому що більше вже ніхто не намалює так як Караваджо, ніхто не співатиме як Пласідо Домінго, ніхто не напише музику вже як Вівальді, ніхто не напише твору як Р. Р. Толкін. Навіть якщо хтось і зробить щось як ці люди, їх вже будуть порівнювати із існуючими, не можна пригнути вище голови i рости далі. Тому арт пішов стежкою намазюкати за 15 хвилин носом чи іншою частиною тіла красками купленими в супермаркеті на холсті купленому на eBay і сказати «а я так бачу» чи «а що ви тут бачите?». Ніхто вже із метрами не може боротись бо це довго і тяжко, на руках мозолі, а всі хочуть швидко. Або купить дорогущій фотоапарат із мільйонами мега пікселів та лінзами зробленими в Японії на заводі, фоткать Ейфелеву вежу із усіх можливих кутів. Це арт? Це вже технологія. І те саме із піснею і фільмом і всим. Арт повністю переріс в технологію. Тому я кажу арт мертвий. І ніяка душа творця вже не допоможе.

Арт мертвий.

You can’t kill the metal, metal will live on

Але написав ти це все дуже натхненно.

Але я і не претендую на роль письменника.

Дякую за таку змістовну статтю!

Опублікував англійською мовою огляд опенсорс утілити як через чат працювати із БД. Запит користувача конвертується в SQL. Сподіваюсь вам буде корисно.
medium.com/...​e-good-stuff-e4d57c0c181c

Хороша стаття, не зваєжаючи на нюанси по базовим поняттям (але це продукт сучасної епідемії діпльонінга). Розбирати малі неточності не хочется, зупинюсь тільки на онтологіях. У поясненнях що до онтологій багато хто робить цю помилку, починаючи розбирати її як звязок ноди-відношення, хоча це по суті опис first order logic, чи взагалі якась реляційна або об’єктна модель даних. А онтології це поння зовсім іншого порядку.

Задача онтології — це представлення області знань у символьному вигляді так, щоб до них можна було примінити:
1) модель логіки
2) різонінг

І саме reasoning тут відіграє головну роль. Спочатку треба запам’ятати, що онтології це інструмент репрезентації знань. У вас як у людини в голові є картинка навколишнього світу, котра педставлена у вигляді абстрактних понять, образів, звязків — знання. Ви можете зання отримувати з оточуючого світу, змінювати, генерувати нові. Дослідники AI у своїй меті зробити штучний розум, б’ються з проблемою, а як саме представити знання світу/середовища у «голові» машини, так щоб вона цей світ «розуміти» — зберігати, використовувати та генерувати нові знання на основі старих. (Далі повинен був бути довгий текст про символьне представлення знань, моделі логіки, крутість професорів KRR, але лінь і воно трохи не в тему).

Онтологія це набір знань у якомусь зрозумілому машині вигляді, достатній для вирішення задач, під які цю машина зробили. Класи, атрибути, ентіті, звязки — схоже на OOP, але на движку логіки. Онтологію може з’їсти спеціальна фігня, яку називають «різонер» — інтерпретатор на основі конкретної моделі логіки (моделей логіки багато). Різонер дозволяє робити комплексні запити по знанням, які представлені в онтології, з метою отримання та генерації нових знань.
І да, оці LLM мають... ніякого відношення вони не мають до знань і логіки. В ідеальному світі LM хотіли годувати даними закодованими моделями логіки, онтологіями, але Deep Learning за допомогою Big Data зробив це швидше. І якщо під певні задачі, типу обробка зображень, чи звуку, це найкращий підхід наразі, язикові моделі, не дивлячісь на зовнішньо крутий результат, задачі логіки вирішують з великими проблемами. Так, RAG ситуацію покращує, але фундаментально нічого не міняє. І агенти (Intelligence Agents) це взагалі не про це.

А так в цілому дуже цікавий матеріал.

а як саме представити знання світу/середовища у «голові» машини

...і для цього робились експертні системи

«різонер» — інтерпретатор на основі конкретної моделі логіки (моделей логіки багато)

а це пробували на LISP / Prolog

ну і OWL (англ. Web Ontology Language)
uk.wikipedia.org/...​iki/Web_Ontology_Language

В ідеальному світі LM хотіли годувати даними закодованими моделями логіки, онтологіями, але Deep Learning за допомогою Big Data зробив це швидше

Саме так.
Як десь зустрів, вислів одного профессора з MIT
(зміст по пам’яті)
Ми з сусіднью кафедрою змагаєсь з 70их. Ми підходимо аналітично, вони пробують тупо запхати в комп’ютер щось. Беремо якусь проблему, стартуємо, І... вони постійно нас випереджають у практичних результатах...

задачі логіки вирішують з великими проблемами

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

RAG ситуацію покращує, але фундаментально нічого не міняє

Це треба навіть не для покращення, а взагалі:
задати контекст — любому геніальному інтелекту.
Контекст не може покращити можливості інтелекту.
Але без контекста інтелект буде думати над «сферичними конями у вакуумі».

але краще за середню людину, в чималій кількості областей знання.

мій викладач KRR за такий statement розіп’яв би мене на хресті і змісив би писати академічний репорт, чому це не так :)

давайте не порівнювати логіку з набором текстів
лінь лізти в google scholar, але там є декілька прикладів, як LLM тренували на посібниках з логіки, і результат був на рівні 30-50% вірних відповідей

LLM це про купу тексту, яка була оброблена, і як результати отримана вірогіднісна модель, яка показує вирогідність, з якою за нобором слів буде йти наступний набір слів. Які тексти дали, такі «знання» і отримали.
Якщо в текстах частіше було «Бєлгород — російське місто», то машина вам «відповідає» те саме тільки тому, що воно частіше зустрічалось. Якщо розбавити тексти фразою «Білгород — українське місто», то і результат ви отримаєте інший. При чому який саме результат ви отримаєте не буде залежати від набору юридичних чи літаратурних текстів, тільки те що пов’язано саме з цим твердженням. Машина не може зробити висновок, вона може показати результат обробки з вирогідністю. Людина може проаналізувати знання, зробити висновки, що місто Білгород належіть Україні навіть якщо в текстах частіше зустрічається що він російський. Людина може мати, обробляти, генерувати нові знання і навіть валідувати їх орієнтуючись на закони логіки.
LLM зараз імітує дитину в школі — компіляція текстів з підручників у пам’яті є, а навички робити висновки ще нема. І те що ви називаєте «знаннями» залежить виглючно від частоти з якою зустрічаються ті чі інши слова, а не фактичними знаннями, які вони кодують.

Бєлгород руский город
Бєлгород руский город
Бєлгород руский город
Так каже русня
Русня завжди бреше
Білгород — це Україна

Для LLM «Бєлгород руский город» має більшу вагу.
Для будь якої моделі логіки це пльова задача з єдиним висновком.

Дійсно, якщо порівнювати тексти які генерить середня людина і середній GPT, може скластися враження, що LLM знають все, а люди у більшості тупі. Але це не так. Люди просто менше знань в голові тримають, і взагалі-то без певних тренувань генерувати текст на основі знань не так вже й просто.

“Yet, general-purpose LLMs are designed to hallucinate, because they are trained to reduce the average error across the examples they’ve seen. They’re pretty good at everything, but perfect at nothing.They can produce fluent English prose because they’ve seen so much of it across the internet, but specific facts—like a date, a revenue number, or a variable name—get muddled in probabilities. As a result, companies have not been able to count on LLMs for the most critical and most valuable use cases — until now.” Дуже гарно як на мене описано про LLM та їх родовід, що вони можуть чого не можуть і звідки ноги ростуть, відповідно чого від них чекати.

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

Підкажіть які би ви підходи та практики використовували для конвертації тексту в Knowledge Graph?

NLP трохи не моя парафія, тому мою думку прошу не вважати експертною

Натягувати структуровані знання на існуючі LLM це таке собі задоволення. Хоча хто зна... тест Т’юрінга теж он думали, що без моделі знань комп’ютер не зможе.

Чисто теоретично, треба починати з того, який саме текст, яка мова, які топіки, які задачі треба вирішувати. Проводити якійсь exploratory data analysis.

Для англійської з її структурою нормально підійде Linguistic Analysis, як мінімум там є норм теоретична база і понаписано багато чого готового. Переганяти тексти у структурні формати згідно лінгвістичному аналізу. Знов проводити exploratory data analysis (вважаю для невеликих областей знань це реально). Якщо задача вузька, то можна навіть спробувати зробити онтологію, і вже на її базі маючи готовий формат, думати як і де це все зберігати. І ось на цьому вже якось намагатись тренувати LLM. І використовувати як контекст не токени, а онтології. Навіть вже не LLM для навчання брати, діпльонінгу ж не буде, фічі ми вже отримали. Хоча не факт — отримані структури можуть кодувати знання по різному, можливо deep learning дозволить отримати якісь свої нові комплексні фічі, всі будуть нити що знов не розуміють логіки нейронок, нові дослідження... і так на всі гроші.
Може зроблять якусь математику для нейронів, щоб і градієнт, і помилка через онтологію та лексичний аналіз. Зроблять нові слої у нейронку, як було з convolution, і оnримають непоганий feature extraction підкріплений логікою. Далі дело техніки.

Звісно, це все припущення. Думаю, OpenAI та інші дослідники над цим вже працювали/працюють, і ми могли б побачити якісь результати, але нічого суттєвого в літературі не зустрічав (чесно кажучі, не дуже і шукав). Якщо хтось щось бачив цікаве — поділіться.

Натягувати структуровані знання на існуючі LLM це таке собі задоволення.

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

Для англійської з її структурою нормально підійде Linguistic Analysis, як мінімум там є норм теоретична база і понаписано багато чого готового.

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

Якщо задача вузька, то можна навіть спробувати зробити онтологію

І що заважало те робити?

І використовувати як контекст не токени, а онтології.

Або нехай комп’ютер їх робить, бо чогось з ними проблема у людей :)

Зроблять нові слої у нейронку, як було з convolution, і оnримають непоганий feature extraction підкріплений логікою

Так в свіжій доповіді Курцвейла щось такє і є
Нейромежі будуть створювати більш складні нейромережі.

Звісно це припущення.
Але й диво LLM в тому і є
Десятиліття люди пробували аналітично, тим шляхом що ви написали.
І оп, виявилось що «тупий» шлях привів до більш вражаючих результатів.

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

Взяли шкільну сумку, напхали книжок, і базнули по голові першокласника. І він оп — третьокласником став.

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

Або нехай комп’ютер їх робить, бо чогось з ними проблема у людей :)

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

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

Якщо ми про епоху ML, то це називається reinforcement learning, і під цим така ж математика, як під іншими видами ML. Просто дані беруться не з датасету, а з оточення.

Третьокласником с феноменальною памяттю, який не здавав іспити, і який просто формально пам’ятає як написано в підручниках

ну так, він же третьокласник.
я ж про метод.
«А от як і його ми голові луснимо — стане п’ятикласником?» а як п’ятикласника?

Він не розуміє суті теореми Піфагора

Ну так, не розуміє. Більшість людей теж не розуміє.
Першокласник — теж не розуміє :) І більшість його однакласників — ніколи не зрозуміють.

і може пересказати її 5тьма різними способами як написано в 5 різніх підручниках

Так. Але з цього не можна зробити висновок, що коли опанує 6ий спосіб, то знову не з’явиться розуміння. Ми — не знаємо.

В тому то і річ — це те, що комп’ютер не може фізично.

Чому не може фізично :) До чого тут — фізично.

Він може зробити текстовий опис онтології,

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

і під цим така ж математика, як під іншими видами ML

Хімія і електрика нейронів ніяк не пояснює — результати людського мислення :)

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

" Бо ми, люди, робимо такі описи, створюємо онтології бо наші мізки — фізично не можуть оперувати великими об’ємами без абстрагування.
[...]
І вважати що той спосіб мислення який ми знаємо — єдиний і найкращий" погоджуюсь на 100%

А в чому ваша спеціалізація, що би ви могли із своєї спеціалізації порекомендувати чи поділитись досвідом на цю тему?

Зрозумів. Чи могли би ви із своєї колокольні поділитись досвідом на тему RAG/Agents та LLM?

Просити конвертувати текст в Knowledge Graph в лоб, аугументувавши промпт детальними інструкціями щодо knowledge graph.

7B моделі ймовірно цю задачу провалять, але моделі рівня GPT4+ справляться.

Якщо якість результатів буде занизька — беремо багато генерацій і вводимо додатковий крок ранжування/валідації генерацій для вибору найкращого результату (можна реалізувати дуже по різному, це окремий цікавий напрямок).

Якщо тексти сильно більше 1 речення, розбивати але акуратно підібрати методику чанкінгу, щоб не розривати сильно зв’язані конструкції (ймовірно добре підійде семантичний чанкінг, може розбиття по реченням, якщо по абзацам — моя інтуїція каже шо то вже може бути забагато для якісного результату, в залежності від моделі і розмірів абзаців).

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

Ну і само собою, об’єднання підграфів — окремим кроком, якщо ми розбиваєм.

Пробували щось подібне, маєте такі задачі?

Тут же все дуже залежить від вашого бачення та структури Knowledge Graph: Що є ребрами і вузлами? Вузли це окремі поняття (як в онтології), окремі факти, чи більші структури?

і змісив би писати академічний репорт, чому це не так :)

Зустрічав чимало досліджень на цю тему, про людей :)
Ну а на співбесідах бува теж, і навіть ми програмісти — глючимо.
Була колись така мода, логічні задачі давати на співбесідах.

LLM це про купу тексту, яка була оброблена, і як результати отримана вірогіднісна модель,

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

Якщо в текстах частіше було «Бєлгород — російське місто», то машина вам «відповідає» те саме тільки тому

Як і людина, так. Навіть є такє когнитивне упередження.

Якщо розбавити тексти фразою «Білгород — українське місто», то і результат ви отримаєте інший

Так. Бо LLM сама по собі нічого не знає про емпирічні факти.

Людина може мати, обробляти, генерувати нові знання і навіть валідувати їх орієнтуючись на закони логіки.

Не на закони логіки, а насамперед на когнитивні упередження, роботу лімбичної системи, та «захардкожені» стереотипи.
Ви дуже перебільшуєте, наші, людей можливості.

Демагогія — головний інструмент впливу на людей. А не логіка :)

LLM зараз імітує дитину в школі — компіляція текстів з підручників у пам’яті є, а навички робити висновки ще нема

problem-solving- робить.
Ніхто не каже що прямо супер, але якось ви не дивились дослідження на цю тему, чи що...

Для LLM «Бєлгород руский город» має більшу вагу.

Бо знову ж
ви плутаєте логіку і емпиріку.
Бєлгород руский город — це емпирічний факт.

Міськи діти так само вважають що корови фіолетові. Бо так на мілки вей намальовано, а живих не бачили.

Дійсно, якщо порівнювати тексти які генерить середня людина і середній GPT, може скластися враження

Давайте по іншому переформулюю

Програми в шахи грають краще любої людини.
І більш нічого не вміють.

LLM вже купу всього вміє краще середньої людини.
Ой далеко не все, ой далеко не завжди краще.
Але — набагато більше і краще ніж шахова програма.
Хоча, у шахової програми LLM не виграє.

Але й більшість людей грає у шахи нижче мінімального у нас 4го розряду :)

а люди у більшості тупі. Але це не так.

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

Люди просто менше знань в голові тримають

Ви знову плутаєте логіку та емпиріку.

Про пусті знання навіть у людей є образливе про когось:
Ерудит — то пил з книжок засипаний у пустий череп.

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

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

Людина (навіть дуже тупа) використовує інструменти логіки(в перні періоди часу, коли рішення сфокусоване) — робить ствердження, аналізує(індуктивний, дедуктивний,інші), робить висновки (різонінг). Нехай косо, криво, з помилками, але зараз мова не про те. Не можна порівнювати як це робить людина і машина, тому що ми не кінця розумієм як це мозок опрацьовує. Але якщо спрощувати — людина здатна на різонінг, тому що мозок має якісь свої символічні дані, і інструменти обробки. LLM цього не має. В ланцюжку інтелект->KRR->IA->ML язикові моделі це ML, який базується на статистичному аналізі тексту. Не знать. У людини в голові не текст і навіть не таблиця weights для текстів. LLM це про тексти, а не про логіку.

LLM вже купу всього вміє краще середньої людини.

Я б спростив це до «LLM обробили більше інформації, ніж людина може тримати в голові».
У LLM більше текстової інформації. Так, структурованої, академічної. І воно це може показувати на екрані і тому ж вигляді, як це зробили багато мільонів людей, переклавши знання у текст.

бо кажу про логіку наукову, яка базується на ствердженнях, фактах і тд — суха наука.

Значить таки плутаєте.
Бо логіка і факти — це і є незалежні речі.
В сухій науці — особливо :)

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

Ну так це тоді проблема яка дискутується в філософії математики, якщо хочемо бути близькими до «наукової логіки».

Людина (навіть дуже тупа) використовує інструменти логіки(в перні періоди часу, коли рішення сфокусоване) — робить ствердження, аналізує(індуктивний, дедуктивний,інші), робить висновки (різонінг)

І ці висновкі більшою частиною — помилкові щодо емпірики :)

Не можна порівнювати як це робить людина і машина,

Чому не можна?
От людина рахує — і калькулятор рахує.
Чому не можна порівнювати вміння рахувати людини і калькулятора?

тому що мозок має якісь свої символічні дані, і інструменти обробки

Ну так, мозок людини працює зовсім по іншому, аніж любий ШІ.
А чому не можна порівнювати результати їх роботи?

який базується на статистичному аналізі тексту

Ну так. Бо
Людина так не може вчитись. Мозок заслабкий.
Людина не може навчити комп’ютер як вона вчить інших людей. Тому треба інший метод, наприклад «статистичний».

У людини в голові не текст і навіть не таблиця weights для текстів. LLM це про тексти, а не про логіку.

Про китайську кімнату Серла чули ж мабуть.

Яка різниця що там в голові у кого.

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

То якщо ШІ зможе щось набагато краще робити, і так і не навчитись у чисту логіку — то й що з того що він те навчився «на купі текстів і таблиць weights».

Результат — от що цікаво. А не то хто, де як, чому вчився :)

LLM обробили більше інформації, ніж людина може тримати в голові

ОК.
А от ніяка людина не може так і близько.
Вже бачимо — перевагу у ШІ.

Я про те — які фундаментальні причини забороняють ШІ стати ще крутішим?
Фізичні — кількість електроенергії, влитих капіталів — так, може заморозити подальший розвиток.

Але фундаментальні — які?
Підказую — вони не відомі, тому що людство і своє власне мислення ще дуже погано розуміє.
І не мало досвіда — порівняти.

мій викладач KRR за такий statement розіп’яв би мене на хресті і змісив би писати академічний репорт, чому це не так :)

То став би ти Ісусом від AI =)

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

Претензія до такого формулювання самої проблеми звісно є. Метафорично її можна озаглавити як «коні і люди»:
Апелювання до надмірно антропоморфічного архетипу штучного інтелекту в самій постановці запитання (порівняння з середньою людиною) виносить його з академічного дискурсу в художньо-наративний, а отже писати такий репорт було б справою, ймовірно благородною, але точно невдячною :D

Ми можемо про це говорити вічніть, якщо розмовляти різними мовами.
Стверджувати, що LLM вирішують певні задачі логіки взагалі невірно, тому що в них відсутня частина, яка за це відповідає — різонер. В них є частина, яка на цю тему "галюцінує"("імітує") — ANN. Причому галюцінує вона згідно тих текстових наборів даних, на якиї навчалась. Дещо вгадує, дещо ні. Що до ефективності, то це вже добре досліджено:

doi.org/10.48550/arXiv.2401.0075

Our research demonstrated the efficacy of LogicAsker in identifying logical reasoning failures in a diverse set of widely deployed
LLMs, we achieved a substantial success rate in revealing reasoning
flaws in these models, ranging from 25% to 94%. Additionally, we
utilized the test cases from LogicAsker to design in-context learning
demonstrations, which effectively enhance the logical reasoning
capabilities of LLMs, e.g., improving from 75% to 85% for GPT-4.

doi.org/...​10.48550/arXiv.2401.09042

Our results show that when using standard natural language
prompting, the relational reasoning ability of LLMs’ in-context fewshot prompting is generally far from satisfaction compared with
the program induction model which is much smaller in size. While
the LLMs with large context window present consistent or even
improved IID performance on the general graph reasoning tasks.
And we further show that the current state-of-the-art prompting
technique is not generally effective for improving LLMs’ relational
reasoning ability.

doi.org/...​10.48550/arXiv.2402.11442

Our evaluations using a subset of
ULogic show that even advanced models like GPT4 struggle with compositional and structural complex rules and exhibit certain biases. Furthermore,
we distill ULogic into a smaller inference engine
that performs well in generating inferential rules
and benefit downstream reasoning tasks. Our work
points out where LLMs need to improve in logical
reasoning and offers a pathway to enhance their
reasoning capabilities.

doi.org/...​10.48550/arXiv.2404.15522

Our evaluations using a subset of
ULogic show that even advanced models like GPT4 struggle with compositional and structural complex rules and exhibit certain biases. Furthermore,
we distill ULogic into a smaller inference engine
that performs well in generating inferential rules
and benefit downstream reasoning tasks. Our work
points out where LLMs need to improve in logical
reasoning and offers a pathway to enhance their
reasoning capabilities.

Поки мова йде про покращення певними підходами: контекст, окремі датасети, і тд.

вибачаюсь, промазав з останнім посиланням

In this work, we evaluated the logical reasoning
ability of LLMs on 25 distinct inference rules and
reasoning patterns covering PL, FOL, and NM
logics. To this end, we introduced LogicBench,
a natural language question-answering dataset focusing on evaluating a single inference rule. We
devised two tasks using LogicBench: (i) BQA, and
(ii) MCQA. We evaluated a range of LLMs including GPT-4, ChatGPT, Gemini-Pro, Llama-2, and
Mistral on both tasks. Experimental results showed
that LLMs do not perform well on LogicBench,
even though they require the application of only a
single inference rule. Furthermore, we also augmented LogicBench to LogicBench(Aug), which
can be utilized for training purposes. Using LogicBench(Aug), we demonstrated that LLMs trained
using it showcase an improved understanding of
logical reasoning, resulting in a better performance
on existing logic datasets.

Мені здається що проблему із логікою LLM якщо не вирішити то суттєво покращити має інтеграція RAG із Graph Database, за умови що там звісно буде зберігатись необхідна бізнес логіка фрагменти якої будуть надаватись як контекст.

Думаю що навряд чи, коли мова про чисту логіку. То як з математикою, краще щоб LLM пересилала спец енжину, або писала код на пайтоні.

А для логічних задач — писала код для Prolog :)

Хоча люли так рідко користуються що математикою, що логікою, що не критично.

LLM то «частина мозку». Як і в нас, активність зон мозку залежить від задач що вирішуються.
Дуже важлива частина, якої не вистачало. Купа інших «частин мозку ШІ» вже є, але були марними без LLM

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

Ви в приблизно вірному напрямку подумали.

Окрім ML, штучний інтелект вивчає і питання моделей знанть і логіки, і «розумні агенти», і мультиагентні системи. Це саме той високий рівень, який вирішує проблеми, які ви хотіли вирішувати «спец енжином»

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

Так, LLM це неточний інструмент зберігання знань. Наприклад, юридична практика показала, що ChatGPT бреше про прецеденти, створюючі свої, і дуже часто не вірно приймає рішення. LLM не розуміє, які дані можна комбінувати, які треба залишати незмінними, тому що вона по своїй природі не може цього розуміти. Вона не вміє розуміти. Те ж саме про посилання. Спробуйте запитати references до відповіді, і насолоджуйтесь, як воно створює нові істочники, комбінуючі імена різних авторів. Прийнанні, раніше так було. (UPD: Звісно, це такі собі приклади, якщо за наукою, то досліджень про це не мало, зможете знайти)

Скоріш за все для створення чогось схожого на мозок потрібна мультиагентна система, з різними моделями і архітектурами, з нормальним протоколом комунікації (типу як старий перевірений KQML), і з грамотно организованим процесом передачі знань (а не текстової інформації). Є керуючі агенти, є ті хто по ML, LLM, і тд. IA невід’ємна частина науки про AI.

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

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

Розуміння в тому сенсі, в котрому ви маєте його на увазі якось можна виміряти? :)

Я маю на увазі розуміння в сенсі існування у системи хоч якогось логічного апарату: 1) символьного предсталення знань, 2) моделі логіки, 3) різонінга. Це як на сьогодні наука розуміє рішення репрезентації знань. Виміряти, звісно, можна. Його [розуміння] інструмент або є, або його нема. Тобто символьне представлення знань в «зрозумілому» системі вигляді або є, або його нема. Модель логіки або використовується, або ні. Система або генерує нові знання (саме у символьному вигляді), або ні. Так, це не всі умови існування розуміння, але необхідні інструменти. Звісно, це дуже спрощена відповідь. Ми тут одним реченням криво описуємо те, про що цілі команди дисертації пишуть.

тест Тюрінга насправді пройшла система, а не людина в кімнаті

Важливо згадати і саму відповідь Серля на це:

Searle’s response to the Systems Reply is simple: in principle, he could internalize the entire system, memorizing all the instructions and the database, and doing all the calculations in his head. He could then leave the room and wander outdoors, perhaps even conversing in Chinese. But he still would have no way to attach «any meaning to the formal symbols». The man would now be the entire system, yet he still would not understand Chinese. For example, he would not know the meaning of the Chinese word for hamburger. He still cannot get semantics from syntax.

Окрім того, тест Тʼюрінга це лише один з підходів. У світі AI дослідники досі не визначились з humanly vs rationally та think vs act, тому використовують всі чотири підходи: мислити як людина, мислити раціонально, діяти як людина, діяти раціонально. Але тут доведеться відкрити портал у Пекло, тому на цьому і зупинимось :)

Окей.

1) Як в вашому мозку символьно представлені знання? Закріплені за певними нейронами та зонами кори головного мозку? LLM мають якусь принципову відмінність в цьому плані? Вам щось заважає побудувати аналогію між зонами кори головного мозку і зонами латентного простору моделі, в яких стаються сплески активності під час обробки певних символів?

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

У вас в профілі написано AI, і ви таке питаєте?

Як в вашому мозку символьно представлені знання? Закріплені за певними нейронами та зонами кори головного мозку? LLM мають якусь принципову відмінність в цьому плані?

Знання, наскільки ми розумієм це зараз, закріплені у вигляді нейромереж. Причому, окремі зони відповідають за окремі види інформації, плюс мають складні звязки. Ще емпірично встановлено, що у рамказ зон знання категоризуються по наборам характеристик. Знання про окрему сутність/категорію представлені у вигляді складних образів з різних зон, наше уявлення і розуміння — мультиплікація різних уявлень у вигляді різних типів інформації — зір, слух, текст, і тд. А ще на це все впливає багато різних біохімічних механізмів, типу гормонів, неролептиків, маркерів і тд. Плюс свідоме/несвідоме, механізм «розуміння».

В штучних нейронних мережах «знання» представлені у вигляді тексту закодованого у weights + biases. «Знання» не зберігаються в окремих зонах чи чомусь такому, вони відразу у всії нейронній мережі. Відповідь не регулюється нічим, окрім вхідної інформації. Някого свідомого, ніякого розуміння.

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

Вам щось заважає побудувати аналогію між зонами кори головного мозку і зонами латентного простору моделі, в яких стаються сплески активності під час обробки певних символів?

Якщо дуже спрощувати, то можна сказати, що поїзд це літак.
Відповідь на це вище.

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

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

У вас в профілі написано AI, і ви таке питаєте?

Це було риторичне запитання, що мало б вас підвести до протиріччя в

Я маю на увазі розуміння в сенсі існування у системи хоч якогось логічного апарату: 1) символьного предсталення знань, 2) моделі логіки, 3) різонінга

Розуміння вже було концепцією, що була загальновживаною по відношенню до людей, коли теорій функціонування мозку, про які ви кажете, ще не існувало. І мозок і LLM — чорні коробочки. Розуміння — це початково квалія, а не структурно-описове поняття.
Воно не залежить від способу, котрим воно досягається чи структури піддослідного об’єкту.
Точно так же як «здатність вирішувати логічні задачі» — це метрика, взята з результатів, а не факт наявності певних компонентів.

Той сенс, що ви вкладаєте в це поняття, не є загальновживаним і звідси виникають ті позиції, по яким ми не згодні.

the relational reasoning ability of LLMs’ in-context fewshot prompting is generally far from satisfaction compared with
the program induction model

Бенчмарк хороший, висновки ні (І так очевидно, що результати Casual LLM будуть значно гірші за результати дуже маленької спеціалізованої моделі).

Я б зробив ставку на те, що репрезантативна вибірка людей-респондентів з IQ середнього рівня на цьому бенчмарку навряд-чи набере більше за GPT4.

Ото й я кажу. За життя в мене набралось логічних задачок, простих, але в яких емпирічне знання збиває з пантелику, і більшість людей тому робить логічні помилки.
Перевіряв і 3.5,і 4 ще. А він не збивається, і логічно все розкладає. Тобто він «знає» різницю між логікою та емпирікою, коли робить завдання.
Навіть 3.5, 4 краще.
Складні, де багато кроків треба зробити, так тупить. Правда більшість людей теж не один десяток хвилин буде вирішувати, з олівцем і аркушом.

Перевіряв і на застосування абстрактних знань, тіпа от речення, що в ньому підмет що присудок.

Скептики чекають від ШІ геніальності. А я вважаю що головне — щоб середню людину перевищував у якихось аспектах інтелекту. Не треба навіть щоб у всіх.
Генії, таланти хай собі будуть і далі незамінними — людьми. Їх багато і не треба людству, щоб мало сенс «клонувати» .

Маю думку, що таким же чином як сумарна складність цивілізації суттєво перевищує те, що може осягнути середня людина, границі практично досяжної ефективності інтелектуальної роботи, виконуємої штучним інтелектом сьогодні, встановлюються композицією LLM-based агентів, що можуть мати абсолютно посередні reasoning capabilities. Якщо розглядати розвиток AI в контексті актуальних мовних моделей, звісно.

А ці мовні моделі народжують нову парадигму програмування, що лежить в композиції природномовних інструкцій, семантичних функцій високого рівня та оперування даними на принципово іншому рівні абстракції. Базові вентелі цієї парадигми, такі як llm inference, semantic search & similarity ranking, методики промптінгу накшталт ToT, Cot, Self-Reflection, etc розроблюються, систематизуються та впроваджуються просто сьогодні.

Майбутнї проєкти, що будуть мати резонанс в контексті сильного ШІ, ймовірно будуть побудовані просто як композиція всього того, що в нас вже зараз є навколо мовних та інших генеративних моделей. Просто чекаємо, в яку ШІ-корпорацію завезуть талановитіших вчених-когнітивістів, що мають відповідні компетенції і в computer science / ML (це питання інвестицій та цілепокладання).

Так, повністю згоден.

Я навожу такий приклад
Мало хто знає, що першим 100 км/г подолав — електромобіль.
Але — ДВЗ переміг глобально на десятиліття бо не було потрібних акумів.
Тепер — є.

...тепер є — LLM

arxiv.org/pdf/2402.11442

Отже, на різних тестах умовні індуси з Amazon Mechanical Turok показали на 10-20% кращі результати, ніж GPT4.

Якщо екстраполювати прогрес в наступних GPT4-Turbo і GPT4o, то можна припустити, що цей розрив, що сам по собі не такий вже й великий, вже суттєво скорочено, якщо не подолано.

Крім того, виконавці на Amazon Mechanical Turok, по очевидним причинам, мали б бути індивідами зі значно вищим IQ, ніж в «середньої людини».

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

arxiv.org/pdf/2404.15522

We hired three graduate student volunteers

Випускники університету Арізони вельми ймовірно мають значно вищий за середній IQ.
Не дивлячись на це, застарівша GPT-4 модель порвала їх в найскладнішій категорії цього, як називають його автори, систематичного оцінювання здатності до логчного міркування, а саме MCQA NM.
Увага, висновки авторів:
Experimental results showed that LLMs do not perform well on LogicBench

:)

Знов ви про змагання людини та LLM. Як би пояснити...Це блін те саме що порівнювати літак і поїзд. Так, вони можуть попасти з «А» у «В», але літак прилетить, а поїзд приїде. У різний час, по різному. Для деяких задач транспортування вирішать це питання зі схожим результатом. Використання моделі логіки — політ, верогідністна модель побудована на ANN — ізда залізицею. Це два різні процеси, кожен зі своїми особливостями, плюсами, мінусами, витратами. Ви зараз говорите, що поїзд так же прилітає у пункт «В», як літак. Я вам кажу, що ні, літаки літають, поїзди їздять. Це різні процеси і архітектури, різні принципи. Ви кажете, що якщо і те і те може дістатись з А у В, то це те саме, або дуже схоже, і діє схоже. Ніт, процеси різні. Поки ви поїзду не зробите крила і не змусите літати, він буде поїздом. І поїзд, поки він не літає, не зможе наздогнати літак у якостях польоту. Там само, як літак не довезе майже всюди, куди може доїхати поїзд.

Розумію, що дивлячись на результати, дуже важко прийняти, що у LLM фізично не може бути моделі логіки. Логіка може бути між символами у тексті, на яких воно навчалось. Дай йому хибний текст, і воно покаже хибну послідовність символів. Дай текст побудований на моделі логіки, і воно відповідно буде відповідати точніше. На чому тренували, те і отримали. Це такий собі neural style transfer але для LLM. Якщо зафайнтюнити на існуючих моделях логіки, воно дає кращий результат, тому що набір фіч у датасеті підібраний під задачу. Ми переробили салон поїзда, щоб він виглядав як салон літака. Переставили на магніти, щоб швидше їхав. З середини може виглядати як літак і відчуття схожі. Але це lва різні види транспорту на різних принципах.

І, доречі, про логіку: нормально побудована онтологія дає 100% точність результату на будь якій програмній реалізації різонера. З нульовими витратами (окрім часу спеціалістів на створення онтології).

Я трохи не зрозумів.Як саме ви пропонуєте прикрутити онтологію?

Я це питання трошки розкрив в іншій відповіді.
Коротко — мультиагентні архітектури.

А можна посилання будь-ласка? Бо я не бачу у якій відповіді ви це розкрили.

окрім часу спеціалістів на створення онтології).

Лінгвисти витратили не одне десятиліття на створення систем машинного перекладу.
результат же кращий зараз показують нейромережі.

«Створити нормальну онтологію» — вкрай довга історія. Немає її, нормальної, для купи важливих речей.

Але це два різні види транспорту на різних принципах.

А то пофік, коли задача попасти з А в Б.

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

Логіка може бути між символами у тексті, на яких воно навчалось

LLM показують що встановили логіку не між символами, а між — сенсами.

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

Раціональне ж — та то не цікаво, бо воно легше піддається формалізації.

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

Дивно ж, а тому корисно те що до цього ніщо і ніхто не вмів.

А можна посилання на дослідження психологів? Цікаво почитати.

Не копив. За час з виходу у 22ому — багато зустрічав, різними колективами, з різними коментарями.
Цікаві й тести для оцінки розвитку дітей, коли треба
1. Поставити себе на місце іншого. «що б я відчував на його місці»
2. Поставити іншого на його місце. Що б інший, з іншими ніж в мене рисами характеру і т.і. відчував (цей тест і чимало дорослих не проходять).
Різниця між 1 і 2
Що б я робив на місці Путіна у ситуації Х
Що Путін робитиме на своєму місці у ситуації Х :)
Але там просто, можете й самі перевірити, взяти щось з сайтів психологів, переформулювати і розпитати чатгпт.

Або взагалі про своє, як з психотерапевтом поспілкуватися :)

«Створити нормальну онтологію» — вкрай довга історія. Немає її, нормальної, для купи важливих речей.

Так от, пан @Max апелює до відсутності умовного «reasoner» в архітектурі LLM, потім каже, що нормально побудована онтологія дає 100% точність результату на будь якій програмній реалізації різонера.

А тепер слідкуєм за пальцями і розмірковуєм далі: LLM вирішують задачу побудови онтології. Простий програмний різонер дає 100% точність над точністю самої онтології. Виходить, що інтелектуальна робота (Reasoning) такої ШІ системи завдячує в першу чергу мовній моделі, а не примітивному reasoning алгоритму над онтологією :D

Особливо вражають експерименти психологів з моделями без цензури

Десь була (нажаль не знайду посилання) дуже цікава стаття одного дослідника латентного простору мовних моделей про те, що в певній математичній інтерпретації центру цього простору, неочікувано виявилось прірва фалоцентричності, сексу і такого що Фрейду було б прям дуже-дуже цікаво :)

Десь була (нажаль не знайду посилання) дуже цікава стаття одного дослідника латентного простору мовних моделей

А я от такє бачив:

Do Llamas Work in English?
On the Latent Language of Multilingual Transformers
...
In this interpretation, the model’s
internal lingua franca is not English but concepts—
concepts that are biased toward English. Hence,
English could still be seen as a pivot language, but
in a semantic, rather than a purely lexical, sense.
Our experiments involve three text completion
tasks. The translation and cloze tasks operate at a
semantic level, whereas the word repetition task is
purely syntactic.
arxiv.org/pdf/2402.10588

Знов ви про змагання людини та LLM. Як би пояснити...Це блін те саме що порівнювати літак і поїзд.

Я сам вище писав, що це як

коні і люди

стосовно змагання людини і LLM. Я погоджуюсь з вашою метафорою про літак і поїзд і в цьому пойнті з вами згоден.

.

Ви зараз говорите, що поїзд так же прилітає у пункт «В», як літак. Я вам кажу, що ні, літаки літають, поїзди їздять.

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

Стверджувати, що LLM вирішують певні задачі логіки взагалі невірно, тому що в них відсутня частина, яка за це відповідає — різонер. В них є частина, яка на цю тему "галюцінує"("імітує") — ANN.

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

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

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

Як ці два протиріччя уживаються в світі LLM?

Є підозра що все ж таки є можливість не генеруючи нову інформацію витягувати розуміння і ідеї через реорганізацію та повторну ре-інтерпретацію.

Які у кого думки із цього приводу?

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

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

Ну по факту таке витягування це і є обробка даних. І в результаті виглядає що модель згенерувала нові данні. На мою думку дуже виглядає що є протиріччя. І відповідно постає питання і хочеться дізнатись відповідь, а чи є такі сгенеровані данні котрих не було в навчанні, множення на числах «новими»?

В контексті теорії інформації, внутрішня інформація моделі надійшла в згенеровані нею дані.

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

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

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

Теорія інформації

занадто низкорівнева для відповіді на такі питання.
Вона не може відповісти на питання — про сенси, патерни, і їх зв’язкі — емерджентність.

інформація може залишитись, але ніколи не може збільшитись.

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

Наприклад з вікіпедії
Інформаційна ентропія:
Наприклад, послідовністю Фібоначчі є 1, 1, 2, 3, 5, 8, 13, .... При розгляді цієї послідовності як повідомлення, а кожного числа як символу, існує майже стільки ж символів, скільки є символів у повідомленні, даючи ентропію близько log2(n). Таким чином, перші 128 символів послідовності Фібоначчі мають ентропію приблизно 7 біт/символ. Проте цю послідовність може бути виражено за допомогою формули [F(n) = F(n—1) + F(n—2) для n = 3, 4, 5, ..., F(1) =1, F(2) = 1], і ця формула має значно нижчу ентропію, і застосовується до послідовності Фібоначчі будь-якої довжини.

Про збільшення інформації:
Якщо приймач має вміння, потужність виявляти патерни, то отримавши послідовність
Фібоначчі скажімо 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, він виявить патерн, і згенерує оту формулу, використання якої дозволить продовжити ряд і виявити продовження 144, 233, ... А цього не було в першому повідомлені.
Ми отримали — нову інформацію.
Але — вона може бути не вірною, бо цей ряд у передавача мав правило — F(n) = F(n—1) * 100 для n > 12
І тоді ми скажемо що приймач — галюціонує, отими 144, 233 :)

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

Гарний приклад. У мене виникає питання, а чи правильно взагалі називати такі данні «нові», може просто проблема в термінології.

У мене виникає питання, а чи правильно взагалі називати такі данні «нові»

так і я перепитую, коли кажуть
— та LLM не зможе ніколи генерувати нове!
— а що такє — нове? І чим генерація, як результат, нового людиною відрізняється від генерації нового машиною?

Надайте критерій — нового, кажу :)
Об’єктивний. Тобто такий що ми можемо порівнювати щось як нове, без урахуванная суб’єкта його генерації. Бо якщо ми враховуємо суб’єкта — то буде — суб’єктивний критерій.

може просто проблема в термінології.

ну, галюцінація — точно ближче до нового.

от приклади були — запитували щось з історії у чатгпт. він крутий автор з жанру альтернативної історії :)
Письменників у цьому жанрі — люблять. А от чатгпт — критикують. За — нове.

Тут мені теж не зрозуміло, як і арифметикою
Є вікіпедія, гуглпошук — навіщо ще одна програма яка перекаже емпирічні факти?

А ця ж історична галюцінація може бути як раз виявленням — історічних законів, патернів :)
Які не спрацювали у дійсності в силу випадкових подій.

Так, згоден. Тоді от лишається тільки зрозуміти як тоді правильно сформулювати що таке «нова інформація», і чим воно тоді відрізняється від того що оброблено LLM.

я думаю що люди просто іраціональні, як зазвичай, і не рефлексують, що вони очікують — «корисну інформацію», а викорстувують термін — нову.

Ну наприклад, у сусідній темі було про музику
А от нову пісню може написати?
а підтекст — таку щоб стала хітом.

Тобто потреба не в новій пісні, а в — хіті :)

І якби люди були більш раціональними, то й ставили б «чесне» питання, по суті:
А от корисну пісню він може згенерувати?

Бо самі оті музиканти мотивовані не нове згенерувати, яке нікому не потрібне, а такє — щоб вразити. І «новизна» то спосіб — унікальності, впізнаванності. І вона повина бути — не зовсім новою, бо як занадто — то буде фейл.

Тобто термін «нова інформація» і не має сенсу розкривати, бо цінність — всім важливіша. а нове воно, чи не нове, то — академічно філософьске питання :)

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

До речі от базуючись на ось цьому прикладі,
Можна назвати таку відповідь не новою інформацією а «гіпотезою» чи «припущенням».
Що може бути вірно і тоді це виглядає як «нова інформація» а може бути не вірною, і відповідно сприйматись як «галюцинація».

Але суть у тім що це одночасно і галюцинація і нова інформація, і тоді виходить що різниця по ходу тільки в сприйнятті?

і галюцинація і нова інформація, і тоді виходить що різниця по ходу тільки в сприйнятті?

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

«Ми підходимо аналітично, вони пробують тупо запхати в комп’ютер щось. Беремо якусь проблему, стартуємо, І... вони постійно нас випереджають» LOL 😂

Нащо ж так піарити рашистську розробку QDrant.

Векторних баз дуже багато, і так от на 1 місце ставити мало відому софтину створену росіянином, то є дуже дивно.

Краще б вже згадали, наприклад, ChromaDB.

Пардон не був в курсі, приберу.
Підкажіть чи є ліміт у ChromaDB для кількості dimensions?

qdrant.tech/about-us

Це німецька компанія з одним лише росіянином (кофандер і СТО), який живе в Європі. Може ще чатгпт не користуватись із-за Цуцкевича? Чи гуглом із-за Бріна не користуватися? У вас вже взагалі дах їде.

Підняли гарну технічну тему, но вишивата і тут зраду знайшла, ніби більше тем для цього на ДОУ немає

PS Сам не користуюсь, але тільки тому, що є безкоштовні альтернативи

А хтось пробував вирішувати проблему з кодом? Так щоб чатбот прямо по кодобазі великого проекту. Всякі копайлоти та інші вбудовані в IDE кодогенератори мають дуже обмежений контекст (один файл в якому ти знаходишся).

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

Цією темою не займався. Але є думки із цього приводу: Тут якби RAG по-любому потрібен, проблема не чисто у розмірі вікна контексту. На приклад можна дати задачу RAG зробити попередню опрацювання коду пройтись і прям всюди додати опис та коментарі до усього коду. Може навіть зробить агента що підтягуватиме документацію по бібліотеках. Потім можна зробити Semantic Layer та бити код із коментарями на фрагменти і зберігати у векторній БД, і витягувати тільки фрагменти під запит, щоб скоротити вікно контексту. Подивитись в сторону як це зроблено в OpenDevin & Devika, може використати їх за базу.

По друге використовувати моделі які вміють оброблювати дуже велике вікно контексту, типу phi3-medium-128k (128k токенів) або Gemma-2b-10M (10 мільйонів токенів). Може навіть спершу опрацьовувати запит моделлю із великим вікном і відсіяти сміття, а потім ще раз вже більш розумною моделлю із меншим вікном але вже без сміття.

Може спробувати поєднати якось ці два варіанти.

huggingface.co/...​hi-3-medium-128k-instruct
aksh-garg.medium.com/...​cal-overview-900adc4fbeeb

Так в тому то і діло щоб адекватно відповідати по проекту, а тим більше писати код, робити ревью, LLM треба знати весь проект, а не тільки відірвані від контексту окремі файли і методи.

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

Я прикидав що треба щось типу цього.

Документація:
1. Згенерувати якусь загальну документацію по проекту
2. Згенерувати детальну документацію по кожному файлу передаючи загальну документацію як контекст, починати знизу вверх або зверху вниз. В кожен наступний слой передавати документацію з попереднього + загальну архітектуру.
3. Можливо доведеться пункт 2 пройти в кілька ітерацій

Запит:
1. Маючи документацію і запит юзера, знайти релевантні файли
2. Для фінальної відповіді, передати загальну архітектуру, документацію по релевантним файлам, самі файли

Але боюсь що це буде сильно дорого і довго.

Ну 10 мільйонів або навіть 128 тис токенів можуть якраз тут стати в нагоді.

Але боюсь що це буде сильно дорого і довго.

Саме так, це одна з невирішиних проблем розробки ПЗ.

Співпало що вчора в тг каналі «software architecture» зачепили тему документації, то я написав такє:

Denys: ...Себто, документаціє має апдейтитись відповаідно потреб реальних читачів, а не для того, щоб вона була.

Illia: Документ-бачення не є обов’язковим — і не має бути єдиним, є й інші різновиди документів. Є різні компанії. Десь купа однотипних речей взагалі без «бачення» — а десь навпаки багато ітерацій напочатку в спробі зрозуміти, що саме робимо.

me: Технології програмування просто ще сируваті, не поспівають за потребами.

Між описом вимог, спеками, тех завданням, валідаторами та моделями у коді, — прірви,і постійний россінхрон.

А то й протиріччя змісту.
І вирішується ця проблема — кількістю годин мітингів
Значення звичайного язика, того що роті, все важливіше. Ну і софт скіли звісно :)
(к.ц.)

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

Наприклад наші IDE повинні перетворитися на якісь wiki системи, на сторінках яких будуть і фрагменти документації, і код, і ментальні карти-UML, і конфіги, і туду списки з обговореннями("jira"), і зв’язкі між якими будуть різних типів — одні високорівневі, інші для транслятора, а тегі будуть ще прив’язувати до додаткових контекстів.
А частина сторінок, або фрагментів буде генеруватись на основі інших сторінок. Частина зв’язків також повинна буде формуватись ШІ.

Такє на зараз нереально, закон Конвея сильніший. Але й наявні LLM тому не зможуть значно змінити процес розробки. Тільки як персональні помічники.
У цьому сенсі скептики про заміну програміста праві. Не праві вони в причинах, не в тупості LLM діло(хотя і це є), а в тому що наявний процес розробки не надає можливості знати все що необхідно для ШІ

По друге використовувати моделі які вміють оброблювати дуже велике вікно контексту, типу phi3-medium-128k (128k токенів) або Gemma-2b-10M (10 мільйонів токенів)

Спробував phi3-medium, скормив йому файл на 1000 строк кода і попросив документувати — справився гірше інших відкритих моделей з меншим контекстом якими я користуюся — llama3-8b (70b сильно повільна на моєму залізі), останній codestral-22b (її фішка писати код а не документувати я так розумію).

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

Найкраще справився новий claude 3 sonnet який доступний через Cody. З gpt4 не пробував, но, думаю справився би не гірше claude.

Ще є Gemini 1.5 Pro із 1М токенів контекстне вікно

А хтось пробував вирішувати проблему з кодом? Так щоб чатбот прямо по кодобазі великого проекту.

Я користуюсь при розробці Codeium.
Там в них в платних версіях є:
Advanced personalization on your code base
Optional finetuning on your code base
codeium.com/pricing

Не знаю наскільки те дієве.
Але думаю що на поточному етапі розвитку — тільки персонально під проект треба тренувати, просто запхати у вікно контексту весь проект буде замало.

Так, контексти в моделей велетенські зараз. Якщо ваш код — не кривавий ентерпрайз в виді моноліту — то скоріше за все, вся кодова база, наприклад, окремо взятого мікросервісу має поміщатись в один запит LLM. Маю консольне code review / code improver рішення. Потенціал неймовірний. Дуже дивно, що всі ці copilotи не беруть на озрброєння рішення, що вносять зміни в код / створюють коміт по команді в чаті.

Workflow наступний:
1) пишем в чаті що зробить
2) вивчаєм діфи внесених мовною моделлю змін
3) Опціонально інтегруємось з тестами і отримуємо не ONE-SHOT рішення, що може бути ок а може ні, а agent-based system, що ітеративно вносить зміни — фіксить помилки.

Це ж які моделі з велетенським контекстом ви використовуєте? У відкритих моделей до 32к токенів, що приблизно 40-50 сторінок тексту, що покриє лише невеличкий проект. Причому із тих 32к токенів, аби половина була «робоча»

У гугла там щось 2 млн. токенів, але:
1. Дорого (особливо якщо постійно в контекст 2 млн. токенів слати)
2. Є певний скептицизм що всі вони «робочі»
3. Все-одно мало для великих проектів

Хоча у мене от сумніви не стільки в кількости токенів, а в увазі LLL серед усього цього сміття чи зможе вона в такому багні розгрібати щось.

Так у мене також є сумніви що модель на 14млрд. параметрів розбереться з таким контекстом. Треба експерементувати.

Навіть якщо то була би модель із одним трильйоном параметрів. всеодно є сумніви в якості уваги.
А тут ще й модель мала, і як довго таке щастя буде пережовувати 10м токенів, теж питання.

Та нє, ну не гоніть. Який сенс використовувати зараз відкриті моделі для такого?

Звісно, GPT4o , Claude Opus.

Ну так, дорого, одна ітерація роботи / code review / фіча з середнім по розміру проєктом через LLM з простим циклом промптів в мене тягнула на $5 — $20 баксів.

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

А різниця в якості роботи з кодом між state-of-the art та відкритими моделями ще 6 місяців тому була дуже радикальна.

Доречі, ще не дивився новий DeepSeekCoder 2. Оце може бути виключення. Це якщо про відкриті моделі.

Попередня версія цієї моделі всіх рвала, а на AI Math Olympiad на Kaggle модель DeepSeekMath, що заснована на DeepSeekCoder, просто впринципі не має конкурентів навіть близько по якості результатів.

Технічно опенсорсних моделей state of the art теж хватає. До речі про питання чому їх використовувати: бо часто буває що вони і так можуть виконувати вузьку задачу, так як вам потрібно, або їх легше fine tune під вашу задачу, не залежить від «старшого брата», в деяких випадках вони бувають навіть краще працюють (на приклад якщо ми кажемо про вузьку спеціалізацію чи задачу), і дуже часто вони дешевші.
Зрозумійте правильно, я не пропоную відмовлятись від платних сервісів, я просто кажу що це все разом якщо правильно поєднавши можна отримати кращій результат як по ціні так і по якості.

1) По ціні експлуатації — Так. Зауважу, що в масштабах різних бізнесів цією ціною часто можна знехтувати на користь інших аспектів.
2) По якості — При умові об’єму інвестицій, що часто може бути невиправданим, особливо на ранніх етапах впровадження ШІ, або ж просто непідйомним для інвестора/замовника.
3) По ціні розробки — ні, а це ключова стаття витрат.

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

Та для мейнстріму правильною порадою було б: Віддавайте перевагу state-of-the art мовним моделям доступним як SaaS, що показують найкращі результати на цільових бенчмарках. Вони взаємозамінні. Перехід на локальні спеціалізовані моделі з повним контролем можна здійснити пізніше, якщо виникне така необхідність.
І що важливо: цей перехід, ймовірно, буде не переписуванням рішення, а його розширенням в контексті роботи над моделлю, адже core-логіка ймовірно залишиться на своєму місці, а інтеграція з мовною моделлю має бути частиною 3rd-party abstraction.

Це не загальна істина, але для більшості RAG-like рішень буде правдою.

У мене відчуття що ви проводите паралелі між SaaS такими як GhatGPT і State of the art моделями. Але open source теж є багато моделей state of the art.

На моїй практиці рівно навпаки: легше почати із локальної моделі і потім перейти на той самий OpenAI. Open Source моделі та inference більш примхливі і проблемні є баги. Відповідно якщо ви відтестували це на локальній моделі і воно працює, то воно вже точно буде працювати якщо просто замінити endpoint на OpenAI. А ось навпаки якраз не все так просто.

Це ви GPT4o до вашого RAGа конектите з приватними документами? Чи просто використовуєте як помічника?

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

З власного досвіду:

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

Всі топові мовні моделі доступні для використання через Trusted Cloud Providers, якто Amazon Bedrock, Microsoft Azure, Google Vertex.
Тобто, моделі ізольовані на VPS хмарних провайдерів, і відповідно до ToS цих провайдерів, дані звідти не можуть передаватись третім особам (наприклад, компаніям-розробникам моделей).

Більшість корпорацій вже хостять свої non-ai сервіси у цих хмарних провайдерів. Якщо ви і так хостите всі свої дані на умовному Amazon, в вас немає причин не довіряти використанню Claude через Amazon Bedrock, якщо на Microsoft Azure — аналогічно щодо GPT4o і так далі.

Щоб розбити ці стіни, відправляємо decision-maker’ів читати Terms of Service хмарних провайдерів, де вони вже і так хостяться, і отримуємо юридично та безпеково обгрунтований дозвіл нормально працювати зі state of the art мовною моделлю.

В підсумку — радикальне зменшення затрат на розробку та краща якість результатів AI-рішення, фокус кодової бази на власних бізнес-задачах, а не на подоланні дитячих проблем мовних моделей, котрі в результаті стрімкого розвитку галузі, буду викинуті на сміття через 10-20 місяців.

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

Але це вже велетенський крок вперед через корпоративну стіну страху.

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

У гугла там щось 2 млн. токенів

По особистим враженням, моделі Google дуже відстають по якості reasoning.

А Google Vertex зроблено настільки через сраку, що я поки-що тримаюсь моделей OpenAI, Anthropic, Meta & Microsoft (Mistral нажаль серед відставших, але вірю, що вони скоро увірвуться з чимось якісним).

От що особисто мені подобається в моделях Google — так це multimodality. Тут вони дійсно конкурентноздатні.

У мене приблизно такі самі враження. Гугл відстає. Хоча усі думали що вони перші будуть в цьому.

Дякую, гарна робота, багато корисної інформації!)

Це дуже гарна стаття, яка надає оглядову інформацію про всі сучасні поняття в ШІ. Дякую!

Чи коректно буде перекласти «Retrieve Augment Generate (RAG) Pipeline» як «конвеєр уточненої догенерації» ?

Ну суть передає, але переклад не точний.

Ще рекомендую dify.ai — як простий спосіб погратись із моделюванням флоу. Можна легко щось просте зібрати, та в них ще є шаблони готових рішень. Звісно нічого серйозного не зробиш, але легше почати ніж з Flowise.

Так бачив цей китайський продукт, виглядає цікаво. Що вам в ньому сподобалось?

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

По моїм враженням самий Production Ready фреймворк із автономними агентами виглядає Microsoft AutoGen

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

То більше тема для RPA. Так інтегрувати RPI та АІ цікавий напрямок.
Думаю Apple скоро випустить AI який буде кнопки натискати на єкрані айфона.

Та то просто приклад був з кнопками. Майкрософт скоро додасть ШІ в свій РПА. Я мав на увазі шось типу Девіна 🙂 більш складні системи який можуть бути відносно автономними, в не просто виклики ендпоінтів та function calling

Ну в них же є RPA: Power Automate. Так буде цікаво подивитись як це працюватиме.
І є ж ще інші більш наворочені RPA ніж Майкрософт

Суть не в РПА, а саме в автономності та здатності до само рефлексії та планування і навчання. Ми також робимо ШІ старт ап і дуже багато всьо пройшли за 9 місяців 😉 Але ще ці система мають багато недоліків

Чим би ви могли поділитись із свого досвіду корисного чи повчального?

Не хватає трохи реальних прикладів. Поділюся своїм досвідом )

1. Використовувати llm напряму через її API ollama або через легку обгортку litellm. Всі ці модні фреймворки типу langchain, llamaindex додають лише непотрібні абстракції, complexity і overhead, і при цьому ховають купу важливих деталей. Самі llm набагато простіші, ніж їх намагаються представити ці фреймворки.

2. Зберігати ембедінги в якійсь векторній базі даних або в документній (особисто я elasticsearch використовую). А то якщо будете дампити в файли, замучаєтесь чекати поки завантажаться в пам’ять при кожному запуску. Да і пам’ять всю з’їсть якщо проіндексуєте 1000 документів.

3. Відкриті моделі брешуть по поводу контекстного вікна. Вони заявляють що можна передавати від 7к до 24к токенів, но насправді воно сильно менше. Так, вона з’їсть кілька сторінок тексту, но проігнорить більшість інформації, чи прочитає по діагоналі. Тому, очевидний варіант в лоб, а саме знайти потрібні документи і передати разом з запитом не прокатує, особливо якщо документи великі. Але має прокатити з закритими платними моделями на 500 млрд. параметрів типу chatgpt 4, гугловскі платні.

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

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

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

Це сильно допомагає знайти релевантні шматки, але лише якщо це конкретне питання по поводу якогось факту в документах. Якщо ж це якесь загальні питання («розкажи як працює он ця штука») чи питання які вимагають аналізу кількох документів — тут вже треба інші методики (див пункт 6.)

6. В реальному житті запит від юзера != запит до llm. Це обмін запитами між RAG, джерелами даних і llm, де ваш RAG оркеструє процесом. Процес може виглядати так: спочатку RAG просить llm класифікувати запит, а залежності від типу запиту може бути різний конвеєр обробки. Якщо запит складний, RAG попросить llm розбити на простіші у відповідності з джерелами даних які є в наявності, потім кожен дрібний запит обробляється окремо, відповідь зі всіх передається знову в llm для генерації кінченої відповіді, потім з допомогою llm перевіряється чи кінчена відповідь відповідає на питання юзера, якщо ні то процес повторяється але вже зі знайденим контекстом з попередніх ітерацій.

На ютюбі є повно відео в стилі «робимо чатбот для приватних даних за 5 хв» — не ведіться ). Воно працює лише в тепличних умовах, з маленьким набором документів, або простими текстовими документами, з використанням розумних, платних llm типу chatgpt 4o. З реальними сценаріями, коли у вас тисячі документів різної давності, валідності і структури, різні джерела інформації які часто протирічать друг другу, безкоштовна llm модель на 7 млрд. чи 50 млрд. параметрів — доведеться попотіти щоб отримати адекватний, стабільний результат. До речі платний майкрософтский copilot для бізнесу на основі chatgpt 4o, куди можна закинути приватні документи — працює не сильно краще.

На скільки HyDE підхід для вас показує гарний результат для генерації гіпотетичної відповіді та пошуку чанків?
Які би ви порекомендували cross encoder моделі?

Не знаю яка конкретно заслуга самого HyDE, я все скопом зробив і вроді гарно чанки шукає, але залежить від питання. Чанки допомагають при чітких питаннях при умові що ця відповідь є в документах, а як щось треба щось подумати, чи щось загальне, типу «Поясни як працює АБС?» то, відповідь буде так собі, навіть якщо буде цілий документ який описує як працює АБС, тільки половина чанків з того документа знайдуться.

Які би ви порекомендували cross encoder моделі?

Я звідси беру дефолтні:
sbert.net/...​_encoder/usage/usage.html

Не грався з іншими, та думаю вони всі більш-менш одинакові

Які би ви порекомендували моделі?
Особливо спеціалізовані типу cross encoder, Reranking, Text-to-Text, language detector, document layout awareness, Table question answering, Topic summarization, sentiment analysis, Zero-Shot Text Classification, annotation & Relation extraction чи щось такого роду

Які саме можливості моделей на вашій практиці недоступні чи не зручні якщо використовувати inferince довіжки у порівнянні із запуском моделі прямо із додатку?

Можна на окремому сервері запустити, особливо якщо там А100 карта якась для ML/AI. Можна використовувати таку модель із різних клієнтів, різними додатками різними юзерами одночасно. Зручність короче. А якщо в додатку використовувати litellm якусь, то однією строчкою коду можна переключитися на будь-яку llm, хоть на чатгпт.

Перепрошую, я думав ви якраз були проти використання LiteLLM proxy чи inference движків типу LocalAI чи Ollama. Я думав ви якраз пропонували це не використовувати і запускати модель на пряму із коду. І тому спитався що саме в inference та proxy для вас було якраз НЕ зручно.

Ні, я проти фреймворків (llamaindex, langchain) які працюють поверх llm.
Де сама llm хоститься — в програмі чи окремо, це вже інше питання, зручніше, звісно, щоб окремо )

Я мене зв’язка litellm -> ollama. llamaindex використовую лише для парсингу документів — у них є багато рідерів під різні формати. Ви до речі якими інструментами парсите?

На разі під парсинг використовуємо LangChain

Є ще варіант не парсити документи а делегувати це повністю рішенням типу Azure AI Search, особливо, якщо поповнення Knowledge Base не є частиною frontend рішення. Там майки завезли і інтеграції з sharepoint і парсинг купи форматів.

Ми в своїй практиці намагаємося менше покладатись на 3-rd party платних клаудних сервісів, якщо це можна зробити самому за умови якщо можна зробити те саме не гірше.

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

Як ви вирішуєте проблему конвертації text-to-graph?

Всі ці модні фреймворки типу langchain, llamaindex додають лише непотрібні абстракції, complexity і overhead, і при цьому ховають купу важливих деталей. Самі llm набагато простіші, ніж їх намагаються представити ці фреймворки.

Боже тааак. Це треба червоними літерами капсом десь писати всім менеджерам, замовникам та їх технічним командам (не AI).

Реально наболіло від зоопарків всього, що хотять засунути в проєкти going overcomplicated with no reasons and benefits.

Я особисто роблю ось так: github.com/Nayjest/ai-microcore — просто python адаптер над різними LLM API (http чи local типу hugging face transformers) з однією кор функцією для inference: llm(prompt, additional_params). І набором костилів, що зглажує відмінності в API.

Дякую, повчально. Чим ще ви могли поділитись із свого досвіду корисного чи повчального?

Ух, та багато.

— Якшо модель не слухає — кричіть! Кумедно, але досить простий і часто ефективний підхід до рішення проблем not following instructions, особливо коли інструкцій багато і вони складні — писати важливе капсом :)

— Специфіка Manual QA в ШІ застосунках — тут на цілу статтю потяне.

— Бенчмарки якості LLM-відповідей під ваш конкретний ШІ застосунок — це те, на що треба і варто закладати час. Актуально на всіх стадіях продукту після перших прототипів. Необхідно для прийняття рішень і вибору найбільш дієвих підходів.
imho, для середніх-великих по кількості фіч ШІ-додатків, це ще більш важливо, ніж базові тести, адже без бенчмарків вкрай складно визначити, чи є те чи інше рішення прийнятним з точки зору якості.

— Є сенс не заморочуватись над покращеннями вашого RAG, чи що там ви робите, саме в роботі з актуальними локальними мовними моделями (low-end), а орієнтуватись на state-of-the-art мовні моделі доступні по API, адже opensource моделі розвиваються дуже швидко і те що ви там файнтюнили / костилили під LLAMA-3 / Phi-3 / Mistral буде неактуально через 6-12 місяців, якщо в вас все ок працює, наприклад, на GPT4o. Сьогоднішній High-end це завтрашній Low-end

— Я вірю, що акції Nvidia будуть показувати крутий перформанс як мінімум наступні 3 роки :)

— Якщо ви маєте базові знання ML / розумієте, як працюють нейронні мережі, бачили Pytorch, чи щось схоже, то, наприклад по численним відео Andrej Karpathy та деяких інших авторів на Youtube, ви можете осмисленно створити з нуля мовну модель, що мало чим відрізняється від state-ofthe-art моделей крім розмірів, буквально за кілька годин. Я от робив модельку під мову Тараса Григоровича, навчав її на Кобзарі, результати були кумедні.

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

Дякую. Повчально. Додав в закладки.

У вас вийшов прямо посібник початківця для входження у домен «прикладного ШІ»!

По секрету, наскільки вам допогав chatgpt, тобто наскільки полегшив оформити вам вашу візію та знання у таку вправну статтю?

Користувався досить часто, але тільки для того щоб зробити простіше і придумати кращі приклади, суть вичитана із статей і git репозиторіів. По друге оригінально я писав її англійською мовою. Так що в даному випадку більш допомагав перекладач DeepL ))

Зрозуміло. Просто без нього, здається, вже як без «друкарської машинки» :)

А ще питання про

Шукаю ентузіастів та однодумців, що знаються на Python

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

Чи прийдеться й з JS/TS переходити, чи ні, якщо йти в цей домен?

Ха-ха. Так, Без LLM вже як без рук.

Так, node.js теж популярний в цьому напрямку. І думаю ще лишатиметься таким довго, так що переходити на Python не думаю що обовʼязково, хоча в AI більшість всього зроблено саме на Python, подавляючи більшість тулз та бібліотек. Node.js частіше зустрічається в готових продуктах як от Flowise & WrenAi які зроблено на TypeScript, що майже те саме.

LangChain є для обох Python & Node.JS

Радий що вона була вам корисна

Вона взагалі для мене з категорії
«Всесвіт відгукнувся!»

Це коли про щось думаєш, вагаєшся, шукаєш, забуваєш, а потім знову чогось починає саме якось думатись. і тут щось з Всесвіту тобі лусь по лобі
і ти такий: Евріка! а я знав, а я так і думав! :)

Зірки зійшлись. Це чудово. Просто зараз на часі.

Підписатись на коментарі