Во второй части мы рассмотрели аналитическое решение задачи линейной регрессии и наткнулись на ряд неприятностей — сингулярность, плохая обусловленность, вычислительная сложность и т.д.
Логическим продолжением будет изучение (не побоюсь этого слова) сердца машинного обучения: градиентного спуска.
Привет, меня зовут Алексей и я C# разработчик. Однажды передо мной стояла задача написать утилиту для взаимодействия с различными UI-элементами в Windows и во всех популярных браузерах. Сама утилита не была связана с тестированием, но вполне годилась для автоматизации некоторых действий на машине, так как была простой в управлении и интуитивно понятной. Мне понравилось работать в этом направлении и возникла идея создания инструмента, который не будет перегружен широким функционалом RPA решений, но возьмёт от них всё что нужно для тестирования интерфейсов, чтобы получился действительно полезный инструмент-помощник для QA с низким порогом входа.
Как вышло, что опытные венчурные инвесторы Silicon Valley Bank и IT-директора клиентов CrowdStrike принимали решения на основе слухов, игнорируя официальные отчеты и графики? За последние десять лет когнитивная наука накопила массив данных, доказывающий: классическая «модель информационного дефицита» больше не работает.
Статья носит справочный характер и задумана как навигатор по современным исследованиям для специалистов, которым необходимо понимать почему люди верят в опровергаемые мифы. Разберем 6 причин уязвимости — от архитектуры «ленивого мозга» до феномена «потребности в хаосе» и дам ссылки для более глубокого изучения проблемы.
Расскажу, как мы делаем железо для Neko. Взлёты и падения, победы и провалы, всё как мы любим. Фактически, это лог одного из наших чятов про HW.
Вы меняете системный промпт, надеетесь, что все заработало и деплоите фичу в продакшен. На следующее утро прилетает жалоба: агент выдумал дедлайн или проигнорировал важную инструкцию. Вы снова открываете IDE, правите промпт, смотрите глазами на пару примеров — «вроде стало лучше» и цикл вновь повторяется.
Если это ваша повседневная реальность, у нас плохие новости: вы не управляете продуктом, вы играете в лотерею.
В мире, где LLM-агенты становятся основой бизнес-процессов, AI Evals (оценки) — это не дополнительная нагрузка на инженеров, а единственная возможность контролируемых улучшений. Лидеры индустрии, от OpenAI до Anthropic, сходятся в одном: если вы не можете измерить качество работы ИИ - вы не можете им управлять.
Поп-астрология рассказывает про влияние планет, про проработку аспектов. Скептики ждут точных ответов. И вообще, все это окутано туманом мистики, гаданиями на кофейной гуще.
Но давайте отбросим эти глупости из женских журналов. Я не предлагаю верить или не верить. Просто хочу показать, как это работает.
Есть схемотехники в зале?
Когда вся эта астрология появилась, не было схемотехники. Но сейчас она есть, и есть элементная база.
Поэтому предлагаю рассмотреть натальную карту как принципиальную схему.
Большинство советов по сборке Docker заканчиваются на порядке слоёв: сначала копируйте манифесты зависимостей, запускайте менеджер пакетов, затем копируйте остальной исходный код. Это полезно, но недостаточно для инструмента релиза. Инструмент релиза должен отвечать на более сложные вопросы. Какой процесс имел право читать дерево исходного кода? Какие учётные данные достигли сборщика? Был ли сокет Docker предоставлен недоверенной команде? Кэш пришёл из предыдущей ветки, общего бакета или пустого локального сборщика? Может ли агент объяснить, почему сборка была быстрой, без парсинга логов BuildKit? На все эти вопросы поможет ответить torque.
Привет. Меня зовут Николай Пискунов, я руководитель направления Big Data и эксперт курса Cloud DevSecOps по безопасной разработке от Академии вАЙТИ Beeline Cloud. Ранее я уже писал обзорную статью про конкретную реализацию клиента для Ollama. Но чем глубже я погружался в код, тем отчетливее понимал: разговор о конкретном клиенте — это разговор о следствии. А мне хочется поговорить о причине. Об инструменте, который делает возможным любой клиент. О Spring AI.
DevOps и CI/CD эволюционируют в сторону агентных систем: вместо ручных скриптов и разрозненных инструментов — декларативные стеки, верифицируемые планы и автономные агенты, которые выполняют, проверяют и фиксируют доставку. Статья показывает, что Torque — один из возможных путей к такому будущему, где инфраструктура становится предсказуемой, аудируемой и готовой к работе с ИИ-агентами.
Проверили, насколько сильно расходятся результаты расчета, полученные в быстрой 2D-системе инженерного анализа SimPCB Lite, с результатами полноволнового 3D-симулятора Ansys HFSS на примере копланарной линии (CPW) на подложке GaAs. Спойлер: по волновому сопротивлению — меньше 1% во всём диапазоне до 50 ГГц, по потерям — до ~18% на 50 ГГц, но в абсолютных цифрах это 0.04 дБ на линии длиной 2 мм. Читать, если вы проектируете СВЧ МИС и хотите понять, когда достаточно быстрого расчёта, а когда без HFSS не обойтись.
Каждая компания разработчик хочет иметь в своей команде сильных специалистов и зачастую поиск и найм таких спецов ограничивается только бюджетом. Однако, в этой статье мы рассмотрим ситуацию, в которой у нас была возможность нанять гениального одиночку, но в итоге мы получили токсичный актив, разрушивший всю команду.
Один ученик писал экзаменационную работу, а кто-то чужой дописал часть за него. Как мы научили нейросеть распознавать это.
Дано: государственная аттестация, бумажные бланки, никакого онлайн-контроля. Классический способ фальсификации: ученик начинает работу сам, потом часть дописывает кто-то другой: сосед, нанятый человек, преподаватель. Проверяющий смотрит на текст, но не оценивает почерк.
Задача ИИ: поймать фальсификацию почерка без эталона: система не знает заранее, как пишет конкретный ученик. Единственное, от чего можно отталкиваться - начало бланка, мы предполагаем, что первые строки написал сам экзаменуемый.
Цель: определить, написан ли весь бланк экзаменационной работы одним человеком. На входе - скан бланка, порой низкого качества. На выходе — координаты подозрительных фрагментов для ручной проверки. Все это в режиме потоковой обработки. Основной вызов: экзаменационный бланк — это смешанный документ. Рукописный текст соседствует с формулами, графиками, схемами, печатной подложкой бланка.
Ваши вакансии под угрозой! Я откликнусь везде. HH превратил поиск работы в беличье колесо. Зачем монополисту делать так, чтобы вы нашли работу, если выгоднее, чтобы вы её искали?
Каждый разработчик помнит тот самый момент, когда система, которая только что работала идеально, вдруг начинает вести себя так, будто сошла с ума. Когда дашборд в Grafana показывает что-то страшное, а ты стоишь перед ним с кружкой остывшего кофе и не понимаешь, с чего начать.
На нашем мероприятии Avito Go Loto разработчики поделились своим опытом без прикрас. О блоате в полтора терабайта, о девяти инстансах, которые передрались за один звонок, о бэкенд-разработчице, которая в пятницу вечером открыла чужой фронтовый проект, о нагрузочных тестах за несколько месяцев до большой рекламной кампании, и о транзакции, которую забыли закоммитить тоже в пятницу вечером.
Спойлер: все выжили. Но стали другими людьми.
Привет, Хабр!
Когда мы говорим о доверенной операционной системе, быстро выясняется: одного защищенного кода недостаточно. ОС нужна точка опоры еще до того, как начнет работать она сама, — компонент или механизм, с которого начинается доверие ко всей системе. Его называют Root-of-Trust, или корнем доверия.
Для KasperskyOS это практическая инженерная задача. Мы строим ОС на принципах конструктивной безопасности, а значит, доверие должно быть заложено в архитектуру с самого начала, в том числе на уровне взаимодействия с аппаратной платформой. И здесь начинается самое интересное: у разных платформ корень доверия может быть устроен по-разному.
Меня зовут Антон Рыбаков, я руковожу разработкой функций безопасности KasperskyOS в «Лаборатории Касперского». В этой статье разберем, какими бывают корни доверия, как мы работаем с разными реализациями в KasperskyOS и почему для индустрии все острее становится вопрос унификации: единых требований, общего языка описания и понятных правил оценки Root-of-Trust.
Привет, Хабр! Меня зовут Платон Малюгин, я Android Developer в Garage Eight. Мы в компании разрабатываем экосистему инвестиционных продуктов, и недавно на корпоративном хакатоне у нас появилась идея. Мы решили проверить, получится ли управлять торговой платформой — интерфейсом для инвестиций на финансовом и фондовом рынке — через голосовой диалог с ассистентом. Не просто задавать вопросы, а обсуждать рынок, анализировать инструменты и совершать операции.
Более пятнадцати лет я занимаюсь управлением изменениями – внедряю проектное управления и запускаю трансформации. И вот неутешительный вывод: 70% трансформаций, на которые компании тратят годы и миллионы, заканчиваются ничем. Это не мои данные, их регулярно подтверждают многочисленные исследования, включая самое свежее – от компании BCG. Семь из десяти. На каждые три истории успеха приходится семь, о которых стыдливо умалчивают.
Хуже того: в большинстве случаев провал был очевиден еще до запуска. Не в середине, когда уже поздно. В первые недели. Просто слишком много людей поставили на программу свои репутации и бонусы, чтобы признать это вслух.
Есть восемь признаков, по которым я почти со стопроцентной уверенностью предсказываю провал. Если ваша компания соответствует двум-трём пунктам, у меня для вас плохие новости. Если пяти и более – закрывайте программу сегодня, сэкономите всем нервы. Что это за признаки – читайте в статье ниже.
Когда я начинал этот pet-проект, у меня в голове была одна цель: за полтора-два года вытеснить ноунейм-сайты из верхушки выдачи Яндекса и Google по запросам типа «калькулятор бетона», «расчёт утеплителя», «сколько нужно плитки на ванную». Не зайти пятым на странице, не получить какой-то «нормальный трафик», а конкретно занять первое место в нише. Сайт — getmasterok.ru, ему около трёх месяцев. Но какой же я был легкомысленный и как я сильно ошибался.
Амбиция выглядит наивно, и я отдаю себе в этом отчёт. Ниша строительных калькуляторов забита под потолок: десятки доменов, заточенных под партнёрки крупного DIY-ретейла, ещё столько же пустых SEO-шаблонов с одним и тем же текстом, прогнанным через рерайт. Туда не идут крупные команды, потому что выручка с лида в этой нише небольшая. Туда идут одиночки, маркетологи на фрилансе и редкие подрядчики, которым заказали сайт условно за несколько тысяч под ключ. Качество предложения в среднем на уровне 2010 года.
Это и есть причина, по которой я туда полез. Когда вся ниша держится на технически неряшливых продуктах, у одиночки с инженерным фоном есть окно. Я не питаю иллюзий, что «возьму качеством и всё». Я понимаю, что Google маринует новые домены, что Яндекс хочет видеть поведенческие, что SEO без бюджета — это игра вдолгую. Но проверить гипотезу, реально ли в этой нише отбить лидерство одним инженерным качеством расчётов и нормальным UX, мне интересно. Если не получится за два года, я хотя бы пойму, чего не хватает помимо качества продукта.
Космические аппараты всегда зависели от надежности бортовых компьютеров. Они отвечают буквально за все: от ориентации в пространстве до сбора научных данных и их передачи на Землю. Но есть одна особенность: пока на Земле процессоры развиваются с огромной скоростью, в космосе используется гораздо более скромная электроника. И дело вовсе не в том, что инженеры NASA не умеют делать современные чипы — просто за пределами Земли техника работает в настолько жестких условиях, что надежность важнее всего остального.
Сегодня ситуация начинает меняться. NASA совместно с компанией Microchip Technology запустили проект High-Performance Spaceflight Computing (HPSC), в рамках которого создается новое поколение радиационно-стойких процессоров. Эти чипы обещают дать более чем стократный прирост производительности по сравнению с тем, что летает сейчас. Это открывает новые возможности: обрабатывать данные, запускать алгоритмы искусственного интеллекта и принимать автономные решения прямо на борту, без постоянной подсказки с Земли.
⚡ Архитектура монорепозитория для параллельного исполнения торговых стратегий
Статья описывает архитектуру эмулятора биржи. Эмулятор ускоряет время в 6300x раз и запускает такую же торговую стратегию как в prod без изменений. В статье описаны практики структурирования кодовой базы для командной работы
B-Tree O(log n) , memcache lookupO(1), монорепозиторий, SRP, линейное расширение кодовой базы при модернизации