Попов воскрес!

Попов воскрес!

Интересно, а существует такой агент, который получает на вход таблицу (эксель), по размерам значительно превосходящую контекстное окно, и начинает ее документировать по сути. Вот есть несколько вкладок. Вот есть на вкладке 5 табличка в миллион строк и пять столбцов. Столбцы такие-то. Берем случайные данные из таблички, так, там вроде числа, а там — фамилии. Делаем предположение, что числа там везде — пишем код, который проверяет это предположение и заодно вычисляет мин/макс и набор уникальных значений. Так, значений немного, всего пять. Запишем. Проверяем теперь фамилии. Да, это просто строки, новый сэмплинг показал, что там фамилии правда. Тут формула. Смотрим куда она указывает. И т.д. А вот эта колонка — неясного назначения. Смотрим на данные — это какие-то числа от 0 до 1. Померяем среднее и разброс. Спросим у пользователя — может, даст какие комменты. Дал. Окалось это выданный kpi этого юзера из внешней системы. Запишем. И так далее. Получается документация. Дальше, когда есть документация, можно просить сделать какие-то операции со всем этим, поскольку LLM уже понимает плюс-минус назначение данных, и их связь, и может строить какие-то гипотезы на выявление outliers и их проверять.
Почти в каждом проекте разработки есть выделенная команда автоматизации функционального тестирования, однако на удивление редко встречается аналогичный акцент на Data Quality. Неважно, идут ли данные из внешних интеграций, от пользователей или генерируются самой системой, часто они остаются без должного контроля просто потому, что почему-то никто не считает это важным, а потом борятся с последствиями — они накапливаются как снежный ком. Чем дольше длятся такие проблемы, тем труднее их устранить, что в итоге приводит к ситуации, когда народ просто смиряется с «непоправимым» состоянием базы. Уж насколько лучше выявлять эти проблемы в момент их возникновения, пока технический долг не стал непреодолимым, чем потом решать, как сделать так, чтобы из-за них ничего не падало;
По сути, надо внедрять постоянного «надсмотрщика» над базами данных всех типов, использующихся системой (реляционных, NoSQL, поисковых индексов или графовых БД) — по сути, это слой проверки качества данных поверх процессов. Конечно, должны быть четкие правила — что именно проверять и какими флагами отмечать конкретные аномалии.
Должен быть ответственный за процесс (кожаный мешок, не AI), который будет интегрировать эти отчеты в рабочие процессы разработки и поддержки. Многие проблемы целостности данных невозможно решить просто через интерфейс — они требуют от инженерной команды разработки скриптов для массового исправления и очистки данных.
Тут кстати еще переходит все в область детектирования аномалий (outlier detection). Машинное обучение и LLM для выявления тонких «плохих» паттернов, которые традиционные системы на основе правил могут пропустить.
Что вы об этом думаете? Внедрены ли подобные механизмы в ваши процессы?

Сходили вчера на Project Hail Mary. Честно говоря, совсем не понравилось ни мне, ни Наде. Может, мы просто выросли из возраста, кому такие кино нравятся. Комикс-стайл. Сам инопланетянин, на мой взгляд, появился из экономии. Мне кажется, уровень начала 2000-х годов — тогда можно было бы сделать вот точно тоже самое. Тот же фильм Прибытие вспомните, где пыталить сделать что-то придумать необычное. Ну правда, это каменое уродство стоило 200М? Весь сюжет полон условностей и банальностей. За минуту они сделали так, что человек и инопланетянин начали прекрасно друг друга понимать с помощью какой-то программы, которую учитель естествознания создал за день. Мол, пусть астронавт и кусок камня сразу начинают болтать как приятели.. 5 километров железной цепи толщиной в указательный палец это где-то 10 тонн металла … это у них на корабле было столько?
Режиссеры стали успешными на поприще мультфильмов Лего-фильм и Осадки в виде фрикаделек, парой комедийных сериалов и Мачо и ботан. Я ожидал фильма в духе Интерстеллара или Марсианина, умного взрослого sci-fi, который не боится научных деталей, а получил детскую сказку с некрасивым инопланетянином.
Погуглил, оказалось, что прям до фига народу в восторге от этого, и кассу собирает.. Вероятно, люди соскучились по такому среди постиронии, сатиры, повесточек разных, Лантимоса и «Битвы за битвой». В детстве все смотрели «Полет навигатора» и «Короткое замыкание», ну вот взрослые ностальгируют по простому добру. Возможно, что это просто такой семейный фильм, для просмотра с детьми. Тогда может и норм.
ну ок, возвращаемся к просмотру второго сезона Succession. Он значительно лучше.

Сломался очиститель воздуха, купил такой же б/у с новым картриджем по цене стоимость сменного картриджа+40 долл. Старый полностью разобрал, заодно извлек компоненты, которые можно переиспользовать, и понял, как оно работает. Прям как в школе 🙂
В общем, внутри:
— контроллер на ESP32-WROOM-32D. Но на плате сгорела часть, отвечающая за напряжения, поэтому в помойку.
— газовый (CO) сенсор MQ-7 (к сожалению, впаянный в плату, но можно выпаять). Правда, для корректной работы нужен цикл нагрева. Сначала 5В (60 сек) для очистки сенсора, затем 1.5В (90 сек) для измерения. Но тоже можно использовать где-нибудь.
— Plantower PMS9103M — высокоточный лазерный датчик концентрации взвешенных частиц в воздухе (PM1.0, PM2.5, PM10). Можно подключить к Arduino, есть специифкация.
— микроволновый датчик движения (радар), модель RCWL-0516. Можно подключить к Arduino, очень простой по интерфейсу. Видит на 5-7 метров вокруг себя 360 градусов.
— 200W мотор Snowfan YY225H310B. Подключить тоже довольно просто, только там напряжение 310V DC плюс 15V управляющее оборотами. Но зато больше ничего нет.
— датчик Холла (магнит)
Самое ценное — мотор. На eBay он стоит 100 долл. Правда, надо бы и его проверить сначала, не сгорел ли он.

