1. Глаза (Компьютерное зрение): Взял модель от Google (Vision Transformer), которая умеет смотреть на пиксели и понимать: "Ага, вот это ребро, а вот тут какое-то белое пятно".

2. Рот (Языковая модель): Взял ruGPT-3 от Сбера (это младший брат ChatGPT). У нее глаз нет, она умеет только тексты писать.

Я алгоритмически "пришил" зрение к генератору текста. Но чтобы этот мутант стал врачом, его нужно было учить.

Взял открытую базу клиники Индианского университета (США) — это больше 7000 реальных рентгенов грудной клетки вместе с заключениями настоящих американских врачей. Прогнал все эти заключения через нейросеть-переводчик на русский язык.

Потом арендовал бесплатные сервера на Kaggle (спасибо им за халявные видеокарты T4) и заставил нейросеть несколько часов подряд смотреть на снимок и читать диагноз. Ошибаешься — получаешь по цифровой шапке, угадываешь — молодец. И так 15 эпох подряд.

Что получилось? (Можно потрогать)

Получилась штуковина, которая реально сыпет медицинскими терминами и в большинстве случаев понимает, где здоровые легкие, а где пневмония или увеличенное сердце.

Я выкатил её в открытый доступ, сделал простенький веб-интерфейс. Денег не прошу, рекламы нет, регистрации тоже.

👉 Ссылка на ИИ: https://huggingface.co/spaces/livadies/AI-Radiologist-RU

Инструкция для Пикабушников:

1. Гуглите "рентген легких норма" или "рентген пневмония".

2. Сохраняете картинку.

3. Закидываете по ссылке выше и жмете Submit.

4. Ждете 10-15 секунд (сервера там бесплатные, крутятся на обычных процах, так что имейте терпение).

5. Читаете, что она вам выдаст.

АХТУНГ ДЛЯ ИПОХОНДРИКОВ: Я программист, а не врач. Нейросеть обучалась в исследовательских целях за пару часов. Иногда она ловит "галлюцинации" и может найти у вас то, чего нет. ОНА НЕ ЗАМЕНЯЕТ ПОХОД К НАСТОЯЩЕМУ ВРАЧУ! Не вздумайте лечиться по её советам.

Для Лиги Программистов 🤓

Если тут есть дата-саентисты или те, кто изучает Machine Learning — я выложил весь код в Open Source.
Там хардкор: обход блокировок сессий Kaggle, написание кастомного PyTorch датасета, ковыряние в конфигах VisionEncoderDecoderModel, чтобы заставить is_decoder=True работать со слоями Cross-Attention, и обучение в fp16 с градиентным накоплением.

👉 Ссылка на GitHub с кодом: [https://github.com/livadies-collab/Multimodal-XRay-Analyzer-...]

Пишите в комменты, какие диагнозы она вам нагенерировала! Если пост зайдет, в следующий раз расскажу, как прикрутить к нейросети распознавание МРТ мозгов.

Всем чистых легких! 🩻

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

Поэтому я немного отошел от канона и добавил в профиль один бонус – магический кубик (+3 к броску).

Можно им не пользоваться и тогда будет совсем-совсем канонично.

Умерли? Вас телепортирует в начало, но всех убитых врагов это не воскресит — они так и останутся мертвыми.

Каждую новую жизнь игрока здоровье определяется броском двух кубиков * 4.

Механика простая, но для 91-го года — и детей этого было достаточно.

Главный вопрос: зачем?

Отвечаю: переботал. Еще это назвается "выгорел", но это какое-то противное слово.

Последние несколько лет и пару моих работ были не очень мотивирующими. Сначала был «Самокат»: там создали новый отдел, наняли тысячу человек. А через некоторое время руководство решило: «А давайте всех разгоним и займемся Купером и Мегамаркетом». Кстати, про Мегамаркет давно не слышал.

Вторая работа оказалась просто до ужаса скучной. Инвесторы, видимо, тоже соскучались и решили не вкладываться в проект.

В феврале глянул я на рынок вакансий — а там тьма, тоска и печаль. Поэтому решил пока вообще не работать :) А в свободное время запилил эту игру.

