ДалееСледующее руководство
Как писать сценарии и макросы для электронных таблиц с помощью ИИ
Технический
Техническое РУКОВОДСТВО
Написание SQL-запросов с помощью ИИ означает описание вопроса, на который вы хотите получить ответ, на простом английском языке, предоставление модели определений таблиц и столбцов, а также составление, объяснение или оптимизацию SQL для вас.
Это важно, поскольку аналитики, маркетологи и разработчики могут получать ответы из баз данных гораздо быстрее, если они проверяют полученные результаты на соответствие реальным данным, прежде чем доверять им.
Большие языковые модели изучали SQL на основе огромного количества общедоступного кода, документации и форумов вопросов и ответов, поэтому они хорошо умеют создавать синтаксически корректные запросы. Чего они не могут знать, так это вашей базы данных. Без вашей схемы модель угадывает имена таблиц, такие как «пользователи» или «заказы», и имена столбцов, такие как «create_at», и запрос может завершиться неудачно или, что еще хуже, запуститься и вернуть неправильный ответ. Единственное самое большое улучшение, которое вы можете сделать, — это вставить схему: операторы CREATE TABLE или список таблиц, столбцов, типов данных и того, как таблицы связаны через внешние ключи. Добавление нескольких образцов строк и примечаний к бизнес-правилам, таким как «отмененные заказы имеют статус = 'X'» или «суммы хранятся в центах», предотвращает множество скрытых ошибок. Укажите также диалект SQL. PostgreSQL, MySQL, SQL Server, SQLite, BigQuery и Snowflake различаются функциями даты, конкатенацией строк, LIMIT и TOP и другими деталями. Запрос, написанный для одного, может завершиться неудачно или вести себя по-другому на другом. Надежный рабочий процесс состоит из четырех этапов: дайте контекст, задайте вопрос на простом английском языке, попросите модель объяснить свой запрос словами, а затем протестируйте. Шаг объяснения важен, поскольку он выявляет недоразумения, такие как подсчет строк вместо отдельных клиентов или использование INNER JOIN, которое автоматически отбрасывает клиентов, у которых нет заказов. Распространенные заблуждения включают убеждение, что выполняемый запрос корректен (неправильное соединение может привести к двойному подсчету сумм), что выходные данные AI можно безопасно запускать в рабочей среде (операции UPDATE или DELETE без предложения WHERE изменяют каждую строку) и что вы должны делиться реальными данными. Обычно одной схемы достаточно, что также позволяет не допускать попадания информации о клиентах в чат. Общие помощники, такие как ChatGPT, Claude и Gemini, инструменты кодирования, такие как GitHub Copilot, и помощники искусственного интеллекта, встроенные во многие редакторы баз данных, лучше всего работают по одному и тому же шаблону.
Архитектурные решения влияют на производительность и эксплуатационные расходы на протяжении многих лет.
Техническое образование помогает командам выбрать правильный стек, а не только самый новый.
Лучший инженерный выбор снижает вероятность возникновения проблем с надежностью на производстве.
Преобразование текста в SQL — это активная область исследований, и поставщики баз данных и аналитики все чаще встраивают помощников на естественном языке в редакторы запросов и инструменты бизнес-аналитики. Эти помощники работают лучше всего, когда они могут читать метаданные схемы, описания столбцов и семантический уровень, который определяет такие термины, как «активный клиент», один раз для всех. Точность в беспорядочных реальных базах данных по-прежнему отстает от результатов чистых тестов, поскольку неоднозначные бизнес-определения — это человеческая проблема, а не проблема синтаксиса. Навык, который останется ценным, — это точное знание того, какой вопрос вы задаете, и как проверить правильность ответа, даже несмотря на то, что составление самого SQL-кода становится более автоматизированным.
Владелец небольшого интернет-магазина вставляет операторы CREATE TABLE в таблицы заказов и клиентов, спрашивает: «Какие 10 клиентов потратили больше всего за последние 90 дней?» и запускает полученный запрос к копии базы данных, прежде чем использовать цифры.
Аналитик данных вставляет медленный запрос отчета из 60 строк вместе с выводом EXPLAIN ANALYZE и просит ИИ предложить индекс и переписать коррелированный подзапрос как соединение.
Новый сотрудник, унаследовавший старый ежемесячный отчет, просит ИИ объяснить существующий запрос построчно, включая то, что делает каждый JOIN и GROUP BY, прежде чем что-либо менять.
Разработчик, переносящий отчет из MySQL в PostgreSQL, просит ИИ преобразовать такие функции, как DATE_FORMAT, в to_char PostgreSQL и составить список любых различий в поведении, которые стоит протестировать.
Оптимизация одного теста может скрыть более широкие недостатки системы.
Затраты на инфраструктуру и техническое обслуживание часто недооцениваются.
Пробелы в безопасности и наблюдаемости могут увеличиваться по мере усложнения систем.
Определите целевые показатели задержки, качества и стоимости перед внедрением.
Тестирование при реалистичной нагрузке и условиях данных.
Мониторинг прибора на наличие ошибок, дрейфа и влияния пользователя.
Перед масштабированием подготовьте пути отката и реагирования на инциденты.
Free newsletter
Three verified AI stories every weekday morning, written in plain English. Free forever, no ads.
One email each weekday. Unsubscribe in one click. We never sell or share your address.
Test yourself
Instant feedback on every answer, and a shareable certificate with a verifiable ID once you pass a course.
Support free AI education. AI Understanding is a 501(c)(3) nonprofit — no ads, no paywall, ever. Make a donation
Написание SQL-запросов с помощью ИИ означает описание вопроса, на который вы хотите получить ответ, на простом английском языке, предоставление модели определений таблиц и столбцов, а также составление, объяснение или оптимизацию SQL для вас. Это важно, поскольку аналитики, маркетологи и разработчики могут получать ответы из баз данных гораздо быстрее, если они проверяют полученные результаты на соответствие реальным данным, прежде чем доверять им.
Без вашей схемы модель должна угадывать имена таблиц и столбцов. Придание ему реальной структуры и бизнес-правил устраняет большую часть этих догадок.
PostgreSQL, MySQL, SQL Server, SQLite, BigQuery и Snowflake по-разному обрабатывают даты, конкатенацию строк и ограничения строк, поэтому запрос для одного может прерваться на другом.
Это разветвление соединения: соединение с таблицей с несколькими строками на заказ дублирует общую сумму каждого заказа. Перед соединением заполнитель нужной зернистости, часто с КТР.
Объяснение простым языком позволяет сравнить то, что на самом деле делает запрос, с тем, что вы имели в виду, выявляя логические ошибки, которые по-прежнему выполняются без нареканий.
COUNT(*) подсчитывает строки независимо от содержимого, а COUNT(столбец) игнорирует строки, в которых этот столбец имеет значение NULL. Их смешивание незаметно меняет результаты.
Продолжайте учиться
Другие руководства, выбранные по этой теме
ДалееСледующее руководство
Как писать сценарии и макросы для электронных таблиц с помощью ИИ
Технический