За вечер сделал простую утилитку, которая вытаскивает чат Natural Language Processing за полтора года — там 65 тысяч сообщений, и переводит его в пары вопрос-ответ, по которым есть семантический поиск. При клике на результат поиска (слева) открывается диалог в чате. Подсвечиваются те сообщения, которые являются ответами на вопрос. Ну и сверху подсвечивается вопрос а оригинальной формулировке.
Как работает: система предполагает, что люди в основном делают reply to на сообщения, находящиеся относительно близко в прошлом. Если на одно сообщение делается несколько reply-to, то наверняка оно полезное, и зацепило в чате других. Система берет сообщения, начиная с того, на которое многие отвечали, и заканчивая последним в цепочке reply-to — и среди таких берет те, которые имеют минимум 3 reply-to к оригинальному вопросу. То есть, по сути, она вырезает из чата кусок, начинающийся популярным вопросом так, что после нижнего отреза скорее всего уже идет нерелевантное. Такие блоки могут накладываться друг на друга — например, если кто-то спросил, пока другие отвечали на что-то еще.
То есть, если пользователь А спросил какая погода, и ему ответили «хорошая», «плохая», «дождь», и еще было пять сообщений без reply-to, а потом кто-то ответил на «дождь» вопросом «почему дождь», и на этот вопрос ответили еще пятеро, то в систему попадет первый вопрос про погоду — кусок будет заканчиваться 13 сообщениями.
Дальше эти куски суммаризуются в вопрос-ответ.
Получается прикольно.
П. С. На скриншоте поисковый запрос не имеет отношения к результату поиска, потому что я сдуру сделал скриншот, когда запрос ещё поменял, а отправить ещё не нажал

Пытаюсь понять, это у меня одного так глаза работают или нет 🙂 если смотреть на любое место, кроме слова «Омурбекова», то боковым зрением четко выделяется линия, показанная на втором скриншоте красным цветом (но конечно, она белая). Как только возвращаешь глаза на нее, линии нет. То есть, она видна только боковым зрением. Делитесь, как у вас 🙂


Это я набрал слово gremlin, не переключив раскладку. Собрался блин почитать про язык запросов графовых баз данных, по работе надо. Удивляет гугл, удивляет

На картинке — вавиловочеренковское излучение. Это я в 2009 году был на САЭС, стою в зале с ядерным реактором. Вода на фото — для замедления нейтронов и охлаждения отработанных стержней с ядерным топливом. Свечение возникает, когда электроны вылетают из топлива со скоростью, превышающей фазовую скорость света в воде. Типа звукового барьера, только для света. По интенсивности этого свечения можно на глаз примерно определить, насколько «свежее» топливо находится в бассейне. Чем ярче и гуще синева, тем активнее идут процессы распада. Интересно, что черенковское излучение является причиной, по которой на многокилометровой глубине океанского дна не бывает абсолютной темноты.

К годовщине Чернобыля. Кто интересуется этой темой может быть и не знает, что практически подобная авария могла произойти на десять лет раньше на головном (самом первом блоке РБМК-1000) Ленинградской АЭС.
Там была практически аналогичная ситуация: одна турбина в работе, глушение реактора аварийной защитой и последующий вывод реактора на мощность.
Тогда ситуацию спас СИУР Михаил
Карраск, который действуя интуитивно и полагаясь на свой опыт управления промышленными реакторами, порциями по 4 штуки ввёл в реактор
12 стержней ручного регулирования
ПРЕЖДЕ чем нажать кнопку аварийной защиты.
Пару лет назад Карраск умер. Эта история почти никому не известна вне отрасли. За пруфами гуглите некролог на росатоме.
Собственно, техчасть. Главная опасность РБМК того времени заключалась в конструкции стержней управления. В нижней части они имели графитовые «вытеснители». При нажатии кнопки аварийной защиты стержни начинали идти вниз, и в первые секунды графитовые наконечники не глушили реактор, а наоборот — вытесняли воду и увеличивали мощность в нижней части активной зоны. Но как раз инструкция на случай проблем предполагала нажатие кнопки аварийной защиты. Если ты действовали по инструкции, «Чернобыль» случился бы раньше.
После аварии на ЛАЭС была создана комиссия. Специалисты (в том числе из ИАЭ им. Курчатова) указали на опасные конструктивные недостатки РБМК — положительный паровой коэффициент реактивности и неправильная конструкция стержней. К сожалению, масштабные изменения в конструкцию всех реакторов РБМК тогда внесены не были. Были даны лишь рекомендации по регламенту эксплуатации, которые, как показала история, оказались недостаточными для предотвращения трагедии в Чернобыле.