Техническая часть

Сделать такую игру проще всего на нормальном ООП-языке. Поэтому я взял не ООП язык, а - Go.

Так, как я бэкенд-разработчик, но без фронта такое делать нельзя, выбор пал на Vue. Главное требование — чтобы работало везде, даже в браузере смартфона.

CI: Github Actions и VPS.

ИИ использовал мало. Совсем не использовать ИИ, считаю глупостью, но и вайб-кодинг мне не интересен. Вот где использовал ИИ:

Оцифровка книги: Нашел PDF, попросил ИИ распарсить и создать JSON-ы для базы данных. Не руками же копировать.

Админка: Сгенерировал CRUD для редактирования секций и врагов. Делать CRUD руками — скучно.

Простенькая карта: Тут ИИ сэкономил кучу времени. За основу взял формат DOT, адаптировал ответ под JSON и нарисовал на фронте в Canvas. Правда, руками потом всё равно пришлось поправить.

Тесты: Я очень люблю писать тесты (так как терпеть не могу тестировать функционал руками). Но тут я взялся за задачу без четкого понимания архитектуры проекта, поэтому никакого TDD тут не получилось бы. Так что основные тесты нагенерировал с ИИ, а на спорные места добавил своих.

Я старался не трогать оригинальные механики (хотя с кучей вещей не согласен).

В идеале хотелось бы сделать другой мир и еще кучу всего добавить, чего тут нет. Если не найду работу, то у меня будет куча времени ))

P.S.

Игра старенькая, местами слишком простая. Интерес может представлять для тех, у кого в детстве была эта книга.

Баги возможны и вероятно есть: я тут и бэк, и фронт, и QA, и архитектор в одном лице — где-то да накосячил.

Ссылки:

URL игры: http://labirint-kolduna.ru/ (без https - мне было лень, да и нет тут ничего такого)

Репозитории (может кому интересно):

https://github.com/Zazza/labirint-kolduna.ru-go

https://github.com/Zazza/labirint-kolduna.ru-vue

Код рабочий, но сыроват. Вылизывать до блеска лень. Seeders в репозитории не выкладываю, потому что с авторскими правами не знаю, как быть (а самого автора не нашел). Если очень нужно — можете (или могу) нагенерить тестовых данных, структура в GO entity описана четко.

P.P.S.

Да, VPS дохлый, но тут и нагрузки может не будет.

Если сообщество выбрано не верно - поменяю.

Итак.

Сегодня на производстве, например, нам необходимо сделать вот такую деталь:

Для начала необходимо создать наши изменяемые переменные:

#1 = 0.1 (BOTTOM OFFSET) // Отступ от кончика фрезы до стола чтобы не фрезеровать зеркало стола.

#2 = 3.175 (ENDMILL DIAMETER) // Диаметр рабочего инструмента

(---------------------------------)

#3 = 200 (OUTER WIDTH) // Ширина детали

#4 = 80 (OUTER HIGHT) // Высота детали

#5 = 20 (OUTER CORNER RADIUS) // Радиусы скруглений на детали

(---------------------------------)

#6 = 120 (INNER WIDTH) // Ширина отверстия

#7 = 60 (INNER HIGHT) // Высота отверстия

#8 = 10 (INNER CORNER RADIUS) // Скругления внутренних углов

С переменными разобрались. Теперь стандартная строка безопасности и шапка программы:

G90 G17 G21 G40 G49 G80 G94 F1500

G54

T1 M6

G43 H1 M03 S20000

Т.к. тему компенсации на радиус инструмента здесь мы затрагиваем (в дальнейшем будет и на это отдельная тема), то, чтобы получить отверстие необходимых размеров необходимо учитывать и диаметр режущего инструмента тоже. Для этого мы и завели переменную #2.

Начало координат - G54 X0 Y0 - у нас в центре детали. Это важно!

Пишем код для обработки внутреннего контура:

