text to sql bedrock workshop
Module 4: Security for Text-to-SQL
Корпоративные хранилища данных представляют собой крупнейшую инвестицию в технологии для компаний во всех отраслях за последние 20 лет. Хотя генеративный ИИ показал многообещающие результаты в создании нового контента и понимании больших массивов информации в неструктурированном формате, как он улучшит потребление данных, в которые организации так много вложили, чтобы сделать их полезными? Эти источники данных являются одними из самых надежных в организации и во многих случаях определяют решения на самом высоком уровне руководства.
С момента своего создания в 70-х годах язык структурных запросов (SQL) был наиболее универсальным языком для взаимодействия с базами данных, но для понимания данных по-прежнему необходимо глубокое понимание теории множеств, типов данных и отношений внешних ключей. . Генеративный ИИ предлагает способ восполнить этот пробел в знаниях и навыках путем перевода вопросов на естественном языке в действительный SQL-запрос.
В число систем и людей, которые могут извлечь выгоду из этого шаблона доступа к базам данных, входят люди, не имеющие технических знаний, которые хотят включить реляционные источники данных в свой процесс, например агенты по обслуживанию клиентов и сотрудники колл-центров. Кроме того, технические варианты использования включают конвейеры «Извлечение-Преобразование-Загрузка», существующие архитектуры извлечения дополненной генерации (RAG), которые интегрируют реляционные базы данных, а также организации, которые имеют дело с платформой данных, слишком большой для разумной навигации по ней в изоляции.
Самые сложные компоненты создания точного SQL-запроса на естественном языке — это те же самые, с которыми мы, возможно, сталкивались, когда были новичками в этом языке. Такие концепции, как выявление связей внешних ключей, разбиение вопроса на более мелкие вложенные запросы и правильное соединение таблиц, являются одними из самых сложных компонентов генерации SQL-запросов. По данным исследователей, более 50% тестов генерации SQL терпят неудачу только при связывании схем и объединениях.
Помимо этих основных компонентов запроса, каждое ядро базы данных имеет свой собственный синтаксис, который может гарантировать умение писать действительный запрос. Кроме того, во многих организациях существует множество перекрывающихся атрибутов данных (например, значение агрегируется в одной таблице и не агрегируется в другой), а также сокращенные имена столбцов, для правильного использования которых требуются племенные знания.
Итак, насколько мы близки к решению этой проблемы? Сообщество объединилось вокруг двух основных таблиц лидеров, в которых ранжируются наиболее успешные подходы с размеченными наборами данных: Spider и BIRD. Обе таблицы лидеров отдают приоритет наиболее важному показателю для измерения точности любого подхода к решению этой проблемы, называемому точностью выполнения (EX). Эта метрика просто сравнивает сгенерированный SQL-запрос с помеченным SQL-запросом, чтобы определить, соответствует он или нет. Кроме того, SPIDER измеряет точность совпадения точного набора (EM) — действительно ли возвращенный набор результатов ответил на вопрос, независимо от того, как был написан запрос, — а BIRD предлагает показатель валидной эффективности (VES) — меру производительности сгенерированного SQL-запроса. Вы можете прочитать больше о каждом наборе контрольных данных на соответствующих страницах.
Наборы данных Spider и BIRD зарекомендовали себя как авторитетные и надежные наборы данных для тестирования методов преобразования текста в SQL и даже для точной настройки моделей. На протяжении всего этого модуля мы будем обращаться к этим наборам данных и соответствующим таблицам лидеров, чтобы продемонстрировать наиболее надежные подходы к преобразованию текста в SQL.
Согласно таблице лидеров BIRD, уровень точности выполнения задачи преобразования текста в SQL составляет 60%. Хотя это все еще значительно ниже человеческих возможностей, обратите внимание, что за год мы перешли от базовой модели T5, работающей с 7% EM, к году спустя, когда EM превысил 60%. Мы рады видеть, как эта ситуация улучшится в следующем году, поскольку эти модели и методы продолжают исследоваться.
Важно отметить, что эти методы оптимизированы для единственной цели — создания правильного SQL-запроса. Эти таблицы лидеров не оценивают некоторые важные аспекты этих методов, особенно скорость. Многие из этих методов демонстрируют скорость сквозной цепочки подсказок, превышающую несколько секунд, что недопустимо для многих сценариев использования бизнес-аналитики с нулевым выстрелом. Кроме того, многие из них также делают несколько выводов в LLM для завершения необходимых рассуждений, что может значительно увеличить стоимость запроса.
Этот семинар предназначен для развития методов преобразования текста в SQL, начиная с надежного оперативного проектирования. Весь код представлен в виде блокнотов Jupyter, размещенных в SageMaker Studio. Когда вы будете готовы приступить к работе, перейдите в раздел «Настройка», чтобы начать развертывание необходимых ресурсов для этого семинара.
Ниже представлено краткое содержание семинара:
