Forwarded from Daily Coding 🔥
🛠 Panther — это удобная автономная библиотека для парсинга веб-сайтов и проведения сквозных тестов с использованием реальных браузеров.
🌍 Сайт
Daily Coding #инструменты #PHP
🌍 Сайт
Daily Coding #инструменты #PHP
Forwarded from Дизайн-кабак
Aigul’ Gambarova: «7 опорных точек в оценке продукта: взгляд со стороны бизнеса, пользователя и дизайна»
https://designpub.ru/b70d645bbc6b
https://designpub.ru/b70d645bbc6b
Forwarded from Цифровой геноцид
Онтологии, ИИ и знаниевые графы
https://www.youtube.com/watch?v=Sir59K8ZDPU
Хорошая лекция о том, как могут быть использованы онтологии для работы с агентами - и как это может функционировать. Нечто подобное делал для некоторых коммерческих проектов, хотя там причины были тривиальны
Фрэнк Койл (Frank Coyle) описывает два метода создания онтологий, то, что 15 лет назад еще можно было называть инженерией знаний: "подход сверху вниз — собираешь экспертов, и они садятся и анализируют предметную область, придумывают сущности. Что у нас есть? У нас есть заказы на покупку, у нас есть клиенты, у нас есть представители клиентов, и мы их структурируем. Формируются связи и свойства" и есть второй подход снизу вверх, когда уже реакции клиентов, пользователей и новые сущности наносятся на сложившийся граф в онтологии базы знаний. https://schema.org/ до сих пор хранит таксономии для всего на свете - я так понимаю, что это язык XML о котором подзабыли
OWL - Web Ontology Language для описания онтологий обладал уже необходимыми свойствами транзитивности и поддерживался веб консорциумом.
Современные агенты-ЛЛМ, которые работают в циклах, могут быть существенно улучшены и избавлены от родовых травм и ошибок - если в момент детекции проблем будут получать обращение к формальной онтологии. Так как агенты являются чисто стохастическими языковыми моделями, то обращение к формальной схеме для проверки может качественно улучшить качество ответа. Френк приводит пример, что повторный возврат средств по одному и тому же заказу — это проблема, которая может возникнуть у языковой модели. Но онтологии могут это отловить, тогда как в обычном тексте это отследить очень сложно. Выплата, отправленная в службу поддержки вместо покупателя — это тоже можно отловить с помощью OWL disjoint property, когда «клиент» и «представитель поддержки» — это две отдельные сущности.
"На самом деле мысль, которую я хочу донести, такая: используйте reasoner (машину логического вывода), построенный на онтологии, чтобы отслеживать LLM, иметь ограждения (guardrails), которые держат её честной. Под этими ограждениями я имею в виду вот эти вспомогательные технологии — RDFS и OWL"
https://www.youtube.com/watch?v=Sir59K8ZDPU
Хорошая лекция о том, как могут быть использованы онтологии для работы с агентами - и как это может функционировать. Нечто подобное делал для некоторых коммерческих проектов, хотя там причины были тривиальны
Фрэнк Койл (Frank Coyle) описывает два метода создания онтологий, то, что 15 лет назад еще можно было называть инженерией знаний: "подход сверху вниз — собираешь экспертов, и они садятся и анализируют предметную область, придумывают сущности. Что у нас есть? У нас есть заказы на покупку, у нас есть клиенты, у нас есть представители клиентов, и мы их структурируем. Формируются связи и свойства" и есть второй подход снизу вверх, когда уже реакции клиентов, пользователей и новые сущности наносятся на сложившийся граф в онтологии базы знаний. https://schema.org/ до сих пор хранит таксономии для всего на свете - я так понимаю, что это язык XML о котором подзабыли
OWL - Web Ontology Language для описания онтологий обладал уже необходимыми свойствами транзитивности и поддерживался веб консорциумом.
Современные агенты-ЛЛМ, которые работают в циклах, могут быть существенно улучшены и избавлены от родовых травм и ошибок - если в момент детекции проблем будут получать обращение к формальной онтологии. Так как агенты являются чисто стохастическими языковыми моделями, то обращение к формальной схеме для проверки может качественно улучшить качество ответа. Френк приводит пример, что повторный возврат средств по одному и тому же заказу — это проблема, которая может возникнуть у языковой модели. Но онтологии могут это отловить, тогда как в обычном тексте это отследить очень сложно. Выплата, отправленная в службу поддержки вместо покупателя — это тоже можно отловить с помощью OWL disjoint property, когда «клиент» и «представитель поддержки» — это две отдельные сущности.
"На самом деле мысль, которую я хочу донести, такая: используйте reasoner (машину логического вывода), построенный на онтологии, чтобы отслеживать LLM, иметь ограждения (guardrails), которые держат её честной. Под этими ограждениями я имею в виду вот эти вспомогательные технологии — RDFS и OWL"
YouTube
Why Agentic Systems Need Ontologies — Frank Coyle, UC Berkeley
A second refund on the same order. A payout sent to the support desk instead of the buyer. An order status of "probably shipped." These are the kinds of mistakes a probabilistic agent makes and a paragraph of instructions cannot reliably stop. Frank Coyle…
Forwarded from Shock Design
This media is not supported in your browser
VIEW IN TELEGRAM
В macOS 27 Apple наконец унифицировала радиусы скругления окон. Больше никаких различий между системными и сторонними приложениями.
Forwarded from Цифровой геноцид
Вот и Анатолий вторит с публикациями в ведущие журналы
Forwarded from MB3R Lab
alphaXiv
Mass vs. Meaning in the Age of AI: From Artifact Inflation to Assurance Density
This work introduces a conceptual framework, "Mass vs. Meaning," to integrate generative AI into risk-bearing software development while maintaining assurance. It establishes a provenance-sensitive...
Уже почти год сражаюсь с рецензентами Communications of the ACM и уверен, что лучше этой версии не напишу. Пока рецензенты докапываются до формы, суть статьи рискует растерять новизну. Поэтому даже если им опять что-то не понравится, переделывать ничего не хочу — решил опубликовать препринт.
Подтолкнул меня к этому сегодняшний разбор свежего отчёта DX Q2 2026. Судя по цифрам, объём AI-сгенерированного кода превысил 50%, медианный размер PR вырос на 64%, а расходы на ИИ скакнули с $1.5 тыс. до $44 тыс. за год. При этом доверие к изменениям упало, доля инноваций не выросла, а сэкономленное время поглотили ревью и CI/CD. Индустрия производит всё больше кода, но доверия к нему становится только меньше. В посте отлично разобрана диагностика проблемы, однако индустриальных протоколов её решения всё ещё нет. Во всяком случае в публичном поле.
А это именно то, о чем моя статья. Когда ИИ генерирует патч, тесты, документацию и ревью-комментарии на основе пересекающейся информации, зелёные тесты и выросший coverage ничего не доказывают. Они лишь подтверждают соответствие собственным, возможно ошибочным, предположениям модели. Возникает artifact inflation. Количество объектов в Pull Request растет, остаточный риск не снижается. При этом нагрузка на команду остаётся прежней.
В статье я предлагаю правило допуска для рискованных изменений. Оценка должна вестись не по количеству сгенерированных строк, а через assurance density. Этот показатель должен отражать, насколько пакет изменений действительно покрывает заявленные риски и снижает неопределенность, не раздувая при этом ресурсы на ревью и поддержку.
Сразу оговорюсь, что это opinion-статья. В ней нет эмпирической валидации или метрик с продакшена. Но это и не голословная демагогия — концепция опирается на строгий формальный аппарат assurance cases, чтобы дать индустрии рабочий язык и конкретные правила до того, как проблема окончательно выйдет из-под контроля.
Собственно, препринт.
Подтолкнул меня к этому сегодняшний разбор свежего отчёта DX Q2 2026. Судя по цифрам, объём AI-сгенерированного кода превысил 50%, медианный размер PR вырос на 64%, а расходы на ИИ скакнули с $1.5 тыс. до $44 тыс. за год. При этом доверие к изменениям упало, доля инноваций не выросла, а сэкономленное время поглотили ревью и CI/CD. Индустрия производит всё больше кода, но доверия к нему становится только меньше. В посте отлично разобрана диагностика проблемы, однако индустриальных протоколов её решения всё ещё нет. Во всяком случае в публичном поле.
А это именно то, о чем моя статья. Когда ИИ генерирует патч, тесты, документацию и ревью-комментарии на основе пересекающейся информации, зелёные тесты и выросший coverage ничего не доказывают. Они лишь подтверждают соответствие собственным, возможно ошибочным, предположениям модели. Возникает artifact inflation. Количество объектов в Pull Request растет, остаточный риск не снижается. При этом нагрузка на команду остаётся прежней.
В статье я предлагаю правило допуска для рискованных изменений. Оценка должна вестись не по количеству сгенерированных строк, а через assurance density. Этот показатель должен отражать, насколько пакет изменений действительно покрывает заявленные риски и снижает неопределенность, не раздувая при этом ресурсы на ревью и поддержку.
Сразу оговорюсь, что это opinion-статья. В ней нет эмпирической валидации или метрик с продакшена. Но это и не голословная демагогия — концепция опирается на строгий формальный аппарат assurance cases, чтобы дать индустрии рабочий язык и конкретные правила до того, как проблема окончательно выйдет из-под контроля.
Собственно, препринт.
Forwarded from Daily Coding 🔥
🛠 pgbench — это простая программа для проведения тестов производительности в PostgreSQL. Она снова и снова выполняет одну и ту же последовательность SQL-команд, возможно, в нескольких параллельных сеансах работы с базой данных, а затем вычисляет среднюю скорость обработки транзакций (количество транзакций в секунду). По умолчанию pgbench тестирует сценарий, основанный на TPC-B, с пятью командами SELECT, UPDATE и INSERT на транзакцию. Однако можно легко протестировать и другие сценарии, написав собственные скрипты транзакций.
🌍 Сайт
Daily Coding #инструменты #SQL
🌍 Сайт
Daily Coding #инструменты #SQL
Forwarded from Shock Design
This media is not supported in your browser
VIEW IN TELEGRAM
В Sphere arena состоялся необычный показ классического фильма «Волшебник страны Оз» (1939). С помощью нейросетей Google восстановил и улучшил качество оригинальной ленты, адаптировав её для показа на гигантском сферическом экране с разрешением 16 000×16 000 пикселей.