Истории (не)успеха (ИИ)ЕИ
444 subscribers
171 photos
89 videos
2 files
265 links
Просто о математике, нейросетях, программировании, спорте, политике, культуре. Общение, контакты, международные онлайн дискуссии/лекции в формате лайвстрим, встречи на спорт в Мюнхене.
Download Telegram
🧠 В последнее время мы много говорили о математике, теории сложности, об искусственном и естественном интеллекте и прочих фундаментальных вещах. А вот про повседневную практику софт-разработки — почти не вспоминали.

Хочу это исправить. В ближайших постах планирую рассказать о трёх проектах из более чем дюжины, которыми я занимался за последние 15 лет для крупных и известных компаний. Это не теория, не хобби и не pet-проекты — это рабочие системы, созданные за деньги и реально используемые в серьёзных продуктах.

Начнём с трёх проектов, довольно разных, но каждый — на стыке инженерии и высоких технологий:

🔬 Медицинасофт в приборах для микрохирургии глаза.
Это safety-critical система: пациент не должен ослепнуть из-за бага в коде или перегоревшего транзистора в железе.

🏗️ Машиностроениесистемы управления продвинутой индустриальной 3D-печатью.
Пожалуй, самый высокотехнологичный продукт, над которым я когда-либо работал.

🔐 Криптографиягомоморфное шифрование в реальных системах, с реальными пользователями.
Работает ли это на практике или остаётся в теории?

На днях расскажу, как эти проекты были устроены, с какими техническими (и не только) вызовами мы сталкивались и чему я сам из них научился.

📡 Оставайтесь на связи — будет интересно даже тем, кто далёк от программирования.

продолжение следует на днях

#RealWorldProblems #SoftwareEngineering #SoftwareQuality
👍42🔥2
Dmytro
1/2 Как обещал вверху 👆, расскажу о паре реальных проектов в интересных областях, над которыми мне довелось работать в последние годы. 💡 Работал над Callisto Eye — системой для микрохирургии глаза. Прежде всего удаление катаракты и имплантация искусственных…
2/2. Продолжение. Начало тут 👆

⚙️ В проекте Callisto Eye я отвечал за контроль качества. Один из главных вызовов — реалистичные автоматические тесты на реальном железе, которые симулируют целый рабочий день хирурга. Они должны были ловить даже мельчайшие сбои: функциональные ошибки, утечки памяти, взаимные блокировки (deadlocks), нарушения в синхронизации потоков, неожиданные задержки в UI — всё, что может проявиться только в долгосрочном, живом сценарии.

Тесты должны были не просто запускать отдельные функции или проверять отклик интерфейса, а наблюдать за поведением всей системы под нагрузкой, максимально приближённой к реальности операционной.

Среди множества задач особенно запомнились две.
Одна — чисто техническая.
Вторая — методологическая и по-настоящему новая.

🧩 Проблема 1: установка софта через CI (Continuous Integration) на кастомном "железе"
Callisto Eye — это не просто приложение, которое можно поставить из пакетного менеджера. Это полноценная ОС + tightly coupled системные компоненты, заточенные под определённый стек железа. Поэтому мы тестировали целые образы жёсткого диска, чтобы полностью воспроизвести окружение, как в операционной. CI должен был уметь автоматически прошивать систему этим образом, с нуля и надёжно — каждый раз. Сетевая загрузка (PXE boot) немного усложняла жизнь и с ней пришлось повозиться, но это хотя бы известная штука.. А вот вторая проблема стала по-настоящему новым вызовом.

🔍 Проблема 2: как быть уверенным, что сами автотесты не врут?
Автотест — это тоже софт. А если в нём баг? Что, если тест "зелёный", а на деле хирург в разгар операции увидит пустой экран?
Цена ошибки — зрение пациента. Поэтому пришлось разработать целую методологию и алгоритмический фреймворк, чтобы верифицировать надёжность самих тестов.
К сожалению, пока не оформил это в полноценную статью — руки не дошли. Хотя я неоднократно выступал на различных конференциях по медицинской технике с этой темой и рассказывал про это устно:
👉 https://medtechstars.eu/schedule/dmitrychibisov/

