https://arxiv.org/abs/2504.17004

забавно: обнаружение галлюцинаций невозможно в современных LLM в принципе, какой бы механизм self-evaluation не применялся.

Правильно ли я понимаю, что без достаточного уровня RLHF человеком, LLM будет галлюцинировать только больше со временем, и ничего с этим не сделать никак?

И ещё: получается, что чем жирнее LLM становится (то есть, чем больше данных в тренинг запихивается), тем хуже будет ситуация становиться?

Значит ли это, что коллапс моделей неизбежен, если не вкладывать всё больше и больше денег в человеческую RLHF?

Продолжая тему “best practices”.

Кажется, само стремление к поиску «best practice» часто является симптомом одной или нескольких проблем:

1. перегрузка: когда времени нет подумать, легче всего последовать упрощённой “эвристике” (отсюда все карго-культы). [1][2][3]

2. отсутствие “навыка” критического мышления. (Навык в кавычках — я не до конца понимаю, умение ли это или навык. Современная литература говорит, что критическое мышление редко развивается само, чаще всего ему нужно осознанно учиться. Но всё же иногда появляется и само, то есть может быть и умение и навык) — человек просто не знает, как выбирать и анализировать проблему, и как подходить к выработке оптимального решения [4][5][6]

3. cоциальное или организационное давление. Иногда к неоптимальным решениям принуждают так или иначе, прямо через “давление” со стороны коллег или менеджера или косвенно через конформизм. [7][8]

набор любопытных исследований про TDD:

1. A Comparative Case Study on the Impact of Test-Driven Development on Program Design and Test Coverage
2. Realizing quality improvement through test driven development: results and experiences of four industrial teams
3. A structured experiment of test-driven development

я не знаю, кому нужны какие доводы, чтоб попробовать TDD, но для меня сейчас значимым преимуществом такого программирование стало почти полное отсутствие “когнитивного страха”.

Я не программирую щас фултайм, буквально полчаса-час в день, да и то не каждый день получается выделить. Так вот раньше, когда я писал code-first подходом, “сесть на полчасика” было довольно трудно — я знал, что мне придётся всю структуру подпрограммы “вгрузить в голову” для того, чтоб изменение, которое я вношу, не разломало ничего. Сейчас же я просто сажусь, думаю о том, для чего и как сформулировать ожидания, пишу по ним тест, и потом пишу код. Или даже не пишу код, а оставляю систему в “red” состоянии — всё равно основная работа уже сделана.

28 мая товарищи Павел и Илья будут проводить (бесплатное) онлайн-мероприятие мотивам тренинга: https://hottg.com/above_the_range/714

я о марте месяце участвовал в их курсе, помогал с темой переговоров про увольнение. Ребята хорошие, советую. Это вот мероприятие, что будет — про переговоры на работе вовсе (далеко не только про увольнение и повышение зп).

P.S. реклама бесплатная и искренняя

С четверга по вчера проехал 3000км на поезде, постоял со стендом в Цюрихе на GreaTEST Quality conf, выступил на Tech Internals Conf в Берлине, попытался (безуспешно) уехать на автобусе в Лиссабон, чтобы выступить там на митапе. Пришлось выступить онлайн, спасибо ув. тов. Евгению Коту, что организовал стриминг.

Надеюсь, что “спонсоры” моей смены полётов на разъезды — британское консульство в Париже — успеют мне-таки вернуть паспорт до понедельника, чтоб улететь на всю следующую неделю в Эдинбург на EuroSTAR.

Выступления и общение вживую с людьми — очень весело, но поездки на дальние дистанции на поездах и автобусах — крайне тяжело.

Про “техдолг”.

Ув. тов. Уард Канингем когда-то сказал:

Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring1. The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment2 counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unfactored3 implementation, object-oriented or otherwise

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

Есть ощущение, что люди запомнили только то, что можно брать в долг, даже не дочитывая до stand-still.

Ув. тов. Роман Ивлиев скинул статью — очередное исследование, показывающее, что чем больше 'техдолг', тем труднее и дороже работать. Ничего нового, всем известно вроде бы. У Уарда ровно этот тезис и был — если не рефакторить, будет копиться что-то, замедляющее и осложняющее труд.

Все наверное помнят и кривую Боэма, которая про чем дольше дефект живёт, тем дороже его починить.

Кажется, онтологически эти две тезиса об одном и том же: о том, что система неизбежно "отклоняется", "отходит" от ожиданий к ней (явным или неявным).

Получается, что постоянное тестирование и рефакторинг — равноценно важные меры по обнаружению и исправлению этих отклонений.

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

Рефакторинг даёт возможность привести систему в состояние соответствия как сформулированным, так и несформулированным ожиданиям ("понятность" и "изменяемость" кода не кажется возможным зафиксировать навсегда).

Так вот, покуда мы размышляем в рамках метафоры "долга", мы просто уменьшаем качество как внутреннее, так и внешнее — потому что откладываем рефакторинг. Метафора “долга” будто бы легитимизирует “сделаем потом”, что конечно же никогда не наступит.

