Як я вже згадував у попередньому дописі, розробка штучного інтелекту Fabrice виявилася набагато складнішою, ніж очікувалося, що змусило мене дослідити багато різних підходів.
Початковий підхід: Індекс лам – векторний пошук
Моя перша спроба покращити пошукові можливості Fabrice AI була пов’язана з використанням індексу Llama для векторного пошуку.
Концепція була проста: взяти вміст мого блогу, перетворити його на документи Langchain, а потім перетворити їх на документи Llama.
Потім ці Llama-документи зберігалися б у векторному індексі, що давало б мені змогу запитувати в цьому індексі потрібну інформацію.
Однак, коли я почав тестувати систему, стало очевидно, що такий підхід не дає тих результатів, на які я сподівався.
Зокрема, коли я ставив системі контекстно-залежні запитання на кшталт “Яких найбільших помилок припускаються засновники маркетплейсів?”, штучний інтелект не зміг надати змістовних відповідей.
Замість того, щоб отримати детальну інформацію, яка, як я знав, містилася в даних, він повертав нерелевантні або неповні відповіді.
Ця перша невдача змусила мене переглянути свій підхід.
Я зрозумів, що просто зберігати контент у векторному індексі недостатньо; механізм пошуку повинен розуміти контекст і нюанси поставлених запитань.
Це усвідомлення стало першим з багатьох уроків, які вплинули на еволюцію Fabrice AI.
Зберігання знань: Зберігання та пошук документів у MongoDB
Маючи на увазі обмеження підходу Llama Index, я дослідив можливість зберігання документів Llama в MongoDB.
Гнучка схема та документно-орієнтована структура MongoDB здалася мені багатообіцяючим рішенням для управління різноманітними типами контенту, який я накопичив за ці роки.
План полягав у тому, щоб створити більш динамічний та оперативний пошук.
Однак такий підхід швидко зіткнувся з проблемами.
Пошукова функціональність, яка, як я очікував, повинна була бути більш надійною, не спрацювала так, як очікувалося.
Запити, які мали б повертати релевантні документи, натомість не давали жодного результату або ж показували нерелевантний контент.
Ця невдача розчарувала, але вона також підкреслила важливий урок: метод зберігання так само важливий, як і стратегія пошуку.
Я почав розглядати інші варіанти, такі як використання MongoDB Atlas для векторного пошуку, що потенційно могло б забезпечити потрібну мені точність і масштабованість.
Однак перед тим, як зупинитися на цій альтернативі, я хотів дослідити інші підходи, щоб визначити, чи може бути більш ефективне рішення.
Пошук метаданих та векторне сховище: У пошуках специфіки
Одним із наступних шляхів, які я дослідив, було використання ретрівера метаданих у поєднанні зі сховищем векторів.
Ідея цього підходу полягала в тому, щоб класифікувати величезний масив інформації у Fabrice AI, а потім отримувати відповіді на основі цих категорій.
Структуруючи дані за допомогою метаданих, я сподівався покращити здатність штучного інтелекту надавати конкретні, цілеспрямовані відповіді.
Однак цей метод також мав свої обмеження.
Хоча на перший погляд він здавався багатообіцяючим, штучний інтелект намагався давати точні відповіді на всі типи запитів.
Наприклад, коли я запитав: “Чи оптимістично налаштований автор?”.
Система не змогла інтерпретувати питання в контексті відповідного контенту.
Замість того, щоб надати глибокий аналіз на основі метаданих, вона або повертала розпливчасті відповіді, або не давала жодної.
Цей підхід дав мені цінний урок про важливість контексту в ШІ.
Недостатньо просто класифікувати інформацію; ШІ також повинен розуміти, як ці категорії взаємодіють і перетинаються, щоб сформувати цілісне розуміння контенту.
Без такого глибокого розуміння навіть найсучасніші методи пошуку можуть виявитися неефективними.
Структурування знань: Індекс SummaryTreeIndex
Продовжуючи вдосконалювати Fabrice AI, я експериментував зі створенням SummaryTreeIndex.
Цей підхід мав на меті узагальнити всі документи у вигляді дерева, що дозволило б штучному інтелекту переміщатися по цих резюме і отримувати релевантну інформацію на основі структури контенту.
Ідея полягала в тому, що, узагальнюючи документи, ШІ може швидко визначати ключові моменти і відповідати на запити стислою, точною інформацією.
Однак цей метод також зіткнувся зі значними проблемами.
Штучний інтелект намагався надати змістовні відповіді на складні запити, такі як “Як приймати важливі рішення в житті?”.
Замість того, щоб спиратися на багатий, нюансований контент, що зберігається в резюме, відповіді ШІ часто були поверхневими або неповними.
Цей досвід підкреслив, наскільки складно збалансувати широту і глибину в ШІ.
Хоча резюме можуть забезпечити загальний огляд на високому рівні, їм часто бракує детального контексту, необхідного для відповідей на складніші запитання.
Я зрозумів, що будь-яке ефективне рішення має поєднувати як детальний контент, так і узагальнення високого рівня, дозволяючи штучному інтелекту використовувати і те, і інше за потреби.
Ось чому у версії Fabrice AI, яка наразі працює в режимі реального часу, я попросив штучний інтелект спочатку дати коротку відповідь, а потім перейти до більш детальної інформації.
Розширюючи горизонти: Індекс графів знань
Усвідомлюючи обмеженість попередніх методів, я звернувся до більш складного підходу: індексу графів знань.
Цей підхід передбачав побудову графа знань з неструктурованого тексту, що дозволило ШІ здійснювати запити на основі сутностей.
Мета полягала в тому, щоб створити більш динамічне і взаємопов’язане розуміння контенту, що дозволило б ШІ Fabrice ефективніше відповідати на складні, контекстно-залежні питання.
Незважаючи на свою багатообіцяючу перспективу, Knowledge Graph Index також зіткнувся зі значними перешкодами.
Штучний інтелект намагався видавати точні результати, особливо для запитів, які вимагали глибокого розуміння контексту.
Наприклад, на запитання: “Що таке справедлива оцінка посівного капіталу та Серії А?” ШІ знову не зміг надати релевантної відповіді, що підкреслює складність інтеграції неструктурованого тексту в послідовний граф знань.
Цей підхід, хоч і виявився невдалим, надав важливу інформацію про проблеми використання графів знань у ШІ.
Складність даних і потреба в точному контексті означали, що навіть добре побудований граф знань може не дати бажаних результатів.
Ще одним недоліком Індексу графів знань була його низька швидкість.
Час відгуку для отримання пов’язаних документів був дуже високим порівняно з індексом векторного сховища.
Переоцінка даних: Близнюки
Після кількох невдач я вирішив застосувати інший підхід, використавши штучний інтелект Google, Gemini.
Ідея полягала в тому, щоб створити набори даних з JSON-CSV-файлів, а потім навчити кастомну модель LLM, використовуючи ці дані.
Я сподівався, що, використовуючи структуровані дані та надійну навчальну модель, я зможу подолати деякі проблеми, які переслідували попередні спроби.
Однак цей підхід також зіткнувся з труднощами.
Процес навчання було зупинено через неправильне форматування даних, що завадило ефективному навчанню моделі.
Ця невдача підкреслила важливість цілісності даних у навчанні ШІ.
Без правильно відформатованих і структурованих даних навіть найдосконаліші моделі можуть працювати не так, як очікувалося.
Цей досвід змусив мене розглянути можливість використання BigQuery для зберігання даних JSON, що забезпечує більш масштабовану і надійну платформу для управління великими наборами даних, необхідними для ефективного навчання ШІ Фабріса.
Поєднання сильних сторін: Ланцюгові документи з Pinecone
Незважаючи на труднощі, я був сповнений рішучості знайти рішення, яке дозволило б Fabrice AI ефективно зберігати та видобувати знання.
Ця рішучість привела мене до експериментів з документами Langchain та Pinecone.
Підхід полягав у створенні сховища векторів Pinecone з використанням документів Langchain і вбудовувань OpenAI, а потім у витяганні найкращих схожих документів на основі запиту.
Цей метод виявився перспективним, особливо коли запит містив назву документа.
Наприклад, на запитання “Що є ключем до щастя?” штучний інтелект зміг точно знайти й узагальнити відповідний контент.
Однак все ж таки існували обмеження, особливо коли в запиті не було конкретних ключових слів або назв.
Цей підхід продемонстрував потенціал поєднання різних технологій для підвищення продуктивності ШІ.
Інтегрувавши документи Langchain зі сховищем векторів Pinecone, я зміг підвищити релевантність і точність відповідей ШІ, хоча і з деякими обмеженнями.
Досягнення узгодженості: GPT Builder OpenAI
Вивчивши різні методи і технології, я звернувся до GPT Builder від Open AI, щоб консолідувати і вдосконалити знання, що зберігаються в Fabrice AI.
Завантаживши весь контент у базу знань GPT, я мав на меті створити більш послідовну та надійну платформу для пошуку та взаємодії з моїми знаннями.
Цей підхід виявився одним із найуспішніших, оскільки штучний інтелект зміг надати кращі результати за цілою низкою запитів.
Запорукою цього успіху стала інтеграція всіх знань в єдину, цілісну систему, що дозволило ШІ спиратися на всю повноту контенту, відповідаючи на запитання.
Як я вже згадував у попередньому дописі, я не зміг запустити його на своєму веб-сайті, і він був доступний лише для платних підписників Chat GPT, що, на мою думку, було занадто обмежуючим фактором.
Крім того, хоча він став кращим, мені все ще не подобалася якість відповідей, і мені було некомфортно випускати його на загальний огляд.
Остаточне доопрацювання: Асистенти GPT з використанням моделі 4o
Останній шматочок пазла в розробці Fabrice AI з’явився з впровадженням асистентів GPT з використанням моделі 4o.
Цей підхід став кульмінацією всього, чого я навчився протягом проекту.
Використовуючи векторну базу даних і вдосконалюючи підказки, я прагнув досягти максимально можливого рівня точності та контекстного розуміння відповідей ШІ.
Цей метод передбачав завантаження всіх накопичених мною знань у векторну базу даних, яка потім використовувалася як основа для взаємодії зі штучним інтелектом.
Векторна база даних дозволила ШІ виконувати більш складні пошуки, отримуючи інформацію на основі смислового значення запитів, а не покладаючись лише на відповідність ключових слів.
Це стало значним кроком вперед порівняно з попередніми підходами, що дозволило ШІ краще розуміти і відповідати на складні, нюансовані питання.
Однією з ключових інновацій цього підходу було ретельне доопрацювання підказок.
Ретельно розробляючи та тестуючи різні підказки, я зміг спрямувати ШІ на надання більш точних та релевантних відповідей.
Це передбачало не лише зміну формулювань підказок, а й експерименти з різними способами структурування запитів для отримання найкращих відповідей.
Результати були вражаючими.
ШІ тепер міг обробляти широкий спектр запитів з високою точністю, навіть коли питання були відкритими або вимагали глибокого розуміння контексту.
Наприклад, на запитання “Як приймати найважливіші рішення у своєму житті?”.
ШІ надав вичерпну і глибоку відповідь, спираючись на різноманітні джерела і точки зору, щоб надати всебічну відповідь.
Цей успіх став кульмінацією сотень годин роботи і незліченних експериментів.
Він продемонстрував, що за допомогою правильного поєднання технологій і вдосконалення можна створити штучний інтелект, здатний не лише ефективно зберігати і знаходити інформацію, але й осмислено взаємодіяти з нею.
Розробка GPT Assistants з використанням моделі 4o стала тим моментом, коли штучний інтелект Fabrice по-справжньому проявив себе, досягнувши того рівня складності й точності, який я передбачав від самого початку.
Потім API GPT Assistants було інтегровано в мій блог, щоб дозволити кінцевим користувачам взаємодіяти з Fabrice AI так, як ви бачите його в блозі прямо зараз.
Роздуми про подорож
Процес розробки Fabrice AI висвітлив складнощі роботи зі штучним інтелектом, особливо коли йдеться про розуміння та контекстуалізацію інформації.
Він навчив мене, що в розробці ШІ немає швидких шляхів – кожен крок, кожна ітерація та кожен експеримент є необхідною частиною шляху до створення чогось справді ефективного.
Забігаючи наперед, я з радістю продовжую вдосконалювати і розширювати Fabrice AI.
Як згадувалося в попередньому дописі, я перегляну поставлені запитання, щоб доповнити базу знань там, де є прогалини.
Я також сподіваюся з часом випустити інтерактивну версію, яка виглядатиме і звучатиме як я, і з якою ви зможете поспілкуватися.
