Если Вы профессиональная ИТ-компания разработчик серьезного ПО, то должны знать, что этот процесс 1в1 соответствует процессу разработки сложного технического изделия. Этому важному пониманию уже как полвека (см книгу Брукса как создаются программные комплексы выпуска где-то 2-ой половины 70'х). Соответственно весь процесс разбивается на строгие этапы на которых работают соответствующие специалисты в своих компетенциях: конструкторы (архитекторы программного продукта), управленцы разработкой (для ИТ это ещё и специалист ведущий внутреннюю базу данных программных компонентов системы), технологи (непосредственные разработчики модульной структуры и БД), рабочие (программисты создающие программный код), контролёры (тестировщики программного кода отдельных модулей и в целом создаваемой системы), специалисты по написанию пользовательский документации. Как видите, разнообразий специалистов работающих в своих компетенциях не мало. Соответственно и информационная поддержка их работы должна быть разбита и строго соответствовать их функциональным обязанностям, а не представлять одну информационную кучу документов и всякого рода наставлений. То есть база знаний (или информационная база данных поддержки разработки) должна состоять из соответствующих разделов в их единой концептуальной целостности. Самый простой вариант её реализации это подобие справочного руководства с подразделами и информацией по каждому из них, в которой содержатся ссылки по выделенным в тексте словам и поиском по ключевым словам. Хороший пример, например, документация по Excel. Эта база знаний поискового типа. В некоторых ситуациях специалисту требуется поддержка принятия решения в зависимости от исходных данных (начальных фактов). Тогда в БЗ должен присутствовать и отрабатывать ее интеллектуальный компонент для соответствующего раздела в форме экспертной системы или обученного AI-агента уже со своей внутренней базой знаний. Как видно из сказанного, создание корпоративной БЗ далеко не тривиальная задача.
Задание чисто гипотетическое, придумано и предлагается исключительно с одной целью: проверить применение алгоритмических знаний в среде СУБД Oracle. Автор оговорил это в самом начале статьи. С другой стороны, на нем же продемонстрировать некоторые приёмы реализации подобных алгоритмов в этой СУБД. На практике же, чтобы не допускать подобных (похожих) ситуаций и заморочек, прежде всего требуется правильно проектировать реляционную модель БД и не скидывать "все в одну кучу", то есть не совмещать физически в одной СУБД обработку (манипулирование) данными (insert, select, updare, delete) и всю алгоритмику бизнес-логики, а разумно распределять их между клиентом и сервером.
Задача интересная, если не соотносить ее с таблицами конкретной СУБД, то, как понимаю, формулируется так:
Имеется массив A с N элементами (74 тыс) в котором есть поле ПОЛ со значением (М или Ж) и пустое поле ФИО.
Имеется 2-ой массив B с K элементами и для каждого отдельно со значениями поля ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО. Причем их сочетание может повторяться в разных элементах.
Требуется по данным массива B заполнить поле ФИО ( фамилия & имя & отчество) в массиве А. Причем чтобы сочетание ФИО встречалось в массиве А только один раз (было уникальным).
Шаги решения по каждому (!) полу в отдельности (сначала для муж, потом для жен):
1.Создать три рабочих пустых массива F, I, O.
2.Последовательно из массива В выбрать не повторяющиеся фамилии, имена, отчества и заполнить ими массивы F, I и O. Если из таблицы CLIENT, то это с помощью 3-ех операторов select с distinct.
Максимальное кол-во НЕ повторяющихся сочетаний "фамилия & имя & отчество" будет равно произведению кол-ва элементов в массивах F, I и O.
3.Организовать вложенные циклы по фамилиям (из F), по именам (из I) , по отчествам (из О) с формированием значения ФИО и вставки его в незаполненный для соответствующего пола элемент массива А.
Сложность реализации зависит от условия: делать только с помощью SQL и возможностями конкретной СУБД, либо комбинацией SQL + язык программирования. Если рассматривать задачу с нахождением данных в оперативной памяти без СУБД, то это уровень хорошей информатики 11-ого класса.
Требуются "управленческие срезы по данным из учётной системы" - это как ?
Все основные пользовательские наборы данных (витрины данных и тд) должные закладываться в функционал ИС ещё "на берегу" при ее проектировании. Отображение данных возможно и с выгрузкой их в Excel с последующей активацией работающего в нем аналитического vba-приложения. Как говорится, просто, ясно, без всяких ухищрений и заморочек.
В чем "фишка" принципиально чего-то нового в анализе данных с помощью генеративных моделей построенных на LLM ? С этого надо было начать рекламировать книгу.
Странная статья и не понятна конечная цель автора. Формально оставаясь ещё до 31.08.26 сотрудником такой компании в заявленной должности и публично в негативе обнародовать о ней свое личное мнение ? Как-то не вяжется и больше походит на сказку.
Принцип "что работает, надёжно и просто, то пусть и работает" относится не только к обычному колесу, но и ко всему остальному, включая программное обеспечение. В данном случае к Excel - гениальной программе табличной обработки данных и их анализу. Спасибо автору статьи за напоминание об этом.
Основное назначение базы знаний (knowledge base) - это фиксация и сохранение знаний в конкретной предметной области для использования их в поддержке принятия решений и сохранения интеллектуального потенциала компании. Об этом ещё было сказано 40 лет назад, когда стали говорить об экспертных системах, использующих базы знаний. Пользовательские инструменты для работы с БЗ должны обладать интеллектуальными способностями, копирующих действия специалистов-экспертов. С развитием современных технологий ИИ открываются новые возможности для создания баз знаний и экспертных систем. Главной проблемой останется широкая и разумная доступность к инструментальным средствам для их создания и их гарантированная поддержка, отсутствие которых в 80'х привело к забытию экспертных систем и баз знаний на долгие годы.
Вариантов на "что делать ?" может быть несколько. В том числе и как в данной статье. Нужно детально знать конкретику: какие в таблице данные, как часто поступают новые, как и какие по времени запрашиваются через select, есть ли в них агрегирование. Завязана ли таблица в запросах с другими таблицами, где они формируются: в разных местах (процедурах) непосредственно в самой СУБД или на клиентах тоже. Вопросов много, но без радикального физического разделения данных не обойтись. Что ж поделаешь, такова цена не качественного начального проектирования структуры БД.
Лечение заболевшего гриппом примочками. Источник проблемы в проектировании структуры БД (не только для postgresql). Физической концентрации в одной таблице терабайтовых данных допускать нельзя в принципе. Часть данных, и/или по времени их возникновения, должны распределяться по нескольким таблицам. Также, в зависимости от задачи, в отдельные таблицы могут выноситься исторические данные агрегированные по дате/времени с удалением начальных данных из рабочих таблиц, но с сохранением их в отдельной архивной БД.
Описанная ситуация типичная, когда в одну БД (не только postgresql) пытаются "запихнуть" все вместе. Это лишний раз подтверждает известную истину: правильно проектировать структуру БД, физически разделять ПО для бизнес-логики от ПО для обработки и доставки данных клиентам. Причем уже на этапе проектирования самой ИС необходимо рассматривать варианты возможного будущего расширение ее функционала и, соответственно, БД. Конечно, можно сказать, что на "берегу" все сразу не предусмотреть. Но надо донести до заказчика, что не продуманные до конца его потребности могут в дальнейшем привести к проблемам. Тип инструментов (выбор ЯП, СУБД) тоже очень важен, но вторичен. Это классика и в этом заключается квалификация разработчика.
Калькулятор жёстко запрограммирован на выполнение указанных команд. Не думаю что ваша голова (не дай бог) работает по запрограммированной кем-то программе. На счёт "понимать" добро пожаловать в толковый словарь русского языка.
Можно масштабировать и на уровень ЭВМ, которая тоже оперирует битами и успешно делает вычисления. Но калькулятор не понимает структуру чисел: сколько в них десятков, сотен, тысяч и тд., что значит дробная часть, смысл отрицательного или простого числа и тд. Поэтому об интеллекте калькулятора и говорить как-то не приходится.
Правильнее говорить не об обучении и до обучении (в корректном понимании этих терминов для человека) языковой модели LLM, а об ее настройке и до настройке по предлагаемому тексту. Ибо такая модель оперирует только отдельными элементами составляющими текст (токенами), устанавливает и фиксирует между ними многочисленные связи, используя их в дальнейшей генерации ей своего текста. Она НЕ оперирует в целом понятиями и объектами, их свойствами и связанными отношениями как это делает человек. В этом принципиальное отличие машинного интеллекта на генеративной модели LLM от интеллекта человека.
Для думающих, конечно же, будет интересно. Модели построенные на LLM (нейронный сети) не ведут понятийные логические рассуждения как это делает человек. Они не оперируют в целом объектами и понятиями, их свойствами и связями, а настроены на генерацию контента используя зафиксированные при обучении связи, корреляции и ссылки только между отдельными элементами текста (его словами и фрагментами) - что должно быть следующим за предыдущим. Внешне результат и его объяснение от такой модели абсолютно ничем не отличается от человеческого, но получен он совершенно другим способом. Поэтому, я в своих комментах на эту тему (которые очень гневно воспринимаются оппонентами) пытаюсь донести, что такие модели, в отличие от человека, не понимают смысла в оперируемой ими информации. А от сюда можно уже делать и другие выводы.
Рано или поздно в законодательном порядке придется принимать уже сейчас назревшее решение: вся публичная информация (включая нормативную) в разных форматах полученная и/или сформированная с помощью технологий "машинного интеллекта" должна автором (авторами) помечаться уже в самом заголовке (преамбуле).
"Запрос, написанный таким образом, что планировщик вынужден строить оптимальный план запроса."
У вас в голове рекурсия уже на полную катушку работает.
Если бы хорошо учили теорию по реляционными базами данных, то должны знать, что прежде всего надо говорить об оптимальной структуре таблиц и связей между ними (модели данных), уровне нормализации, исходя из будущей выборки данных правильного определения индексов для полей. ЭТО является основой оптимальности и быстродействия для работы с базой данных, а НЕ запросы. С помощью запросов (процедур на сервере) и ПО на клиенте, их правильного баланса, реализуется алгоритм обработки и выборки данных для решения конкретной задачи. Сам алгоритм также может быть оптимальным и не оптимальным. Но если у вас не оптимальная структура БД, не оптимальный алгоритм решения задачи, то никакие оптимальные запросы пользы не принесут.
Короче, уважаемый, вам нужно садиться за матчасть, а не напрягаться учить других.
Если Вы профессиональная ИТ-компания разработчик серьезного ПО, то должны знать, что этот процесс 1в1 соответствует процессу разработки сложного технического изделия. Этому важному пониманию уже как полвека (см книгу Брукса как создаются программные комплексы выпуска где-то 2-ой половины 70'х). Соответственно весь процесс разбивается на строгие этапы на которых работают соответствующие специалисты в своих компетенциях: конструкторы (архитекторы программного продукта), управленцы разработкой (для ИТ это ещё и специалист ведущий внутреннюю базу данных программных компонентов системы), технологи (непосредственные разработчики модульной структуры и БД), рабочие (программисты создающие программный код), контролёры (тестировщики программного кода отдельных модулей и в целом создаваемой системы), специалисты по написанию пользовательский документации. Как видите, разнообразий специалистов работающих в своих компетенциях не мало. Соответственно и информационная поддержка их работы должна быть разбита и строго соответствовать их функциональным обязанностям, а не представлять одну информационную кучу документов и всякого рода наставлений. То есть база знаний (или информационная база данных поддержки разработки) должна состоять из соответствующих разделов в их единой концептуальной целостности. Самый простой вариант её реализации это подобие справочного руководства с подразделами и информацией по каждому из них, в которой содержатся ссылки по выделенным в тексте словам и поиском по ключевым словам. Хороший пример, например, документация по Excel. Эта база знаний поискового типа. В некоторых ситуациях специалисту требуется поддержка принятия решения в зависимости от исходных данных (начальных фактов). Тогда в БЗ должен присутствовать и отрабатывать ее интеллектуальный компонент для соответствующего раздела в форме экспертной системы или обученного AI-агента уже со своей внутренней базой знаний. Как видно из сказанного, создание корпоративной БЗ далеко не тривиальная задача.
Задание чисто гипотетическое, придумано и предлагается исключительно с одной целью: проверить применение алгоритмических знаний в среде СУБД Oracle. Автор оговорил это в самом начале статьи. С другой стороны, на нем же продемонстрировать некоторые приёмы реализации подобных алгоритмов в этой СУБД. На практике же, чтобы не допускать подобных (похожих) ситуаций и заморочек, прежде всего требуется правильно проектировать реляционную модель БД и не скидывать "все в одну кучу", то есть не совмещать физически в одной СУБД обработку (манипулирование) данными (insert, select, updare, delete) и всю алгоритмику бизнес-логики, а разумно распределять их между клиентом и сервером.
Задача интересная, если не соотносить ее с таблицами конкретной СУБД, то, как понимаю, формулируется так:
Имеется массив A с N элементами (74 тыс) в котором есть поле ПОЛ со значением (М или Ж) и пустое поле ФИО.
Имеется 2-ой массив B с K элементами и для каждого отдельно со значениями поля ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО. Причем их сочетание может повторяться в разных элементах.
Требуется по данным массива B заполнить поле ФИО ( фамилия & имя & отчество) в массиве А. Причем чтобы сочетание ФИО встречалось в массиве А только один раз (было уникальным).
Шаги решения по каждому (!) полу в отдельности (сначала для муж, потом для жен):
1.Создать три рабочих пустых массива F, I, O.
2.Последовательно из массива В выбрать не повторяющиеся фамилии, имена, отчества и заполнить ими массивы F, I и O. Если из таблицы CLIENT, то это с помощью 3-ех операторов select с distinct.
Максимальное кол-во НЕ повторяющихся сочетаний "фамилия & имя & отчество" будет равно произведению кол-ва элементов в массивах F, I и O.
3.Организовать вложенные циклы по фамилиям (из F), по именам (из I) , по отчествам (из О) с формированием значения ФИО и вставки его в незаполненный для соответствующего пола элемент массива А.
Сложность реализации зависит от условия: делать только с помощью SQL и возможностями конкретной СУБД, либо комбинацией SQL + язык программирования. Если рассматривать задачу с нахождением данных в оперативной памяти без СУБД, то это уровень хорошей информатики 11-ого класса.
Требуются "управленческие срезы по данным из учётной системы" - это как ?
Все основные пользовательские наборы данных (витрины данных и тд) должные закладываться в функционал ИС ещё "на берегу" при ее проектировании. Отображение данных возможно и с выгрузкой их в Excel с последующей активацией работающего в нем аналитического vba-приложения. Как говорится, просто, ясно, без всяких ухищрений и заморочек.
Фантазии на ИТ-тему.
Туфта.
В чем "фишка" принципиально чего-то нового в анализе данных с помощью генеративных моделей построенных на LLM ? С этого надо было начать рекламировать книгу.
Странная статья и не понятна конечная цель автора. Формально оставаясь ещё до 31.08.26 сотрудником такой компании в заявленной должности и публично в негативе обнародовать о ней свое личное мнение ? Как-то не вяжется и больше походит на сказку.
Принцип "что работает, надёжно и просто, то пусть и работает" относится не только к обычному колесу, но и ко всему остальному, включая программное обеспечение. В данном случае к Excel - гениальной программе табличной обработки данных и их анализу. Спасибо автору статьи за напоминание об этом.
Основное назначение базы знаний (knowledge base) - это фиксация и сохранение знаний в конкретной предметной области для использования их в поддержке принятия решений и сохранения интеллектуального потенциала компании. Об этом ещё было сказано 40 лет назад, когда стали говорить об экспертных системах, использующих базы знаний. Пользовательские инструменты для работы с БЗ должны обладать интеллектуальными способностями, копирующих действия специалистов-экспертов. С развитием современных технологий ИИ открываются новые возможности для создания баз знаний и экспертных систем. Главной проблемой останется широкая и разумная доступность к инструментальным средствам для их создания и их гарантированная поддержка, отсутствие которых в 80'х привело к забытию экспертных систем и баз знаний на долгие годы.
Вариантов на "что делать ?" может быть несколько. В том числе и как в данной статье. Нужно детально знать конкретику: какие в таблице данные, как часто поступают новые, как и какие по времени запрашиваются через select, есть ли в них агрегирование. Завязана ли таблица в запросах с другими таблицами, где они формируются: в разных местах (процедурах) непосредственно в самой СУБД или на клиентах тоже. Вопросов много, но без радикального физического разделения данных не обойтись. Что ж поделаешь, такова цена не качественного начального проектирования структуры БД.
Лечение заболевшего гриппом примочками. Источник проблемы в проектировании структуры БД (не только для postgresql). Физической концентрации в одной таблице терабайтовых данных допускать нельзя в принципе. Часть данных, и/или по времени их возникновения, должны распределяться по нескольким таблицам. Также, в зависимости от задачи, в отдельные таблицы могут выноситься исторические данные агрегированные по дате/времени с удалением начальных данных из рабочих таблиц, но с сохранением их в отдельной архивной БД.
Описанная ситуация типичная, когда в одну БД (не только postgresql) пытаются "запихнуть" все вместе. Это лишний раз подтверждает известную истину: правильно проектировать структуру БД, физически разделять ПО для бизнес-логики от ПО для обработки и доставки данных клиентам. Причем уже на этапе проектирования самой ИС необходимо рассматривать варианты возможного будущего расширение ее функционала и, соответственно, БД. Конечно, можно сказать, что на "берегу" все сразу не предусмотреть. Но надо донести до заказчика, что не продуманные до конца его потребности могут в дальнейшем привести к проблемам. Тип инструментов (выбор ЯП, СУБД) тоже очень важен, но вторичен. Это классика и в этом заключается квалификация разработчика.
rPman забалтываешь без внятных контраргументов.
Калькулятор жёстко запрограммирован на выполнение указанных команд. Не думаю что ваша голова (не дай бог) работает по запрограммированной кем-то программе. На счёт "понимать" добро пожаловать в толковый словарь русского языка.
Можно масштабировать и на уровень ЭВМ, которая тоже оперирует битами и успешно делает вычисления. Но калькулятор не понимает структуру чисел: сколько в них десятков, сотен, тысяч и тд., что значит дробная часть, смысл отрицательного или простого числа и тд. Поэтому об интеллекте калькулятора и говорить как-то не приходится.
Правильнее говорить не об обучении и до обучении (в корректном понимании этих терминов для человека) языковой модели LLM, а об ее настройке и до настройке по предлагаемому тексту. Ибо такая модель оперирует только отдельными элементами составляющими текст (токенами), устанавливает и фиксирует между ними многочисленные связи, используя их в дальнейшей генерации ей своего текста. Она НЕ оперирует в целом понятиями и объектами, их свойствами и связанными отношениями как это делает человек. В этом принципиальное отличие машинного интеллекта на генеративной модели LLM от интеллекта человека.
Для думающих, конечно же, будет интересно. Модели построенные на LLM (нейронный сети) не ведут понятийные логические рассуждения как это делает человек. Они не оперируют в целом объектами и понятиями, их свойствами и связями, а настроены на генерацию контента используя зафиксированные при обучении связи, корреляции и ссылки только между отдельными элементами текста (его словами и фрагментами) - что должно быть следующим за предыдущим. Внешне результат и его объяснение от такой модели абсолютно ничем не отличается от человеческого, но получен он совершенно другим способом. Поэтому, я в своих комментах на эту тему (которые очень гневно воспринимаются оппонентами) пытаюсь донести, что такие модели, в отличие от человека, не понимают смысла в оперируемой ими информации. А от сюда можно уже делать и другие выводы.
Рано или поздно в законодательном порядке придется принимать уже сейчас назревшее решение: вся публичная информация (включая нормативную) в разных форматах полученная и/или сформированная с помощью технологий "машинного интеллекта" должна автором (авторами) помечаться уже в самом заголовке (преамбуле).
"Запрос, написанный таким образом, что планировщик вынужден строить оптимальный план запроса."
У вас в голове рекурсия уже на полную катушку работает.
Если бы хорошо учили теорию по реляционными базами данных, то должны знать, что прежде всего надо говорить об оптимальной структуре таблиц и связей между ними (модели данных), уровне нормализации, исходя из будущей выборки данных правильного определения индексов для полей. ЭТО является основой оптимальности и быстродействия для работы с базой данных, а НЕ запросы. С помощью запросов (процедур на сервере) и ПО на клиенте, их правильного баланса, реализуется алгоритм обработки и выборки данных для решения конкретной задачи. Сам алгоритм также может быть оптимальным и не оптимальным. Но если у вас не оптимальная структура БД, не оптимальный алгоритм решения задачи, то никакие оптимальные запросы пользы не принесут.
Короче, уважаемый, вам нужно садиться за матчасть, а не напрягаться учить других.
Тут с вами ставлю жирную точку.