Цей пост написано у співавторстві зі Станіславом Єщенком із Q4 Inc.
Підприємства використовують Retrieval Augmented Generation (RAG) як основний підхід до створення чат-ботів із запитаннями та відповідями. Ми продовжуємо спостерігати нові проблеми, пов’язані з характером асортименту доступних наборів даних. Ці набори даних часто є сумішшю числових і текстових даних, інколи структурованих, неструктурованих або напівструктурованих.
Q4 Inc. необхідні для вирішення деяких із цих проблем в одному з багатьох сценаріїв використання ШІ, побудованих на AWS. У цій публікації ми обговорюємо приклад використання бота Q&A, який реалізував Q4, виклики, пов’язані з числовими та структурованими наборами даних, і те, як Q4 дійшов висновку, що використання SQL може бути життєздатним рішенням. Нарешті, ми детальніше розглянемо, як використовувала команда Q4 Amazon Bedrock і SQLDatabaseChain для реалізації рішення на основі RAG із генерацією SQL.
Огляд варіантів використання
Q4 Inc. зі штаб-квартирою в Торонто та офісами в Нью-Йорку та Лондоні є провідною платформою доступу до ринків капіталу, яка змінює спосіб ефективного зв’язку, спілкування та взаємодії між емітентами, інвесторами та продавцями. Платформа Q4 полегшує взаємодію між ринками капіталу за допомогою продуктів для веб-сайтів IR, рішень для віртуальних подій, аналітики залучення, зв’язків з інвесторами, управління взаємовідносинами з клієнтами (CRM), аналізу акціонерів і ринку, спостереження та інструментів ESG.
У сучасному фінансовому середовищі, яке динамічно розвивається та керується даними, спеціалісти зі зв’язків з інвесторами (IRO) відіграють вирішальну роль у налагодженні зв’язку між компанією та її акціонерами, аналітиками та інвесторами. У рамках своїх щоденних обов’язків IRO аналізують різноманітні набори даних, у тому числі CRM, записи про власність і дані фондового ринку. Сукупність цих даних використовується для створення фінансових звітів, встановлення цілей у відносинах з інвесторами та керування зв’язками з існуючими та потенційними інвесторами.
Щоб задовольнити зростаючий попит на ефективне та динамічне отримання даних, Q4 мав на меті створити інструмент запитань і відповідей чат-бота, який забезпечить інтуїтивно зрозумілий і простий спосіб для IRO отримати доступ до необхідної інформації в зручному для користувача форматі.
Кінцева мета полягала в тому, щоб створити чат-бота, який бездоганно інтегрував би загальнодоступні дані разом із приватними даними клієнта Q4, зберігаючи при цьому найвищий рівень безпеки та конфіденційності даних. Що стосується продуктивності, метою було підтримувати час відповіді на запит у секундах, щоб забезпечити позитивний досвід для кінцевих користувачів.
Фінансові ринки – це регульована галузь із високими ставками. Надання невірної або застарілої інформації може вплинути на довіру інвесторів та акціонерів, а також інші можливі ризики конфіденційності даних. Розуміючи галузь і вимоги, Q4 встановлює конфіденційність даних і точність відповідей як керівні принципи при оцінці будь-якого рішення перед його виходом на ринок.
Для підтвердження концепції Q4 вирішив використати набір даних про фінансову власність. Набір даних складається з точок даних часового ряду, що представляють кількість активів у власності; історію транзакцій між інвестиційними установами, фізичними особами та публічними компаніями; і багато інших елементів.
Оскільки Q4 хотів переконатися, що він може задовольнити всі функціональні та нефункціональні вимоги, які ми обговорювали, проект також мав залишатися комерційно здійсненним. Це дотримувалося протягом усього процесу прийняття рішення щодо підходу, архітектури, вибору технології та окремих елементів рішення.
Експерименти та виклики
З самого початку було зрозуміло, що для розуміння людського мовного питання та отримання точних відповідей Q4 потрібно буде використовувати великі мовні моделі (LLM).
Нижче наведено деякі з експериментів, проведених командою, а також виявлені проблеми та отримані уроки:
- Попередня підготовка – Q4 зрозумів складність і проблеми, пов’язані з попередньою підготовкою LLM за допомогою власного набору даних. Швидко стало очевидним, що цей підхід потребує ресурсів і містить багато нетривіальних кроків, таких як попередня обробка даних, навчання та оцінка. Окрім додаткових зусиль, це було б непомірно дорого. Враховуючи природу набору даних часових рядів, Q4 також зрозумів, що йому доведеться постійно виконувати поступове попереднє навчання в міру надходження нових даних. Для цього знадобилася б спеціальна міждисциплінарна команда з досвідом роботи з даними, машинного навчання та домену. знання.
- Тонка настройка – Точне налаштування попередньо підготовленої базової моделі (FM) за допомогою кількох позначених прикладів. Цей підхід показав певний початковий успіх, але в багатьох випадках модельні галюцинації були проблемою. Модель намагалася зрозуміти нюанси контекстуальних сигналів і повертала неправильні результати.
- RAG із семантичним пошуком – Звичайний RAG із семантичним пошуком був останнім кроком перед переходом до генерації SQL. Команда експериментувала з використанням пошуку, семантичного пошуку та вбудовування для вилучення контексту. Під час експерименту з вбудовуваннями набір даних перетворювався на вбудовування, зберігався у векторній базі даних, а потім зіставлявся з вбудовуваннями запитання для вилучення контексту. Отриманий контекст у будь-якому з трьох експериментів потім використовувався для доповнення оригінального запиту як вхідних даних для LLM. Цей підхід добре працював для текстового вмісту, де дані складаються з природної мови зі словами, реченнями та абзацами. Враховуючи характер набору даних Q4, який складається переважно з фінансових даних, що складаються з чисел, фінансових операцій, котирувань акцій і дат, результати в усіх трьох випадках були неоптимальними. Навіть під час використання вставок, вбудовування, згенеровані з чисел, мали проблеми з рейтингом подібності та в багатьох випадках призводили до отримання неправильної інформації.
Висновок Q4: генерування SQL – це шлях вперед
Враховуючи проблеми, з якими стикається використання традиційної методології RAG, команда почала розглядати питання про створення SQL. Ідея полягала в тому, щоб використати LLM, щоб спочатку створити оператор SQL із запитання користувача, представленого LLM природною мовою. Потім створений запит запускається до бази даних для отримання відповідного контексту. Нарешті контекст використовується для доповнення підказки введення для кроку підсумовування.
Гіпотеза Q4 полягала в тому, що для кращого запам’ятовування етапу пошуку, зокрема для числового набору даних, їм потрібно було спочатку згенерувати SQL із запитання користувача. Вважалося, що це не тільки підвищить точність, але й збереже контекст у сфері бізнесу для даного питання. Для генерації запитів і генерації точного SQL Q4 потрібно було надати LLM повну інформацію про структуру свого набору даних. Це означало, що підказка повинна була включити схему бази даних, кілька зразків рядків даних і зрозумілі людині пояснення полів для полів, які нелегко зрозуміти.
Виходячи з початкових випробувань, цей метод показав чудові результати. LLM, оснащений усією необхідною інформацією, зміг згенерувати правильний SQL, який потім запускався з базою даних для отримання правильного контексту. Поекспериментувавши з цією ідеєю, Q4 вирішив, що генерація SQL — це шлях до вирішення проблем вилучення контексту для їх власного конкретного набору даних.
Давайте почнемо з опису загального підходу до рішення, розберемо його на компоненти, а потім складемо частини разом.
Огляд рішення
LLM — це великі моделі з мільярдами параметрів, які попередньо навчені з використанням дуже великих обсягів даних із різних джерел. Завдяки широті наборів навчальних даних, очікується, що магістри права матимуть загальні знання в різних сферах. LLM також відомі своїми здібностями до міркування, які відрізняються від однієї моделі до іншої. Цю загальну поведінку можна оптимізувати для конкретного домену чи галузі шляхом подальшої оптимізації базової моделі з використанням додаткових даних попереднього навчання для конкретного домену або шляхом тонкого налаштування за допомогою даних із мітками. Враховуючи правильний контекст, метадані та інструкції, добре підібраний LLM загального призначення може створювати якісний SQL, якщо він має доступ до потрібного доменно-специфічного контексту.
У випадку використання Q4 ми починаємо з перекладу запитання клієнта на SQL. Ми робимо це, комбінуючи запитання користувача, схему бази даних, кілька прикладів рядків бази даних і докладні інструкції як підказку LLM для створення SQL. Отримавши SQL, ми можемо запустити етап перевірки, якщо це буде необхідно. Коли ми задоволені якістю SQL, ми виконуємо запит до бази даних, щоб отримати відповідний контекст, який нам потрібен для наступного кроку. Тепер, коли у нас є релевантний контекст, ми можемо надіслати вихідне запитання користувача, отриманий контекст і набір інструкцій назад до LLM для отримання остаточної підсумкової відповіді. Мета останнього кроку полягає в тому, щоб LLM узагальнив результати та надав контекстну та точну відповідь, яку потім можна передати користувачеві.
Вибір LLM, який використовується на кожному етапі процесу, сильно впливає на точність, вартість і продуктивність. Вибір платформи чи технології, які дають змогу гнучко перемикатися між LLM в межах одного сценарію використання (кілька поїздок LLM для різних завдань) або в різних варіантах використання, може бути корисним для оптимізації якості результату, затримки та вартості . Ми розглядаємо вибір LLM далі в цій публікації.
Будівельні блоки рішення
Тепер, коли ми висвітлили підхід на високому рівні, давайте заглибимося в деталі, починаючи з будівельних блоків рішення.
Amazon Bedrock
Amazon Bedrock — це повністю керований сервіс, який пропонує вибір високопродуктивних FM від провідних компаній, зокрема AI21 Labs, Anthropic, Cohere, Meta, Stability AI та Amazon. Amazon Bedrock також пропонує широкий набір інструментів, необхідних для створення генеративних програм ШІ, спрощення процесу розробки та підтримки конфіденційності та безпеки. Крім того, за допомогою Amazon Bedrock ви можете вибирати з різних варіантів FM і додатково налаштовувати моделі в приватному порядку, використовуючи власні дані, щоб узгодити відповіді моделей з вимогами вашого сценарію використання. Amazon Bedrock повністю безсерверний і не має базової інфраструктури для керування розширенням доступу до доступних моделей через єдиний API. Нарешті, Amazon Bedrock підтримує кілька вимог щодо безпеки та конфіденційності, зокрема вимоги HIPAA та відповідність GDPR.
У рішенні Q4 ми використовуємо Amazon Bedrock як безсерверний будівельний блок моделі на основі API на основі багатьох основ. Оскільки ми маємо намір здійснити кілька поїздок до LLM в рамках одного сценарію використання, на основі типу завдання ми можемо вибрати модель, яка є найбільш оптимальною для конкретного завдання, будь то генерація SQL, перевірка чи підсумовування.
LangChain
LangChain це платформа інтеграції та оркестровки з відкритим кодом із набором готових модулів (введення/виведення, пошук, ланцюжки та агенти), які можна використовувати для інтеграції та оркестровки завдань між FM, джерелами даних та інструментами. Фреймворк полегшує створення генеративних додатків штучного інтелекту, які вимагають оркестрування кількох кроків для отримання бажаного результату, без необхідності писати код з нуля. LangChain підтримує Amazon Bedrock як багатофункціональний API моделі.
Що стосується конкретного випадку використання Q4, ми використовуємо LangChain для координації та оркестровки завдань у нашому робочому процесі, включаючи підключення до джерел даних і LLM. Цей підхід спростив наш код, оскільки ми можемо використовувати існуючі модулі LangChain.
SQLDatabaseChain
SQLDatabaseChain це ланцюжок LangChain, який можна імпортувати з langchain_experimental. SLDatabaseChain спрощує створення, впровадження та виконання SQL-запитів за допомогою ефективних перетворень тексту в SQL і реалізацій.
У нашому прикладі використання ми використовуємо SQLDatabaseChain у генерації SQL, спрощуючи та організовуючи взаємодію між базою даних і LLM.
Набір даних
Наш структурований набір даних може зберігатися в базі даних SQL, озері даних або сховищі даних, якщо ми підтримуємо SQL. У нашому рішенні ми можемо використовувати будь-який тип набору даних із підтримкою SQL; це слід абстрагувати від рішення та жодним чином не змінювати рішення.
Деталі реалізації
Тепер, коли ми дослідили підхід до рішення, компоненти рішення, вибір технології та інструменти, ми можемо зібрати частини воєдино. На наступній діаграмі показано наскрізне рішення.
Розглянемо деталі впровадження та послідовність процесу.
Згенеруйте SQL-запит
Для спрощення кодування ми використовуємо існуючі фреймворки. Ми використовуємо LangChain як оркестровку. Ми починаємо з етапу введення, де отримуємо запитання користувача природною мовою.
На цьому першому етапі ми беремо ці вхідні дані та генеруємо еквівалентний SQL, який ми можемо запустити з базою даних для вилучення контексту. Для створення SQL ми використовуємо SQLDatabaseChain, який покладається на Amazon Bedrock для доступу до бажаного LLM. Завдяки Amazon Bedrock, використовуючи єдиний API, ми отримуємо доступ до низки базових LLM і можемо вибрати правильний для кожної LLM-тури, яку ми здійснюємо. Спочатку ми встановлюємо з’єднання з базою даних і отримуємо необхідну схему таблиці разом із деякими зразками рядків із таблиць, які ми маємо намір використовувати.
Під час нашого тестування ми виявили, що 2–5 рядків даних таблиці достатньо, щоб надати достатньо інформації для моделі, не додаючи зайвих непотрібних витрат. Трьох рядків було достатньо, щоб забезпечити контекст, не перевантажуючи модель надто великим введенням. У нашому випадку використання ми почали з Anthropic Клод V2. Модель відома своїм розширеним міркуванням і чіткими контекстними відповідями, якщо їй надається правильний контекст і інструкції. Як частину інструкцій ми можемо включити більше уточнюючих деталей до LLM. Наприклад, ми можемо описати цю колонку Comp_NAME
означає назву компанії. Тепер ми можемо створити підказку, об’єднавши запитання користувача як є, схему бази даних, три приклади рядків із таблиці, яку ми маємо намір використовувати, і набір інструкцій для генерації необхідного SQL у чистому форматі SQL без коментарів чи доповнень.
Усі об’єднані елементи введення вважаються підказкою введення моделі. Добре спроектована підказка введення, адаптована до бажаного синтаксису моделі, сильно впливає як на якість, так і на продуктивність результату. Вибір моделі для використання для конкретного завдання також важливий не лише тому, що це впливає на якість результату, але й тому, що це впливає на вартість і продуктивність.
Далі в цьому дописі ми обговорюємо вибір моделі, оперативну розробку й оптимізацію, але варто зазначити, що на етапі генерації запиту ми помітили, що Claude Instant зміг отримати порівняльні результати, особливо коли запитання користувача було сформульоване добре, а не настільки складне. Однак Claude V2 показав кращі результати навіть із більш складним і непрямим введенням користувача. Ми дізналися, що хоча в деяких випадках Клод Інстант може забезпечити достатню точність за кращої затримки та ціни, наш випадок генерації запитів краще підходив для Claude V2.
Перевірте SQL-запит
Наш наступний крок полягає в тому, щоб переконатися, що LLM успішно згенерував правильний синтаксис запиту і що запит має контекстний сенс, враховуючи схеми бази даних і надані приклади рядків. Для цього етапу перевірки ми можемо повернутися до власної перевірки запиту в SQLDatabaseChain або запустити другу поїздку до LLM, включно з запитом, згенерованим разом із інструкцією перевірки.
Якщо ми використовуємо LLM для етапу перевірки, ми можемо використовувати той самий LLM, що й раніше (Claude V2), або менший, більш продуктивний LLM для простішого завдання, наприклад Claude Instant. Оскільки ми використовуємо Amazon Bedrock, це має бути дуже простим налаштуванням. Використовуючи той самий API, ми можемо змінити назву моделі в нашому виклику API, який піклується про зміни. Важливо зазначити, що в більшості випадків менший LLM може забезпечити кращу ефективність як щодо вартості, так і затримки, і його слід розглядати, якщо ви отримуєте бажану точність. У нашому випадку тестування показало, що згенерований запит завжди точний і має правильний синтаксис. Знаючи це, ми змогли пропустити цей етап перевірки та заощадити на затримці та вартості.
Виконайте SQL-запит
Тепер, коли ми маємо перевірений SQL-запит, ми можемо запустити SQL-запит до бази даних і отримати відповідний контекст. Це має бути простий крок.
Ми беремо згенерований контекст, надаємо його LLM за нашим вибором із початковим запитанням користувача та деякими інструкціями та просимо модель створити контекстне та чітке резюме. Потім ми представляємо згенероване резюме користувачеві як відповідь на початкове запитання, узгоджене з контекстом, отриманим із нашого набору даних.
Для LLM, який бере участь у етапі підсумовування, ми можемо використовувати або Titan Text Express, або Claude Instant. Вони обидва представили б хороші варіанти для підсумкового завдання.
Інтеграція додатків
Можливість чат-бота Q&A є одним із сервісів ШІ Q4. Щоб забезпечити модульність і масштабованість, Q4 будує служби ШІ як мікросервіси, які доступні для програм Q4 через API. Цей підхід на основі API забезпечує плавну інтеграцію з екосистемою платформи Q4 і полегшує надання можливостей служб ШІ для повного набору додатків платформи.
Основна мета служб штучного інтелекту – надати прості можливості для отримання даних із будь-якого загальнодоступного чи закритого джерела даних, використовуючи природну мову як вхідні дані. Крім того, служби штучного інтелекту надають додаткові рівні абстракції, щоб забезпечити виконання функціональних і нефункціональних вимог, таких як конфіденційність і безпека даних. Наступна діаграма демонструє концепцію інтеграції.
Проблеми впровадження
На додаток до проблем, пов’язаних із характером структурованого числового набору даних, який ми обговорювали раніше, Q4 зіткнувся з низкою інших проблем впровадження, які необхідно було вирішити.
LLM вибір і продуктивність
Вибір правильного LLM для завдання має вирішальне значення, оскільки це безпосередньо впливає на якість результату, а також на продуктивність (затримка в обидві сторони). Ось деякі фактори, які впливають на процес відбору LLM:
- Тип LLM – Спосіб розробки FM і вихідні дані, на яких попередньо навчена модель, визначають типи завдань, з якими LLM буде добре працювати, і наскільки добре це буде. Наприклад, текстова LLM була б хорошою для генерації тексту та резюмування, тоді як модель тексту до зображення або зображення до тексту була б більше орієнтована на завдання аналітики та генерації зображень.
- Розмір LLM – Розміри FM вимірюються кількістю параметрів моделі, які має конкретна модель, зазвичай у мільярдах для сучасних LLM. Як правило, чим більша модель, тим дорожче початкове навчання або подальше тонке налаштування. З іншого боку, загалом, для тієї самої архітектури моделі, що більша модель, то ми очікуємо, що вона буде розумнішою у виконанні типу завдань, на які вона спрямована.
- продуктивність LLM – Як правило, що більша модель, то більше часу потрібно для створення виводу, припускаючи, що ви використовуєте однакові параметри обчислень і вводу/виводу (підказка та розмір виводу). Крім того, для однакового розміру моделі продуктивність залежить від оптимізації підказки, розміру маркерів вводу-виводу, а також від чіткості та синтаксису підказки. Добре розроблена підказка разом із оптимізованим розміром маркера вводу-виводу може покращити час відповіді моделі.
Тому, оптимізуючи своє завдання, враховуйте такі найкращі методи:
- Виберіть модель, яка підходить для поставленого завдання
- Виберіть найменший розмір моделі, яка може забезпечити потрібну вам точність
- Оптимізуйте структуру підказки та будьте якомога точнішими з інструкціями, щоб їх було легко зрозуміти моделі
- Використовуйте найменшу підказку для введення, яка може надати достатню кількість інструкцій і контексту для досягнення необхідного рівня точності
- Обмежте вихідний розмір до найменшого розміру, який може бути значущим для вас і задовольнити ваші вихідні вимоги
Беручи до уваги вибір моделі та фактори оптимізації продуктивності, ми взялися за роботу над оптимізацією нашого сценарію генерації SQL. Після деякого тестування ми помітили, що за наявності правильного контексту та інструкцій Claude Instant із такими самими швидкими даними створюватиме SQL порівнянної якості з Claude V2 за набагато кращої продуктивності та ціни. Це вірно, коли введення користувача є більш прямим і простішим за своєю природою. Для більш складних вхідних даних Claude V2 був необхідний для досягнення бажаної точності.
Застосовуючи ту саму логіку до завдання підсумовування, ми дійшли висновку, що використання Claude Instant або Titan Text Express забезпечить необхідну точність із набагато кращою продуктивністю, ніж використання більшої моделі, такої як Claude V2. Titan Text Expressed також запропонував краще співвідношення ціни та якості, як ми обговорювали раніше.
Виклик оркестровки
Ми зрозуміли, що потрібно багато чого організувати, перш ніж ми зможемо отримати змістовну вихідну відповідь на запитання користувача. Як показано в огляді рішення, процес передбачав кілька переплетених відвідувань бази даних і кілька переплетених відвідувань LLM. Якби ми створювали з нуля, нам довелося б зробити значні інвестиції в недиференційований важкий підйом лише для того, щоб підготувати базовий код. Ми швидко перейшли до використання LangChain як оркестровки, скориставшись перевагами спільноти з відкритим кодом і повторно використовуючи наявні модулі, не винаходячи колеса.
Завдання SQL
Ми також зрозуміли, що генерувати SQL не так просто, як механізми вилучення контексту, такі як семантичний пошук або використання вбудовування. Спершу нам потрібно отримати схему бази даних і кілька прикладів рядків, щоб включити їх у підказку LLM. Існує також етап перевірки SQL, де нам потрібно було взаємодіяти як з базою даних, так і з LLM. SQLDatabaseChain був очевидним вибором інструменту. Оскільки це частина LangChain, його було легко адаптувати, і тепер ми можемо керувати генерацією SQL і перевіркою за допомогою ланцюжка, мінімізуючи обсяг роботи, яку нам потрібно виконати.
Проблеми продуктивності
Завдяки використанню Claude V2 і після належного швидкого проектування (про яке ми говоримо в наступному розділі) ми змогли створити високоякісний SQL. Враховуючи якість створеного SQL, ми почали дивитися на те, яку цінність насправді додає етап перевірки. Після подальшого аналізу результатів стало зрозуміло, що якість створеного SQL була незмінно точною таким чином, що робило несприятливими витрати/вигоди від додавання етапу перевірки SQL. У кінцевому підсумку ми скасували етап перевірки SQL без негативного впливу на якість результату та скоротили час проходження перевірки SQL.
На додаток до оптимізації для більш економічного та ефективного LLM для етапу підсумовування, ми змогли використати Titan Text Express, щоб отримати кращу продуктивність і економічну ефективність.
Подальша оптимізація продуктивності передбачала тонке налаштування процесу генерації запитів за допомогою ефективних методів оперативного проектування. Замість того, щоб надавати велику кількість токенів, увага була зосереджена на наданні найменшої кількості вхідних токенів у правильному синтаксисі, який навчена розуміти модель, і з мінімальним, але оптимальним набором інструкцій. Ми докладніше обговоримо це в наступному розділі — це важлива тема, яка застосовна не лише тут, але й в інших випадках використання.
Швидке проектування та оптимізація
Ви можете налаштувати Claude на Amazon Bedrock для різних бізнес-випадків використання, якщо використати правильні оперативні методи розробки. Клод здебільшого діє як розмовний помічник, який використовує формат «людина/помічник». Клода навчають заповнювати текст для ролі помічника. Враховуючи інструкції та бажані швидкі завершення, ми можемо оптимізувати наші підказки для Клода за допомогою кількох методів.
Ми починаємо з правильно відформатованого шаблону підказки, який дає дійсне завершення, а потім можемо додатково оптимізувати відповіді, експериментуючи з підказками з різними наборами вхідних даних, які репрезентують дані реального світу. Під час розробки шаблону підказки рекомендується отримувати багато вхідних даних. Ви також можете використовувати окремі набори даних швидкої розробки та тестових даних.
Ще один спосіб оптимізувати відповідь Клода — експериментувати та повторювати, додаючи правила, інструкції та корисні оптимізації. За допомогою цих оптимізацій ви можете переглядати різні типи завершень, наприклад, сказавши Клоду згадати «я не знаю», щоб запобігти галюцинаціям, розмірковуючи крок за кроком, використовуючи оперативне з’єднання, даючи простір «думати», коли це генерує відповіді , а також повторна перевірка розуміння та точності.
Давайте скористаємося завданням створення запиту та обговоримо деякі прийоми, які ми використовували для оптимізації нашого підказки. Було кілька основних елементів, які принесли користь нашим зусиллям із створення запитів:
- Використання правильного синтаксису людина/помічник
- Використання тегів XML (Клод поважає та розуміє теги XML)
- Додавання чітких інструкцій для моделі для запобігання галюцинаціям
У наступному загальному прикладі показано, як ми використовували синтаксис людина/помічник, застосовували XML-теги та додавали інструкції, щоб обмежити виведення SQL і дати команду моделі сказати «вибачте, я не можу допомогти», якщо вона не може створити відповідний SQL . XML-теги використовувалися для оформлення інструкцій, додаткових підказок, схеми бази даних, додаткових пояснень таблиці та прикладів рядків.
Кінцевий робочий розчин
Після того, як ми розглянули всі проблеми, виявлені під час перевірки концепції, ми виконали всі вимоги до рішення. Q4 був задоволений якістю SQL, створеного LLM. Це стосується простих завдань, які вимагали лише речення WHERE для фільтрації даних, а також складніших завдань, які вимагали контекстних агрегацій за допомогою GROUP BY і математичних функцій. Наскрізна затримка загального рішення була в межах того, що було визначено як прийнятне для даного випадку використання — однозначні секунди. Усе це сталося завдяки вибору оптимального LLM на кожному етапі, належному швидкому розробці, виключенню етапу перевірки SQL і використанню ефективного LLM для етапу підсумовування (Titan Text Express або Claude Instant).
Варто зазначити, що використання Amazon Bedrock як повністю керованої служби та можливість мати доступ до набору LLM через той самий API дозволили експериментувати та легко перемикатися між LLM шляхом зміни назви моделі у виклику API. Завдяки такому рівню гнучкості Q4 зміг вибрати найефективніший LLM для кожного виклику LLM на основі характеру завдання, будь то створення запиту, перевірка чи підсумовування.
Висновок
Не існує єдиного рішення, яке б відповідало всім випадкам використання. У підході RAG якість результату сильно залежить від надання правильного контексту. Вилучення правильного контексту є ключовим, і кожен набір даних відрізняється своїми унікальними характеристиками.
У цій публікації ми продемонстрували, що для числових і структурованих наборів даних використання SQL для вилучення контексту, який використовується для розширення, може призвести до кращих результатів. Ми також продемонстрували, що такі фреймворки, як LangChain, можуть мінімізувати зусилля з кодування. Крім того, ми обговорили необхідність мати можливість перемикатися між LLM в межах одного сценарію використання, щоб досягти найбільш оптимальної точності, продуктивності та вартості. Нарешті, ми підкреслили, як Amazon Bedrock, будучи безсерверним і з різноманітними LLM під капотом, забезпечує гнучкість, необхідну для створення безпечних, продуктивних і економічно оптимізованих програм з найменшою кількістю важких робіт.
Розпочніть свій шлях до створення генеративних програм із підтримкою ШІ, визначивши варіант використання, який має значення для вашого бізнесу. Як з’ясувала команда Q4, генерація SQL може кардинально змінити правила створення інтелектуальних програм, які інтегруються з вашими сховищами даних, розкриваючи потенціал прибутку.
Про авторів
Тамер Соліман є старшим архітектором рішень в AWS. Він допомагає клієнтам незалежних постачальників програмного забезпечення (ISV) впроваджувати інновації, будувати та масштабувати AWS. Він має понад два десятиліття досвіду роботи в галузі консалтингу, навчання та професійних послуг. Він багатопатентний винахідник із трьома виданими патентами, і його досвід охоплює кілька технологічних областей, включаючи телекомунікації, мережі, інтеграцію додатків, AI/ML та розгортання хмарних технологій. Він спеціалізується на роботі з мережами AWS і має глибоку пристрасть до машинної адаптації, ШІ та Generative AI.
Мані Хануджа є технічним керівником – Generative AI Specialists, автором книги – Applied Machine Learning and High Performance Computing on AWS, і членом ради директорів ради жінок у виробничій освіті. Вона керує проектами машинного навчання (ML) у різних областях, таких як комп’ютерне бачення, обробка природної мови та генеративний ШІ. Вона допомагає клієнтам створювати, навчати та розгортати великі моделі машинного навчання в масштабі. Вона виступає на внутрішніх і зовнішніх конференціях, таких як re:Invent, Women in Manufacturing West, вебінарах YouTube і GHC 23. У вільний час вона любить довго бігати вздовж пляжу.
Станіслав Єщенко є архітектором програмного забезпечення в Q4 Inc.. Він має більш ніж десятирічний досвід у галузі розробки програмного забезпечення та системної архітектури. Його різноманітний досвід, який охоплює такі ролі, як технічний керівник і старший розробник повного стеку, сприяє його внеску в просування інновацій платформи Q4. Станіслав прагне просувати технічні інновації та формувати стратегічні рішення в галузі.
- Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
- PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
- PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
- ПлатонЕСГ. вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
- PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
- джерело: https://aws.amazon.com/blogs/machine-learning/how-q4-inc-used-amazon-bedrock-rag-and-sqldatabasechain-to-address-numerical-and-structured-dataset-challenges-building-their-qa-chatbot/
- : має
- :є
- : ні
- :де
- $UP
- 100
- 118
- 125
- 15%
- 23
- 7
- a
- здібності
- здатність
- Здатний
- абстракція
- достаток
- прийнятний
- доступ
- доступною
- рахунки
- точність
- точний
- Achieve
- через
- акти
- насправді
- пристосовувати
- доданий
- додати
- доповнення
- Додатковий
- Додатково
- доповнення
- адреса
- адресований
- Регулювання
- просунутий
- просування
- Перевага
- після
- проти
- агенти
- сукупність
- AI
- Послуги ШІ
- випадки використання ai
- AI / ML
- спрямований
- вирівнювати
- вирівняні
- ВСІ
- дозволяти
- дозволено
- по
- Також
- хоча
- am
- Amazon
- Amazon Web Services
- кількість
- суми
- an
- аналіз
- аналітики
- аналітика
- аналізувати
- Аналізуючи
- та
- Інший
- відповідь
- Відповіді
- Антропний
- будь-який
- все
- API
- Інтерфейси
- застосовно
- додаток
- застосування
- прикладної
- підхід
- архітектура
- ЕСТЬ
- AS
- запитати
- Активи
- Помічник
- допомога
- асортимент
- At
- збільшення
- збільшено
- автор
- доступний
- знати
- AWS
- назад
- фон
- заснований
- основний
- BE
- Пляж
- стали
- оскільки
- було
- перед тим
- початок
- поведінка
- буття
- вважається,
- корисний
- КРАЩЕ
- передового досвіду
- Краще
- між
- мільярди
- Блокувати
- блоки
- рада
- рада директорів
- книга
- Бот
- обидва
- широта
- Перерва
- широкий
- будувати
- Створюємо
- Будує
- побудований
- бізнес
- але
- by
- call
- прийшов
- CAN
- Може отримати
- можливості
- можливості
- капітал
- Ринки капіталу
- який
- випадок
- випадків
- ланцюг
- ланцюга
- виклик
- проблеми
- виклики будівництва
- зміна
- Перемикач
- заміна
- характеристика
- Chatbot
- chatbots
- вибір
- Вибирати
- Вибираючи
- ясність
- очистити
- ясно
- ближче
- хмара
- код
- Кодування
- Колонка
- комбінований
- об'єднання
- Приходити
- коментарі
- комерційно
- спілкуватися
- Комунікація
- співтовариство
- Компанії
- компанія
- порівнянний
- завершення
- комплекс
- складність
- дотримання
- Компоненти
- осягнути
- обчислення
- комп'ютер
- Комп'ютерне бачення
- обчислення
- концепція
- укладає
- уклали
- висновок
- проводиться
- конференції
- З'єднуватися
- З'єднувальний
- зв'язку
- Вважати
- вважається
- беручи до уваги
- послідовно
- Складається
- складається
- будувати
- консалтинг
- зміст
- контекст
- контекстуальний
- продовжувати
- постійно
- внески
- звичайний
- діалоговий
- конверсій
- перероблений
- координуючи
- Core
- виправити
- Коштувати
- може
- створювати
- критичний
- CRM
- вирішальне значення
- клієнт
- Клієнти
- щодня
- дані
- Озеро даних
- точки даних
- конфіденційність даних
- Конфіденційність та безпека даних
- наука про дані
- керовані даними
- Database
- набори даних
- Дати
- десятиліття
- десятиліття
- вирішене
- Вирішивши
- присвячених
- вважається
- певний
- Попит
- продемонстрований
- демонструє
- залежить
- розгортання
- розгортання
- описувати
- описують
- бажаний
- докладно
- деталі
- визначає
- Розробник
- розвивається
- розробка
- різний
- прямий
- безпосередньо
- Директори
- обговорювати
- обговорювалися
- занурення
- Різне
- do
- домен
- домени
- Не знаю
- подвійна перевірка
- вниз
- водіння
- два
- під час
- динамічний
- кожен
- Раніше
- легко
- екосистема
- Освіта
- Ефективний
- ефективність
- ефективний
- продуктивно
- зусилля
- зусилля
- або
- елементи
- права
- усуваючи
- з'являються
- працевлаштований
- дозволяє
- кінець
- кінець в кінець
- що закінчився
- займатися
- зачеплення
- Машинобудування
- досить
- забезпечувати
- обладнаний
- Еквівалент
- ІС Г
- особливо
- встановити
- оцінки
- оцінка
- Навіть
- Події
- Кожен
- приклад
- Приклади
- існуючий
- очікувати
- очікуваний
- дорогий
- досвід
- експеримент
- Експерименти
- експерт
- експертиза
- Розвіданий
- експрес
- виражений
- розширення
- зовнішній
- витяг
- видобуток
- стикаються
- полегшує
- фактори
- швидкий темп
- сприятливий
- реально
- кілька
- поле
- Поля
- заповнювати
- фільтрувати
- остаточний
- в кінці кінців
- фінансовий
- фінансові дані
- Перший
- Гнучкість
- потік
- Сфокусувати
- стежити
- після
- для
- формат
- Вперед
- виховання
- знайдений
- фонд
- FRAME
- Рамки
- каркаси
- Безкоштовна
- від
- Повний
- Повний стек
- повністю
- функціональний
- Функції
- далі
- гра
- змінювач гри
- GDPR
- Відповідність GDPR
- орієнтована
- Загальне
- породжувати
- генерується
- генерує
- породжує
- покоління
- генеративний
- Генеративний ШІ
- отримати
- отримання
- Давати
- даний
- дає
- дає
- Go
- мета
- Цілі
- добре
- надається
- великий
- Group
- Зростання
- було
- рука
- щасливий
- Мати
- має
- he
- зі штаб-квартирою
- важкий
- важкий підйом
- допомога
- допомагає
- її
- тут
- Високий
- високопродуктивний
- високоякісний
- вище
- найвищий
- Виділено
- основний момент
- дуже
- підказки
- його
- історія
- капот
- Як
- Однак
- HTTPS
- людина
- читається людиною
- i
- ідея
- ідентифікований
- ідентифікує
- if
- зображення
- Impact
- вплив
- впливає
- Вплив
- здійснювати
- реалізація
- реалізації
- реалізовані
- наслідки
- важливо
- удосконалювати
- in
- В інших
- Инк
- включати
- У тому числі
- Augmenter
- зростаючий
- незалежний
- осіб
- промисловість
- інформація
- Інфраструктура
- початковий
- спочатку
- оновлювати
- інновація
- вхід
- витрати
- мить
- установи
- інструкції
- інтегрувати
- інтеграція
- мати намір
- взаємодіяти
- Взаємодії
- внутрішній
- переплетені
- в
- інтуїтивний
- інвестиції
- інвестор
- Інвестори
- залучений
- емітенти
- ісв
- IT
- ЙОГО
- подорож
- JPG
- просто
- тримати
- ключ
- Знання
- знання
- відомий
- Labs
- озеро
- ландшафт
- мова
- великий
- більше
- останній
- нарешті
- Затримка
- пізніше
- шарів
- вести
- провідний
- Веде за собою
- вчений
- вивчення
- найменш
- Led
- Уроки
- Уроки, витягнуті
- рівень
- підйомний
- як
- Сподобалося
- LLM
- логіка
- Лондон
- Довго
- подивитися
- шукати
- серія
- машина
- навчання за допомогою машини
- made
- головний
- головним чином
- Mainstream
- підтримувати
- Підтримка
- зробити
- РОБОТИ
- управляти
- вдалося
- управління
- виробництво
- багато
- ринок
- Аналіз ринку
- дані ринку
- ринки
- відповідає
- математичний
- Може..
- значущим
- означав
- механізми
- Зустрічатися
- член
- зустрів
- Meta
- метадані
- метод
- Методологія
- мікросервіс
- мінімальний
- мінімізація
- змішувати
- ML
- модель
- Моделі
- сучасний
- Модулі
- більше
- найбільш
- в основному
- переміщення
- багато
- багато
- множинний
- ім'я
- рідний
- Природний
- Обробка природних мов
- природа
- необхідно
- Необхідність
- необхідний
- негативно
- мережа
- Нові
- Нью-Йорк
- наступний
- немає
- увагу
- відзначивши,
- зараз
- номер
- номера
- мета
- Очевидний
- of
- від
- запропонований
- Пропозиції
- офіцерів
- офіси
- часто
- on
- ONE
- тільки
- відкрити
- з відкритим вихідним кодом
- оптимальний
- оптимізація
- Оптимізувати
- оптимізований
- оптимізуючий
- Опції
- or
- оркестровка
- оркестровка
- порядок
- оригінал
- Інше
- наші
- вихід
- над
- загальний
- огляд
- пригнічує
- власний
- яка перебуває у власності
- власність
- параметри
- частина
- приватність
- Пройшов
- пристрасть
- патент
- Патенти
- шлях
- Виконувати
- продуктивність
- виконанні
- вибирати
- частин
- платформа
- plato
- Інформація про дані Платона
- PlatoData
- Play
- точка
- точок
- позитивний
- це можливо
- пошта
- потенціал
- влада
- повноваження
- практики
- переважним
- представити
- представлений
- запобігати
- price
- Принципи
- недоторканність приватного життя
- Конфіденційність та безпека
- процес
- обробка
- виробляти
- Вироблений
- Продукти
- професійний
- глибокий
- проект
- проектів
- підказок
- доказ
- доказ концепції
- правильний
- власником
- доведений
- забезпечувати
- за умови
- забезпечує
- забезпечення
- громадськість
- публічні компанії
- публічно
- мета
- put
- Питання та відповіді
- якість
- запити
- питання
- швидко
- лапки
- Ранжування
- швидше
- RE
- готовий
- Реальний світ
- зрозумів,
- отримати
- рекомендований
- облік
- посилання
- регулюється
- відносини
- відносини
- доречний
- Звіти
- представник
- представляє
- представляє
- вимагати
- вимагається
- Вимога
- ресурс
- поважають
- поважає
- відповідь
- відповіді
- обмежити
- результати
- revenue
- повернути
- рецензування
- право
- ризики
- Роль
- ролі
- Кімната
- круглий
- Правила
- прогін
- пробіжки
- то ж
- Незадоволений
- задоволений
- зберегти
- say
- масштабованість
- шкала
- наука
- подряпати
- безшовні
- плавно
- Пошук
- другий
- seconds
- розділ
- безпечний
- безпеку
- побачити
- вибір
- Продавці
- послати
- старший
- сенс
- окремий
- Серія
- Без сервера
- обслуговування
- Послуги
- комплект
- набори
- кілька
- формуючи
- акціонера
- Акціонери
- вона
- Повинен
- показав
- показаний
- Шоу
- значний
- простий
- простий
- спрощений
- спростити
- спрощення
- один
- Розмір
- розміри
- менше
- розумний
- розумнішими
- Софтвер
- розробка програмного забезпечення
- рішення
- Рішення
- деякі
- складний
- Source
- Джерела
- напруга
- прольоти
- Говорить
- Фахівці
- спеціалізується
- конкретний
- конкретно
- Стабільність
- стек
- Стажування
- ставки
- стояти
- стенди
- старт
- почалася
- Починаючи
- Заява
- залишатися
- Крок
- заходи
- акції
- Фондова біржа
- зберігати
- магазинів
- просто
- Стратегічний
- структура
- структурований
- Згодом
- успіх
- Успішно
- такі
- достатній
- підходящий
- набір
- підсумовувати
- РЕЗЮМЕ
- підтримка
- Опори
- спостереження
- перемикач
- синтаксис
- система
- таблиця
- з урахуванням
- Приймати
- прийняті
- приймає
- взяття
- Завдання
- завдання
- команда
- технології
- технічний
- методи
- Технологія
- телеком
- говорять
- шаблон
- тест
- Тестування
- Тести
- текст
- ніж
- Дякую
- Що
- Команда
- Капітал
- їх
- потім
- Там.
- Ці
- вони
- Мислення
- це
- три
- через
- по всьому
- час
- Часовий ряд
- times
- велетень
- до
- сьогоднішній
- разом
- знак
- Жетони
- занадто
- інструмент
- інструменти
- тема
- Торонто
- до
- поїзд
- навчений
- Навчання
- угода
- Transactions
- перетворення
- подорож
- правда
- Довіряйте
- ПЕРЕГЛЯД
- два
- тип
- Типи
- типово
- не в змозі
- при
- що лежить в основі
- розуміти
- розуміння
- розумієш
- зрозуміла
- створеного
- розблокування
- непотрібний
- us
- використання
- використання випадку
- використовуваний
- користувач
- зручно
- використання
- використовує
- дійсний
- перевірка достовірності
- значення
- різноманітність
- різний
- продавець
- перевірка
- перевірено
- перевірити
- дуже
- viable
- вид
- Віртуальний
- бачення
- ходити
- хотів
- було
- шлях..
- we
- Web
- веб-сервіси
- Вебінари
- веб-сайт
- ДОБРЕ
- пішов
- були
- West
- Що
- Колесо
- коли
- в той час як
- який
- в той час як
- волі
- з
- в
- без
- жінки
- слова
- Work
- працював
- робочий
- робочий
- вартість
- б
- запис
- написати код
- XML
- ще
- йорк
- Ти
- вашу
- YouTube
- зефірнет