Для думающих, конечно же, будет интересно. Модели построенные на LLM (нейронный сети) не ведут понятийные логические рассуждения как это делает человек. Они не оперируют в целом объектами и понятиями, их свойствами и связями, а настроены на генерацию контента используя зафиксированные при обучении связи, корреляции и ссылки только между отдельными элементами текста (его словами и фрагментами) - что должно быть следующим за предыдущим. Внешне результат и его объяснение от такой модели абсолютно ничем не отличается от человеческого, но получен он совершенно другим способом. Поэтому, я в своих комментах на эту тему (которые очень гневно воспринимаются оппонентами) пытаюсь донести, что такие модели, в отличие от человека, не понимают смысла в оперируемой ими информации. А от сюда можно уже делать и другие выводы.
Рано или поздно в законодательном порядке придется принимать уже сейчас назревшее решение: вся публичная информация (включая нормативную) в разных форматах полученная и/или сформированная с помощью технологий "машинного интеллекта" должна автором (авторами) помечаться уже в самом заголовке (преамбуле).
"Запрос, написанный таким образом, что планировщик вынужден строить оптимальный план запроса."
У вас в голове рекурсия уже на полную катушку работает.
Если бы хорошо учили теорию по реляционными базами данных, то должны знать, что прежде всего надо говорить об оптимальной структуре таблиц и связей между ними (модели данных), уровне нормализации, исходя из будущей выборки данных правильного определения индексов для полей. ЭТО является основой оптимальности и быстродействия для работы с базой данных, а НЕ запросы. С помощью запросов (процедур на сервере) и ПО на клиенте, их правильного баланса, реализуется алгоритм обработки и выборки данных для решения конкретной задачи. Сам алгоритм также может быть оптимальным и не оптимальным. Но если у вас не оптимальная структура БД, не оптимальный алгоритм решения задачи, то никакие оптимальные запросы пользы не принесут.
Короче, уважаемый, вам нужно садиться за матчасть, а не напрягаться учить других.
Каюсь, в SQL-1999 возможность рекурсивных вопросов действительно появилась. Ведущие компании разработчики СУБД ее добавили.
Сам начал работать с реляционными СУБД (SyBase, MS Access, MS SQL) с середины 90'х, тогда был стандарт SQL-92.
Реляционная модель изначально НЕ предназначалась для обработки иерархических (древовидных) структур данных. Поэтому, например, задачу хранения в РБД состава (спецификации) изделия пришлось описывать в 2-ух таблицах: главной и подчинённой в отношении "один ко многим". В главной весь перечень состава изделия (агрегаты, узлы, детали), а в подчинённой списки входящих (по ключам в главной) в них элементов согласно структуре изделия. Полное разузлование изделия с корня, состоящего из нескольких сотен деталей, в БД MS-SQL вер.7 на стороне клиента (программа с рекурсией на VB) с запросами через ODBC к серверу за recordset'ами к хранимым процедурам (store procedure), состоящими только из операторов select, занимало ~ 10-15 секунд на выч.мощностях того времени.
Такого рода задачи, как правило, разбивается на отдельные мелкие шаги, которые, кстати, можно реализовать совершенно разными способами, а не пытаться заморачиваться на написание такого совершенно НЕ воспринимаемого и читабельного текста сверхсложного запроса.
Значит "ваньку валял" и включил режим забалтывания.
SQL это язык выборки и манипулирования данными который лежит в основе реляционной БД. Разработан Э.Коддом в 1972г. В классическом стандарте SQL нет никаких рекурсией. Это уже индивидуальные прибамбасы и наворотки в конкретной СУБД, ее SQL-диалекте и попытки на нем построить свой внутренний язык программирования.
Отрадно. Если, уважаемый, вам не приходилось использовать, например, Designer Queries MS SQL, SQL Query for Oracle, мастера запросов MS Access, Power Query в Excel или что-то подобное, а на веру принимать только разноцветную "капусту" с форумов, тогда и давать такие оценки тому с чем не имел дело как-то не гоже.
Как бы в тему то входил ещё 30 лет назад на SyBase, MS Access, MS SQL 6.5, 7, 2000, ... .
Что вы понимаете под "оптимальным запросом" ? Если можно, то пример, только НЕ самого запроса на SQL, а под-схемы отношений таблиц с полями данных и задачи которую собираетесь решить. А там и потолкуем.
Для работы с реляционными базами данных давно уже имеются свои конструкторы запросов - графические интерактивные инструменты, которые генерируют уже готовый текст запроса на языке SQL. Как правило, такие инструменты поставляются вместе с самой СУБД или сторонними разработчиками. Поэтому необходимость писать текст сложных запроса с вложенными операторами select, join, группированием данных и тому подобное, просто отпадает. Это как писать код программы на ассемблере вместо использования языка программирования высокого уровня.
Об экспертных системах заговорили в начале 70'х когда появились диалоговые средства общения человека с компьютером в текстовом виде. Первые программы с текстовым диалогом считались в то время интеллектуальными, что по нынешним меркам выглядит наивно. Экспертные системы, рекламный бум которых был в 80'х годах, так и НЕ нашли широкого применения по одной причине: отсутствием специализированных инструментальных средств для их разработки. Языки программирования, ориентированные на создания ЭС такие как Clips, Prolog, Refal и др, "зашивали" базу знаний и логику рассуждений непосредственно в код программы и работали сугубо автономно без возможности встраивания как компонента в информационную систему.
Язык SQL для работы с данными неотделим от теории реляционной базы данных. Это как две части одного целого. Поэтому логично, и здравый смысл подсказывает, что описание языка должно быть в одной книге по теории РБД. То есть как отдельным разделом или 2-ой частью книги. Для работы с реляционными базами данных имеются свои конструкторы запросов - графические интерактивные инструменты, которые генерируют уже готовый текст запроса на языке SQL. Как правило, такие инструменты поставляются вместе с СУБД или сторонними разработчиками. Поэтому необходимость писать текст сложных запроса с вложенными операторами select, join, группированием данных и тому подобное, просто отпадает. Это как писать код программы на ассемблере вместо использования языка программирования высокого уровня. Работая с реляционными базами данных вот уже более 30 лет (MS Access, MS SQL), я никогда не пытался использовать SQL вручную. Знать этот язык конечно же необходимо, но использовать лучше высокоуровневые средства построения запросов генерирующих их в SQL. Также это необходимо и потому, что отдельные переменные части запроса приходится формировать программно при обращении к базе данных из приложения. Основа запроса строится конструктором, текст копируется в программу с последующей заменой переменных частей условий конкретными данными в процессе ее выполнения.
По 1-ой ссылке - "Результаты Anthropic и Google подчёркивают прогресс в понимании работы ИИ, но также напоминают о сложности прямых аналогий с человеческим мышлением. В то время как Claude демонстрирует элементы планирования и абстрактных концептов, её «рассуждения» остаются продуктом многослойных математических операций, а НЕ сознательного анализа. Эти работы открывают путь к более прозрачным и контролируемым системам, но также ставят новые вопросы о природе «интеллекта» в машинном обучении".
Поэтому пока корректнее оперировать терминами "человеческий интеллект" и "машинный интеллект" и не пытаться их обобщать.
Добро, на словах ставим тчк. Проверить алгоритм формирования LLM-моделью выходного контента можно только через log-журнал внутренней трассировки его выполнения для заданного на входе запроса (промта).
То есть как начинается анализ текста запроса, как формируется план его обработки и пошаговый цикл формирования выходной информации. Чем оперирует LLM-модель? Извлекает ли смысл из текста, то есть какие понятия (объекты материального мира) в нем присутствуют, по их связям и отношениям в базе знаний строит логические заключения и по ним формирует выходной контент. Если ДА, то это интеллект. Если идёт просто механическая обработка текста как данных, поиск (подбор) в базе подходящего ответа или по обученному "за этим должно следовать это", то это настроенный автомат формирования ответа.
Для думающих, конечно же, будет интересно. Модели построенные на LLM (нейронный сети) не ведут понятийные логические рассуждения как это делает человек. Они не оперируют в целом объектами и понятиями, их свойствами и связями, а настроены на генерацию контента используя зафиксированные при обучении связи, корреляции и ссылки только между отдельными элементами текста (его словами и фрагментами) - что должно быть следующим за предыдущим. Внешне результат и его объяснение от такой модели абсолютно ничем не отличается от человеческого, но получен он совершенно другим способом. Поэтому, я в своих комментах на эту тему (которые очень гневно воспринимаются оппонентами) пытаюсь донести, что такие модели, в отличие от человека, не понимают смысла в оперируемой ими информации. А от сюда можно уже делать и другие выводы.
Рано или поздно в законодательном порядке придется принимать уже сейчас назревшее решение: вся публичная информация (включая нормативную) в разных форматах полученная и/или сформированная с помощью технологий "машинного интеллекта" должна автором (авторами) помечаться уже в самом заголовке (преамбуле).
"Запрос, написанный таким образом, что планировщик вынужден строить оптимальный план запроса."
У вас в голове рекурсия уже на полную катушку работает.
Если бы хорошо учили теорию по реляционными базами данных, то должны знать, что прежде всего надо говорить об оптимальной структуре таблиц и связей между ними (модели данных), уровне нормализации, исходя из будущей выборки данных правильного определения индексов для полей. ЭТО является основой оптимальности и быстродействия для работы с базой данных, а НЕ запросы. С помощью запросов (процедур на сервере) и ПО на клиенте, их правильного баланса, реализуется алгоритм обработки и выборки данных для решения конкретной задачи. Сам алгоритм также может быть оптимальным и не оптимальным. Но если у вас не оптимальная структура БД, не оптимальный алгоритм решения задачи, то никакие оптимальные запросы пользы не принесут.
Короче, уважаемый, вам нужно садиться за матчасть, а не напрягаться учить других.
Тут с вами ставлю жирную точку.
Каюсь, в SQL-1999 возможность рекурсивных вопросов действительно появилась. Ведущие компании разработчики СУБД ее добавили.
Сам начал работать с реляционными СУБД (SyBase, MS Access, MS SQL) с середины 90'х, тогда был стандарт SQL-92.
Реляционная модель изначально НЕ предназначалась для обработки иерархических (древовидных) структур данных. Поэтому, например, задачу хранения в РБД состава (спецификации) изделия пришлось описывать в 2-ух таблицах: главной и подчинённой в отношении "один ко многим". В главной весь перечень состава изделия (агрегаты, узлы, детали), а в подчинённой списки входящих (по ключам в главной) в них элементов согласно структуре изделия. Полное разузлование изделия с корня, состоящего из нескольких сотен деталей, в БД MS-SQL вер.7 на стороне клиента (программа с рекурсией на VB) с запросами через ODBC к серверу за recordset'ами к хранимым процедурам (store procedure), состоящими только из операторов select, занимало ~ 10-15 секунд на выч.мощностях того времени.
Вранье. Если делать все правильно в сочетании клиент - сервер, то будет не хуже, а главное проще для поддержки и с возможностью работы на разных СУБД.
Ответ для Akina.
Такого рода задачи, как правило, разбивается на отдельные мелкие шаги, которые, кстати, можно реализовать совершенно разными способами, а не пытаться заморачиваться на написание такого совершенно НЕ воспринимаемого и читабельного текста сверхсложного запроса.
Значит "ваньку валял" и включил режим забалтывания.
SQL это язык выборки и манипулирования данными который лежит в основе реляционной БД. Разработан Э.Коддом в 1972г. В классическом стандарте SQL нет никаких рекурсией. Это уже индивидуальные прибамбасы и наворотки в конкретной СУБД, ее SQL-диалекте и попытки на нем построить свой внутренний язык программирования.
Тут ставлю с вами точку.
Отрадно. Если, уважаемый, вам не приходилось использовать, например, Designer Queries MS SQL, SQL Query for Oracle, мастера запросов MS Access, Power Query в Excel или что-то подобное, а на веру принимать только разноцветную "капусту" с форумов, тогда и давать такие оценки тому с чем не имел дело как-то не гоже.
Вполне вероятно, но только у тех кто такими инструментами никогда не пользовался.
Как бы в тему то входил ещё 30 лет назад на SyBase, MS Access, MS SQL 6.5, 7, 2000, ... .
Что вы понимаете под "оптимальным запросом" ? Если можно, то пример, только НЕ самого запроса на SQL, а под-схемы отношений таблиц с полями данных и задачи которую собираетесь решить. А там и потолкуем.
Чего мелочиться, сразу уж 512, а ещё лучше 1 Тб. (шутка)
Для работы с реляционными базами данных давно уже имеются свои конструкторы запросов - графические интерактивные инструменты, которые генерируют уже готовый текст запроса на языке SQL. Как правило, такие инструменты поставляются вместе с самой СУБД или сторонними разработчиками. Поэтому необходимость писать текст сложных запроса с вложенными операторами select, join, группированием данных и тому подобное, просто отпадает. Это как писать код программы на ассемблере вместо использования языка программирования высокого уровня.
Об экспертных системах заговорили в начале 70'х когда появились диалоговые средства общения человека с компьютером в текстовом виде. Первые программы с текстовым диалогом считались в то время интеллектуальными, что по нынешним меркам выглядит наивно. Экспертные системы, рекламный бум которых был в 80'х годах, так и НЕ нашли широкого применения по одной причине: отсутствием специализированных инструментальных средств для их разработки. Языки программирования, ориентированные на создания ЭС такие как Clips, Prolog, Refal и др, "зашивали" базу знаний и логику рассуждений непосредственно в код программы и работали сугубо автономно без возможности встраивания как компонента в информационную систему.
Язык SQL для работы с данными неотделим от теории реляционной базы данных. Это как две части одного целого. Поэтому логично, и здравый смысл подсказывает, что описание языка должно быть в одной книге по теории РБД. То есть как отдельным разделом или 2-ой частью книги. Для работы с реляционными базами данных имеются свои конструкторы запросов - графические интерактивные инструменты, которые генерируют уже готовый текст запроса на языке SQL. Как правило, такие инструменты поставляются вместе с СУБД или сторонними разработчиками. Поэтому необходимость писать текст сложных запроса с вложенными операторами select, join, группированием данных и тому подобное, просто отпадает. Это как писать код программы на ассемблере вместо использования языка программирования высокого уровня. Работая с реляционными базами данных вот уже более 30 лет (MS Access, MS SQL), я никогда не пытался использовать SQL вручную. Знать этот язык конечно же необходимо, но использовать лучше высокоуровневые средства построения запросов генерирующих их в SQL. Также это необходимо и потому, что отдельные переменные части запроса приходится формировать программно при обращении к базе данных из приложения. Основа запроса строится конструктором, текст копируется в программу с последующей заменой переменных частей условий конкретными данными в процессе ее выполнения.
Сегодня нахваливают Python, а завтра с уже удвоенной энергией Alligator.
Как это нет ? То есть вы не понимаете как сами строите свои рассуждения, даёте обьяснения и делаете выводы ? Вот это интересная новость !
А LLM, правильно говорите, генерирует свои "размышления", только НЕ так, как это делает человек.
Так как не сойдёмся, то на этом можно поставить в нашей дискуссии точку.
По 1-ой ссылке - "Результаты Anthropic и Google подчёркивают прогресс в понимании работы ИИ, но также напоминают о сложности прямых аналогий с человеческим мышлением. В то время как Claude демонстрирует элементы планирования и абстрактных концептов, её «рассуждения» остаются продуктом многослойных математических операций, а НЕ сознательного анализа. Эти работы открывают путь к более прозрачным и контролируемым системам, но также ставят новые вопросы о природе «интеллекта» в машинном обучении".
Поэтому пока корректнее оперировать терминами "человеческий интеллект" и "машинный интеллект" и не пытаться их обобщать.
Короче, нужна внутренняя трассировка обработки конкретного запроса, а потом и поговорим.Лучше такого, ответ на который (как вы говорите) нет в базе.
Добро, на словах ставим тчк. Проверить алгоритм формирования LLM-моделью выходного контента можно только через log-журнал внутренней трассировки его выполнения для заданного на входе запроса (промта).
То есть как начинается анализ текста запроса, как формируется план его обработки и пошаговый цикл формирования выходной информации. Чем оперирует LLM-модель? Извлекает ли смысл из текста, то есть какие понятия (объекты материального мира) в нем присутствуют, по их связям и отношениям в базе знаний строит логические заключения и по ним формирует выходной контент. Если ДА, то это интеллект. Если идёт просто механическая обработка текста как данных, поиск (подбор) в базе подходящего ответа или по обученному "за этим должно следовать это", то это настроенный автомат формирования ответа.