Кажется, само присутствие концепции “долга” провоцирует и усиливает hyperbolic discounting, перерастающий потом с течением времени в short-termism.

а вот очередное про DISC

пришёл мне esp32-s3 от seeed.

самый крошечный esp32-s3 из тех, что я видел вообще

назвал Грегом

Первый созвон рабочий по-французски — done.

Офигенно волнительно было до, но оказалось всё довольно несложно. Во дела!

ребята, расскажите пожалуйста, что с помощью LLM у вас получилось сделать из области, которая раньше вам была неизвестна? И так, чтоб результат кто-то знающий эту область оценил как хороший?

я вот решил попробовать RTSP сделать, и до того, как почитал книжку, никак не выходило у меня с помощью гопоты что-то сделать работающее вообще.

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

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

В предыдущем цикле я рассказывал о том, что такое команда, зачем она нужна и как образуется естественным образом, если ничего специально не делать с точки зрения командостроения. Теперь же я сосредоточусь на том, как строить команду целенаправленно. Начну с описания "матчасти": как устроена командность как феномен, от каких факторов зависит её возникновение, с чем вообще предстоит работать. Дальше будем всё это подробно разбирать. Как всегда, материала получилось много, поэтому разобью его на две части. Сегодня часть 1-я.

Видео
https://www.youtube.com/watch?v=y1vBMyyEA44

Только звук (подкаст)
* Хост на Podster.fm (RSS)
* Apple Podcasts
* YouTube Music
* Яндекс.Музыка

Текстовая версия
1. Постановка задачи
2. Общая структура командности
3. Люди
4. Группа
5. Контекст
6. Выполняемая работа

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

пора и поработать! На этой неделе будут посты.

https://link.springer.com/article/10.1007/s10648-025-10020-8

Любопытное саммари влияния AI на обучение.

domain-specific knowledge is needed for understanding AI outputs in various contexts

не то чтоб новость: для использования результатов LLM надо понимать предметную область.

transversal skills (critical thinking, problem-solving, information literacy, technology literacy, collaboration, communication, and creativity) become increasingly important

ещё и “вокруг” предметной области стоит знать немало, и критическое мышление уметь применять.

students should also be involved in deep learning processes where they synthesize, evaluate, and integrate new and existing knowledge

и вообще, создавать сами новое и закреплять знания, превращая их в умения и навыки.

И вот читаю я это всё и хочу понять: а кто-то научился чему-то новому у LLM? Под "научился" я понимаю не "сделал вместе с" (как обсуждалось тут), а именно "научился", то есть “стал способен теперь сделать сам".

Если научились, то расскажите, как выстраивали процесс своего обучения с LLM пожалуйста. Вот я щас учу французский с учителем, и с LLM просто тренируюсь тому, что уже выучил. Может, есть более крутые работающие способы.

На одном из моих следующих митапов будет выступать товарищ Митеш, занимающийся производством и обслуживанием цифровых копий (digital twins). У них моделей — тьма, от полноценных моделей батарей
до целых медицинских устройств, от тракторов до систем подводных лодок.

Будет рассказывать, что такое вообще эти цифровые копии, где их применяют и почему.

Если кто знаком с темой, или кому тема интересна, задавайте свои вопросы пожалуйста, я постараюсь включить их в доклад.

миллион лет назад делал доклад про PDR , и до сих пор считаю, что любая добавляемая сложность в процессы труда должна быть обоснована не хуже, чем добавление сложности в техническую систему.

инженер не добавляет (я надеюсь) условную кафку просто потому что “кафка это ништяк”, но почему-то этот же инженер становится тимлидом или того хуже СТО и спокойно накидывает в процессы труда всё, что где-то ему казалось прикольным.

вослед за ув. тов. Аланом Холубом хочу собрать набор приемлемых “defaults” для процессов труда.

Начну, наверное, с асинхронности.

Мне видится, что синхронный труд — то есть, mob work — стоит рассматривать как дефолтный, и асинхронность — то есть “декомпозиция” задачи для “разбиения” по отдельным разработчикам — добавляться только после обоснования необходимости.

Ровно так же, кажется, в программирование синхронность — default, и добавление любой асинхронщины мы стараемся обосновывать так, чтоб выгоды было больше, чем сопутствующей цены обслуживания увеличенной сложности.


Upd:
в программировании различие между синхронщиной и асинхронщиной всем вроде известно и понятно, а вот в работе буквально сихнронно это “взяли и сделали все вместе”, а асинхронно это “‘декомпозировали’ задачу, ‘раскидали по людям’, а потом начали играть в пинг-понг со статусами и тикетами в джире”

Следующий “default” который хочется обсудить — отсутствие внешней стимуляции (того, что чаще всего почему-то зовётся “мотивацией”).

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

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

Кажется, отсутствие внешней стимуляции должно быть дефолтным состоянием, и добавление любых форм внешней индивидуальной стимуляции (премии, KPI, грейды, геймификация, доски почёта) должно очень хорошо обосновываться.

Посты на тему: 1, 2, 3.