Расскажите, пожалуйста, подробнее о некоторых моментах:
На каких конкретно задачах вы проводили эксперимент?
Как именно агенты сами назначали себе роли или выбирали специализации? И как в вашем понимании соотносятся роль и специализация? Вот представим, что перед многоагентной системой читателей Хабра поставлена задача прокомментировать вашу статью. Нам конечно можно назначить роли рецензентов/комментаторов/советчиков/критиков/эксперт и т.д., но в моем представлении каждый придет со своим набором знаний и даст комментарий из которого и будет выведена специализация: но как назвать эту конкретную специализацию, есть ли у нее имя? Не окажемся ли мы просто комментаторами с разными специализациями (злой/добрый/компетентный/въедливый/специализирующийся на чем-то комментатор) В вашем случае как именуются и различаются между собой все 5006 специализаций? Не является ли роль просто более общим по отношению к специализации понятием?
Как агенты определяют, что им надо отказаться от какой-либо задачи?
Нет ли проблем с ростом контекста для каждого агента? В моем понимании в задачи координатора как раз входит недопущение неконтролируемого роста контекста.
Иногда одна точка выхода из функции может усложнять ее логику, но по моему мнению влияет скорее положительно. Те же PMD и Checkstyle для Java включают соответствующие правила.
Справедливости ради, к их реализации есть вопросы, например, при перегрузке того же equals часто удобнее делать return в случае непрохождения проверки типа или, например, хочется выбросить исключение в функции, помеченной @ NonNull, а дополнительные проверки делать не хочется.
Однако, на мой взгляд, эти проблемы перевешиваются такими плюсами как:
Удобство отладки. Можно гарантировано поставить точку останова на единственный return и ждать.
Упрощение потока управления и затрат на понимание кода: чтобы понять, что будет возвращено функцией не требуется анализировать весь код, в котором return могут вызываться в произвольных местах: внутри условий, циклов, условий в циклах и т.д.
>Ну, не так уж чтоб совсем никакой
Если в базе не было внешних ключей (или других ограничений), то, наверное ценность есть) А вот если ключи были, дропнулись при генерации и не восстановились, то это скорее вред)
С ссылочной целостностью интересен скорее аспект, о котором вы выше говорили. То есть не просто соблюсти ограничения (этого ведь и перебором можно достичь), а попытаться смоделировать связи, распределение которых близко к реальному.
В контексте данного инструмента авторы описывают последний шаг: LOADS constraints that it had backed up (Mock-data can fail at this stage if its not able to fix the constraint violations). При этом в логе отражается, все ли ограничения были восстановлены.
В целом согласен с вами, что без ссылочной целостности генерация данных в общем-то ценности никакой не несет, даже если рассматривать кейс подобный моему, когда надо было быстро нагенерить данные для проверки работоспособности пользовательского интерфейса.
Спасибо, внес в статью небольшие правки, акцентирующие внимание на том, что сгенерированные данные удовлетворяют ограничениям целостности. Вообще мне казался достаточно очевидным тот факт, что если ограничения ссылочной целостности восстанавливаются, то и данные в таблицах, в том числе внешние ключи, будут удовлетворять этим ограничениям.
Раз уж пишут про форматы ФНС, дополню, что свои форматы публикует и ПФР, вот здесь: pfr.gov.ru/info/af
Другое дело, что во всех этих форматах с учетом истории их изменения и прочих вводных без пол-литры и не разберешь…
Да, тема очень широкая. Попробую уточнить то, что было бы интересно мне, как человеку с небольшим опытом:
1. Подход — в каких случаях и для решения каких задач обычно используете или пробовали использовать, но отказались. Иными словами ваше практический подход к вопросу бизнес-логики в БД.
2. Естественно интересны наборы рецептов или «трюков» на PL/pgSQL =)
3. Интересная тема триггерных функций
4. Ну и опыт того, как использование функций в запросах сочетается с поведение оптимизатора (IMMUTABLE/STABLE/VOLATILE в определении функций)
Спасибо за увлекательный цикл статей и explain.tensor.ru! Надеюсь, вы продолжите. Было бы интересно узнать об опыте использования триггеров и хранимых функций или же о причинах неиспользования.
Старое — не значит плохое. Я привел пример, чтобы подчеркнуть тенденцию к тому, что в массовом сознании возникает эквивалентность понятий ИИ и нейросетей. Конечно, с увеличением мощностей и количества данных нейросети получили колоссальное развитие. Однако, не располагаю информацией о больших успехах нейросетей в областях, в которых требуется обоснованный вывод или приведение цепочки рассуждений, приведших к результату.
Статья интересная в первую очередь постановкой вопроса. Ведь от вопроса «Слышали о языке Prolog?» один шаг до вопроса «Слышали о логическом программировании?», а дальше пара шагов до вопросов «Слышали о математической логике?» и «Слышали о реляционной теории?». На мой взгляд даже небольшой опыт работы с Prolog или Datalog сильно облегчает жизнь при работе с большинством мейнстримовых языков/фреймворков для работы с запросами к данным — SQL, LINQ, JPQL, GraphQL, да даже всяческие stream в Java и прочие *QL. Я уже не говорю о том, что работа с логическим выводом, цепочками рассуждений, продукционными системами многими вообще забыта. Помню, что в институте частенько слышал утверждение, что «Prolog — язык искусственного интеллекта», а в этом году слышал от членов жюри одного известного конкурса на гранты что «Если у вас нет нейросетей, а всего лишь какой-то набор формул (система продукционных правил), то о каком искусственном интеллекте вы говорите, ха-ха»
Ну одно да потому. Да, со связыванием переменных результаты будут другими, это именно то, для чего я и придумал этот пример. Почему вы решили, что я не понимаю, как он работает?
Я не говорил о вашем понимании или непонимании. В вашем примере возможность чтения «данных, которые ему знать не положено» отнесена к недостаткам SQL, в то время, как это недостаток избранного вами метода формирования запроса, который вы передаете СУБД. Аналогичным образом вы можете передать в функцию eval() код, полученный из входного строкового параметра и попенять на то, что у вас возникла возможность выполнения произвольного кода. Но претензии ведь не к eval(), а к методу его использования.
Я привел этот пример в ответ на утверждение:
«А по существу — аргумент всего один. В БД переносится только бизнес-логика, а не вся логика целиком. Взломанный бэк просто в принципе не может дропнуть базу или прочитать те данные, которые ему знать не положено.»
Опять-таки могу предложить вам модифицировать ваш пример так, чтобы во входной строке был не запрос на выборку данных, а какой-либо DML-оператор, и посмотреть на результат.
Основной метод чтения «данных, которые ему знать не положено» — это SQL-инъекция. Мой пример показывает, что даже если бизнес-логика в БД, то все равно существует возможность использовать SQL-инъекцию для чтения данных, которые знать не положено. Думаете хакер, который взломал бэк, будет связывание переменных использовать?
В этом утверждении я могу частично согласиться с вами, но что значить «хакер взломал бэк»? Если хакер путем формирования запросов выполнил произвольный SQL, то мы возвращаемся к вопросу о том, что параметры в БД надо передавать через связывание. Если же хакер имеет доступ к приложению, то скорее всего ему известны учетные данные подключения к БД и тут ситуация такова, что вопрос совсем не к использованию или неиспользованию хранимых процедур.
Расскажите, пожалуйста, подробнее о некоторых моментах:
На каких конкретно задачах вы проводили эксперимент?
Как именно агенты сами назначали себе роли или выбирали специализации? И как в вашем понимании соотносятся роль и специализация? Вот представим, что перед многоагентной системой читателей Хабра поставлена задача прокомментировать вашу статью. Нам конечно можно назначить роли рецензентов/комментаторов/советчиков/критиков/эксперт и т.д., но в моем представлении каждый придет со своим набором знаний и даст комментарий из которого и будет выведена специализация: но как назвать эту конкретную специализацию, есть ли у нее имя? Не окажемся ли мы просто комментаторами с разными специализациями (злой/добрый/компетентный/въедливый/специализирующийся на чем-то комментатор) В вашем случае как именуются и различаются между собой все 5006 специализаций? Не является ли роль просто более общим по отношению к специализации понятием?
Как агенты определяют, что им надо отказаться от какой-либо задачи?
Нет ли проблем с ростом контекста для каждого агента? В моем понимании в задачи координатора как раз входит недопущение неконтролируемого роста контекста.
Не по тематике, но все зависит от того, как о нем писать: https://habr.com/ru/articles/361755/
Занятно, что на скрине с сообщением о нарушении прав доступа, приведена модалка, которую показывает 1С при этом самом нарушении прав доступа)
Вот в такие моменты понимаешь, почему в SQL
NULL <> NULLи есть всякиеIS DISTINCT FROM<irony>А может не так и плоха идея пускать в интернет только по паспорту или через Госуслуги</irony>
До уровня советских инженеров им еще расти и расти </irony>
Иногда одна точка выхода из функции может усложнять ее логику, но по моему мнению влияет скорее положительно. Те же PMD и Checkstyle для Java включают соответствующие правила.
Справедливости ради, к их реализации есть вопросы, например, при перегрузке того же equals часто удобнее делать return в случае непрохождения проверки типа или, например, хочется выбросить исключение в функции, помеченной
@ NonNull,а дополнительные проверки делать не хочется.Однако, на мой взгляд, эти проблемы перевешиваются такими плюсами как:
Удобство отладки. Можно гарантировано поставить точку останова на единственный
returnи ждать.Упрощение потока управления и затрат на понимание кода: чтобы понять, что будет возвращено функцией не требуется анализировать весь код, в котором
returnмогут вызываться в произвольных местах: внутри условий, циклов, условий в циклах и т.д.Получил такое письмо на почту. Приятного мало. Теперь надеюсь дождаться письма с опровержением. Буду держать вас в курсе </sarcasm>
Спасибо за отзыв и дельное замечание про докер. Добавил в статью ссылку на ваш комментарий.
Если в базе не было внешних ключей (или других ограничений), то, наверное ценность есть) А вот если ключи были, дропнулись при генерации и не восстановились, то это скорее вред)
С ссылочной целостностью интересен скорее аспект, о котором вы выше говорили. То есть не просто соблюсти ограничения (этого ведь и перебором можно достичь), а попытаться смоделировать связи, распределение которых близко к реальному.
В целом согласен с вами, что без ссылочной целостности генерация данных в общем-то ценности никакой не несет, даже если рассматривать кейс подобный моему, когда надо было быстро нагенерить данные для проверки работоспособности пользовательского интерфейса.
Другое дело, что во всех этих форматах с учетом истории их изменения и прочих вводных без пол-литры и не разберешь…
1. Подход — в каких случаях и для решения каких задач обычно используете или пробовали использовать, но отказались. Иными словами ваше практический подход к вопросу бизнес-логики в БД.
2. Естественно интересны наборы рецептов или «трюков» на PL/pgSQL =)
3. Интересная тема триггерных функций
4. Ну и опыт того, как использование функций в запросах сочетается с поведение оптимизатора (IMMUTABLE/STABLE/VOLATILE в определении функций)
Я не говорил о вашем понимании или непонимании. В вашем примере возможность чтения «данных, которые ему знать не положено» отнесена к недостаткам SQL, в то время, как это недостаток избранного вами метода формирования запроса, который вы передаете СУБД. Аналогичным образом вы можете передать в функцию eval() код, полученный из входного строкового параметра и попенять на то, что у вас возникла возможность выполнения произвольного кода. Но претензии ведь не к eval(), а к методу его использования.
Опять-таки могу предложить вам модифицировать ваш пример так, чтобы во входной строке был не запрос на выборку данных, а какой-либо DML-оператор, и посмотреть на результат.
В этом утверждении я могу частично согласиться с вами, но что значить «хакер взломал бэк»? Если хакер путем формирования запросов выполнил произвольный SQL, то мы возвращаемся к вопросу о том, что параметры в БД надо передавать через связывание. Если же хакер имеет доступ к приложению, то скорее всего ему известны учетные данные подключения к БД и тут ситуация такова, что вопрос совсем не к использованию или неиспользованию хранимых процедур.