// На ускоренном ходу подъезжаем в точку врезки. Чтоб получить точку врезки по оси Х необходимо нашу внутреннюю ширину разделить на два и отнять половину диаметра фрезы (радиус фрезы), а по оси Y (давайте начнем обработку с точки начала внутреннего радиуса) необходимо от половины высоты отверстия отнять радиус внутреннего угла. Геометрия. 4 класс, вторая четверть. Надеюсь, объяснил понятно ;)

G0 X[#6/2 - #2/2] Y[#7/2 - #8]

Проверяем.

Все правильно (в симуляторе обращаем внимание на верхний правый угол. Это позиция инструмента). Идем дальше.

// На рабочей подаче врезаемся в заготовку до, прописанного нами, отступа от стола.

G1 Z#1

Собственно теперь сама обработка отверстия. Инструмент справа.

// Вторая наша точка абсолютно зеркальна точке врезки, т.е. со знаком "минус" по оси Y. И т.к. мы перемещаемся только по одной оси, то координаты по оси Х опустим. Возьмите себе это за правило. Во-первых, уменьшает объем программы (важно для старых стоек), а во-вторых, улучшает читаемость кода и снижает риск ошибиться.

G1 Y-[#7/2 - #8]

Проверяем:

Ошибок пока нет. И не мудрено, написано то только 3 строки кода ;)

Радиус. Тут немного сложнее. Мы же работаем без компенсации, значит постоянно держим в уме радиус рабочего инструмента. Где-то его надо отнять от координаты, а где-то добавить:

// Точка у нас будет с такими координатами: по оси Х - это половина ширины отверстия минус радиус скругления внутренних углов. По оси Y (отрицательная координата !!!) - это половина высоты отверстия минус половину диаметра фрезы. Радиус дуги R - радиус внутреннего скругления минус половину диаметра инструмента.

G2 X[#6/2 - #8] Y-[#7/2 - #2/2] R[#8 - #2/2]

Проверяем:

Проверяем.

Далее берем значения из предыдущей строки но только для оси Х и с отрицательным значением:

G1 X-[#6/2 - #8]

Можно и не проверять. Ошибиться тут сложно. Но по традиции, 2 картинки:

Далее две точки у нас зеркальны предыдущим точкам. Дуга:

G2 X-[#6/2 - #2/2] Y-[#7/2 - #8] R[#8-#2/2]

Прямая:

G1 Y[#7/2 - #8]

Дуга:

G2 X-[#6/2 - #8] Y[#7/2 - #2/2] R[#8-#2/2]

Прямая:

G1 X[#6/2 - #8]

Дуга с координатами такими же как и наша точка входа:

G2 X[#6/2 - #2/2] Y[#7/2 - #8] R[#8-#2/2]

И т.к. мы находимся в точке входа, то выполняем выход из материала на ускоренной подаче:

G0 Z12

Вот, собственно, мы и получили параметрически описанный код для обработки отверстия в требуемой детали. Теперь вы можете легко поменять любые значения, относящиеся к переменным отверстия (#6, #7 или #8) и траектория обработки у вас перестроится.

С наружным контуром давайте поступим так: если контур отверстия мы строили в абсолютных координатах (G90 - у нас прописан в строке безопасности), то наружный контур давайте построим в относительных координатах.

Начнем.

На точку врезки мы еще двигаемся в абсолютных координатах, потому как в относительных координатах нам сложно вычислить на сколько и по какой оси сместиться. "Можно! А зачем?" (c, кто-то из великих). Точка:

// Чтобы получить точку входа по осям нам необходимо: по оси Х - к половине ширины детали добавить половину диаметра инструмента. По оси Y - от половины высоты детали отнять внешний радиус.

G0 X[#3/2 + #2/2] Y[#4/2 - #5]

Проверим:

Врезаемся в материал:

G1 Z#1

Вот теперь и переключаемся в режим относительных координат:

G91

Инструмент справа. Значит обработка и дуга против часовой стрелки:

// Т.к. мы в относительных координатах, то вычислений у нас минимум. По оси X и Y смещаемся на величину радиуса, но т.к. работаем без коррекции на диаметр инструмента не забываем добавить к величинам половину диаметра инструмента. С включенной коррекцией код еще проще...

G3 X-[#5 + #2/2] Y[#5 + #2/2] R[#5 + #2/2]

Проверим правильность координат:

Все верно! А ведь в относительных координатах и правда удобнее работать. Особенно когда у тебя начало координат находится в какой-нибудь рандомной точке.

Далее прямая:

// Проще некуда: смещаемся по оси Х на величину ширины детали минус два внешних радиуса детали. Должны получить зеркальную координату оси Х предыдущей точки.

G1 X-[#3 - #5*2]

Верно.

Дальше дуга.

// Просто копируем код предыдущей дуги и смотри куда нам надо переместиться. По оси Х - идем "в минус", и по оси Y - также идем "в минус". Обратите внимание на то, что на предыдущей дуге мы смещались: по оси Х - "в минус", а вот по оси Y - "в плюс".

G3 X-[#5 + #2/2] Y-[#5 + #2/2] R[#5 + #2/2]

Даже если вы ошибетесь со знаками осей, то симулятор всегда вам покажет неправильную кривую:

После дуги снова идет прямая:

G1 Y-[#4 - #5*2]

Дуга:

// По аналогии берем код из предыдущей дуги, но в этот раз смещаемся по осям: Х - "в плюс", Y - "в минус".

G3 X[#5 + #2/2] Y-[#5 + #2/2] R[#5 + #2/2]

Прямая:

G1 X[#3 - #5*2]

Дуга:

G3 X[#5 + #2/2] Y[#5 + #2/2] R[#5 + #2/2]

Прямая:

G1 Y[#4 - #5*2]

Всё!

Круг замкнулся, господа присяжные заседатели. Мы в точке врезки. Здесь ОООООЧЕНЬ важно вернуть "взад" режим абсолютных координат:

G90

Выход из материала и конец программы:

G0 Z12 // Выход из материала

M5

M2

Бинго.

А теперь то, зачем мы вообще все это затеяли. Нам необходимо сделать деталь, но уже с другими размерами. Например, квадрат с наружными размерами 150x150. Отверстием 50х50 и радиусами, пусть 5мм. Меняем всего пару цифр в начале программе:

(---------------------------------)

#3 = 150 (OUTER WIDTH)

#4 = 150 (OUTER HEIGTH)

#5 = 5 (OUTER CORNER RADIUS)

(---------------------------------)

#6 = 50 (INNER WIDTH)

#7 = 50 (INNER HEIGTH)

#8 = 5 (INNER CORNER RADIUS)

И мгновенный результат:

Магия? НЕТ! Параметрия.

В следующей части мы усложним наш код различными проверками "на правильность". Ведь зона внутренней обработки не должна быть больше наружной. А внутренний радиус не может быть меньше радиуса инструмента. Правда ведь? Вот мы это и проверим. А при наличии ошибок выведем ошибку на панель.

Дальше - больше ;)

До связи. Ваш @Nikomas

Боль рынка: «Тетрадка — наш лучший CRM» Когда мы начинали, туристический рынок Абхазии выглядел как цифровой заповедник. Огромная доля топовых гостевых домов вообще не представлена в сети. Почему?

1. Крупные агрегаторы забирают до 25%, что для небольшого семейного бизнеса просто неподъемно.

2. Жесткий цифровой барьер. «У меня всё в тетрадочке записано, зачем мне ваш экстранет?» — это реальная цитата, с которой начинался каждый второй диалог.

Мы поняли: сидеть в уютном коворкинге и парсить данные не получится. Придется ехать в горы, пить кофе и убеждать владельцев, что IT — это не страшно. Во время одной из таких вылазок к новому эко-отелю навигатор завел нас на старую лесовозную дорогу, где мы намертво посадили машину на пузо в грязь без грамма сотовой связи. Нас спас случайный охотник на УАЗике: он не просто нас вытащил, а потратил полчаса своего времени, угостил соком и не взял ни копейки.

Этот опыт напрямую повлиял на архитектуру нашего продукта. Мы поняли, что стандартная «калька» с Booking тут не взлетит.

Архитектура: почему мы отказались от обычного поиска Мы решили перевернуть классическую модель и реализовали механику C2B (обратный аукцион). Вот что мы собрали под капотом нашей платформы:

• Тендер за туриста. Гость не просто листает каталог с завышенными ценами. Он вбивает свои даты, город и указывает свой бюджет. Система рассылает эту заявку всем подходящим хозяевам, и они сами откликаются на нее.

• Автопредложения для ленивых. Учитывая любовь к «тетрадкам», мы не могли заставить хозяев сутками сидеть в админке. Мы написали логику автопредложений: хозяин один раз задает минимальную планку цены за номер. Если бюджет гостя подходит — автопредложение улетает само. Уведомления мгновенно приходят в Telegram и на почту.

• Таймер на 4 часа. Заявка гостя живет ровно 4 часа. Это создает эффект горячего лида — хозяин знает, что клиент готов бронировать прямо сейчас. Поэтому владельцам выгодно отдавать «горящие» окна между заездами дешевле, лишь бы не простаивать.

• Интерактивный торг. Гость имеет право ровно 1 раз нажать кнопку «запросить скидку». В ответ хозяин может согласиться, отказать или предложить свой компромиссный вариант. Настоящий южный торг, но полностью оцифрованный!

Итог За два месяца мы не просто собрали базу — мы создали мост между миром гор и современным миром бронирований. Я вернулась домой, оставив там работающий MVP, который сейчас начал прирастать трафиком.

Мы верим, что нестандартная логика кода и понимание менталитета могут победить глобальных гигантов на этом маленьком, но гордом рынке.

Есть кусок данных от мира — предположим, картинка размером 1000 на 1000 пикселей, получаемая видеокамерой каждые 10 миллисекунд. Есть алгоритм предсказания будущей картинки мира на основе динамической системы «мир» + «действие» (действие совершается в тот же момент времени, что и берётся картинка). Затем происходит сравнение этих картинок. Например, из картинки видеокамеры (то, что произошло в реальности) попиксельно вычитается предсказанная для этого момента времени картинка (предсказание). Затем эта разность реальности и ожидания меняет правила эволюции динамической системы «мир», чтобы она лучше предсказывала будущее, и пытается найти новый список действий в этой динамической системе для достижения нужных целей в будущем.

Так как мы считаем, что сознание связано с входными данными и обработкой новых данных, то наиболее вероятный кандидат на подалгоритм сознания в таком ИИ — это подалгоритм, меняющий правила эволюции динамической системы «мир» на основе текущей ошибки предсказания будущего. Если мы будем думать о том, как может быть устроен этот подалгоритм «сознания», то на роль кандидатов в наше время инженеры рассматривают две системы: LLM (ChatGPT, Claude...) и граф логического вывода. При этом мы можем заметить, что LLM в последнее время неплохо справляются с логикой и математическими задачами. Для нашей задачи мы бы считали, что LLM не предсказывает следующее слово в тексте, а предсказывает следующий кадр картинки видеокамеры.

Однако существует проблема того, что LLM до сих пор трудно интерпретировать, поэтому мы можем рассмотреть простейшие схемы логического обновления правил эволюции динамической системы на основе ошибки предсказания и попытаться понять, чем этот алгоритм может быть ограничен. Как я рассматривал в предыдущих постах по теме ограничений сознания, сознание не может менять модель мира, не используя логических правил или внешнего авторитета — иначе оно могло бы переписать ценность наград. Значит, алгоритм работы сознания должен быть связан и быть похож на алгоритм работы систем автоматического вывода доказательств, таких как, например, Lean 4. Ведь изменение логической модели означает изменение правил эволюции системы «мир» — именно та задача, которая, как мы считаем, связана с сознанием.

Что ещё более важно: мы понимаем, что подобно тому, как сознание способно создавать вымышленные миры со своими правилами (например, Средиземье Толкина), так и этот алгоритм должен понимать разницу между гипотезой и теорией.