Из опубликованного — есть только старая статья (там ещё не всё понимание было сформировано, но всё же кое-что есть, если вдруг кому интересно):
📄 https://www.researchgate.net/publication/370595971_Patterns_of_Test_Automation

@easy_about_complex

#RealWorldProblems #SoftwareQuality #TestAutomation #SoftwareDevelopment #MedTech #Engineering

P.S. Следующий пост про real-world-проекты будет из области современного машиностроения и продвинутой индустриальной 3d-печати. Но сначала немного теории и вообще науки 👇👇👇
👍6🔥31
2/2. продолжение. начало тут

🔐 Гомоморфное шифрование: вычисления без раскрытия данных

Гомоморфное шифрование (Homomorphic Encryption, HE) — это криптографический метод, позволяющий производить вычисления непосредственно над зашифрованными данными. При расшифровке результата вы получите тот же ответ, как если бы вычисляли над исходными данными.

📘 Что это значит на практике?


Пример 1: Защищённая аналитика
-У больницы есть зашифрованные данные о пациентах.
- Исследователь хочет посчитать средний возраст пациентов с диабетом.
- Он выполняет вычисления над зашифрованными данными, не получая доступ к реальным возрастам.
- Результат после расшифровки — корректный, но приватность не нарушена.

Пример 2: Облачные вычисления
-Компания шифрует свои бизнес-данные и отправляет их в облако.
-Облачный сервис считает оптимальный маршрут доставки, не зная, что именно обрабатывает.
-Компания получает готовое решение, не жертвуя конфиденциальностью.

🔣 Типы гомоморфного шифрования
PHE
(частичное): поддерживает одно арифметическое действие (например, схема RSA — умножение, Paillier — сложение).
SHE (ограниченное): ограниченное число операций.
FHE (полное): любые арифметические операции и неограниченное их количество — теоретически мощно, практически сложно.

⚙️ Сложность и ограничения
Полностью гомоморфные схемы (например, BGV, BFV, CKKS) используют сложные математические конструкции, основанные на задачах на решётках (например, Ring-LWE). Они считаются устойчивыми даже к квантовым атакам.
Но:

Один шаг умножения может быть в 1000 раз медленнее, чем над открытыми данными.
Размеры зашифрованных данных могут вырасти в десятки мегабайт даже при обработке маленьких чисел!

Пример 3:
Сравнение времени:
Обычное сложение: ~100 наносекунд
Гомоморфное сложение: ~10–100 микросекунд
Гомоморфное умножение: ~1–10 миллисекунд


Но что, если таких операций — сотни миллионов, как в настоящих аналитических запросах?

🧠 Реальный сценарий, SQL запрос к базе данных:
SELECT AVG(salary) FROM employees WHERE department_id IN (10, 12, 15);

В открытом виде:
-Выполняется за десятки миллисекунд.
- Сложения и фильтрация — почти бесплатные.

В гомоморфной форме (FHE):
- Фильтрация = миллионы сравнений.
- Суммирование и деление — над зашифрованными значениями.- всё дорого.

🔢 Оценка масштабов:
Если один шаг FHE-умножения ≈ 1–10 миллисекунд, а запрос требует 100 млн арифметических операций,
то:
100,000,000×1 мс=1,000,000  секунд≈11.5 дней

🤯 И это — только один запрос.

Да, можно параллелить, батчить, использовать SIMD, но даже с 1000-ядерным распределением это всё ещё часы на простейший аналитический запрос.

🔍 Почему так медленно?
🚫 Невозможно адресовать конкретные данные напрямую: всё обрабатывается последовательно, от начала до конца.
Даже простая фильтрация превращается в арифметическую маску (массив умножений).
🔐 Все операции идут по "защищённому пути": нет читов, нет оптимизаций из классических DB.

🛠️ Что делают?
⚙️ Используют batching (один шифротекст содержит десятки/сотни значений).
⏱️ Переписывают запросы на арифметику, минимизируя глубину схем.
💡 Комбинируют FHE с другими подходами: MPC, TEE, дифференцированным шифрованием.

📌 Вывод:
Гомоморфные вычисления не подходят для произвольных SQL-запросов по большим базам — пока или вообще никогда?

#RealWorldProblems #Crpyptography
#HomomorphicEncryption
#DataPrivacy #Algorithms #Complexity
👍2😁2🔥1