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

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

Это наверное можно поправить промптом. Но я просто отставил ИИ в сторону когда налетел на проблемы в важных вопросах. Думать надо своей головой. ИИ для другого — это просто тул для обработки текста.

Ну вот, началось то, что и должно было начаться. Опус всем нравится. А вот счета за него — почему-то никому. Он не приносит пользы соразмерной этим деньгам, и честно говоря — в целом приносит ее так мало, что можно относительно легко обойтись вообще без него.

Шесть месяцев назад Microsoft предоставила тысячам инженеров доступ к Claude Code и поощряла их использовать эту платформу.

Инженерам она очень понравилась, и ее популярность резко возросла. Но затем пришли счета.

Ценообразование на основе токенов означает, что каждый запрос, каждый ревью кода, каждая сессия отладки стоит денег. При масштабе в 100 000 инженеров суммы стали настолько большими, что Microsoft издала внутренний приказ отменить почти все лицензии на Claude Code к концу июня и заставить всех перейти на собственный, более дешевый инструмент.

Догадываетесь что будет с дурачками, кто выстроил вокруг доступности Опуса целые стратегии, в которых они с удовольствием срут на головы своим программистам?

https://x.com/Ric_RTP/status/2058546401483653236?s=20

...а теперь Карпатый.

Есть те кто умеет красиво пиздеть. Есть реально умные. А есть те, кто умеет делать так, что оно реально работает.

В общем, Карпатый точно не третье. И люди это знают.

🤖 RAG и роботы

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

И это оказалось вполне реальной альтернативой файнтюнингу. Причём работает оно неожиданно хорошо.

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

С этим пониманием я решил сделать из агента Hermes в моём роботе настоящего специалиста по самому роботу. Сейчас собираю RAG-поиск по учебным материалам и курсам для Rosmaster.

Требования к поиску очень простые:

1. Никаких сервисов: всё должно работать на файлах и скриптах командной строки.
2. Система должна работать поверх папки с множеством Markdown-файлов.
3. При построении индекса нужно учитывать структуру Markdown: заголовки, секции, абзацы.
4. Поиск должен быть гибридным: и по смыслу, и по ключевым словам.

Сейчас сравниваю два варианта: простые скрипты поверх SQLite и отдельное решение на LanceDB.

Честно говоря, я меньше всего ожидал, что первым серьёзным шагом в робототехнике окажется разбирательство с RAG. Но мне нравится этот поворот. Я всё равно давно хотел этим заняться, а тут появился идеальный повод.

Результаты первого этапа экспериментов с RAG

https://github.com/gaperton/ROSMASTER-M3PRO

1. Все руководства переведены из pdf в markdown. Это необходимый первый шаг. Я наконец научился делать это хорошо не руками а автоматически.

2. Написана базовая версия поиска RAG с sqlite. Использованы лучшие стандартные рекомендации, чтобы избежать совсем глупых ошибок. Это гибридный поиск, который объединяет результаты семантического поиска и поиска по ключевым словам. Чанки нарезаются осмысленным образом c cохранением структуры markdown. В общем, реализованы все стандартные советы, минимальная база.

3. Было сделано то же самое при помощи специализированной базы данных LanceDB.

А вот дальше началось интересное. В тесте на поиск LanceDB просрал sqlite. Сильно. Вскрытие показало, что причиной был паршивый алгоритм ранжирования гибридного поиска LanceDB. Прямолинейное ранжирование, которое я сделал руками в sqlite оказалось лучше. И вообще, sqlite оказался лучше примерно всем. По крайней мере, на этом маленьком детасете.

4. Поэтому я отключил встроенное ранжирование LanceDB. И сделал его снаружи, ровно, как сделано в sqlite. Что вдвое замедлило LanceDB. Зато он перестал давать паршивые результаты.

Такого я не ожидал, поэтому решил попробовать другой эксперимент. В котором, по советам бывалых, LanceDB должен был играючи обойти sqlite. Ну должна же специализированная база данных быть в чем-то круче, чем наколенная поделка. cross-encoder's re-scoring и reranker.

Opus был уверен, что это сильно поможет. Это оказалось полным фиаско. После очень жесткой ебли BGE-reranker таки показал лучший результат на размытых запросах. Но испортил простые запросы.

5. Cross-encoder's re-scoring не дал ожидаемых результатов.

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

Поэтому надо все обдумать и будем делать второй этап. А результаты первого описаны в README. Там внутри в репозитории, если кому интересны детали.

👨‍🔬 А жена, посмотрев на все это, сказала, что она не ожидала, что ее муж превратится в безумного ученого из "назад в будущее". Но ит из вот ит из.

🌧 Я же ответил, что газон не пострижен не поэтому, а потому, что дождь идет второй день. Что я могу поделать?

https://github.com/gaperton/ROSMASTER-M3PRO/blob/main/PS-LEDGER.md

Состояние эксперимента, формат для людей и ИИ.

Этот файлик помогает и мне и ИИ помнить что и зачем мы делаем.

Локальный RAG поиск учебному курсу Rosmaster M3 Pro
Фаза 1: Поиск из командной строки

Аннотация

Этот репозиторий представляет собой доступное для поиска офлайн-зеркало учебной документации Yahboom по ROSMASTER M3 Pro и контролируемое исследование качества поиска по этому корпусу. Практический исследовательский вопрос был таким: для фиксированного набора Markdown-руководств, преобразованных с помощью Marker, какая локальная архитектура поиска дает новичкам наиболее релевантные фрагменты источников без использования сетевого сервиса во время запроса?

Итоговая система использует гибридный поиск по 247 Markdown-файлам: эмбеддинги BGE-small, ключевой поиск BM25/FTS, хлебные крошки заголовков, доступные обоим поисковым каналам, Reciprocal Rank Fusion и узкий детерминированный слой повышения рейтинга маршрутов для предсказуемых запросов новичков. На размеченном бенчмарке и sqlite-vec, и LanceDB достигают file MRR 1.000. Chunk MRR составляет 0.613 для sqlite-rag и 0.562 для lance-db-rag. Оставшиеся слабые ответы в основном связаны с ограничениями покрытия корпуса, а не с ошибками ретривера.

Исследовательский вопрос

Может ли полностью локальный RAG-ретривер надежно находить фрагменты, содержащие ответ, для естественно-языковых вопросов новичков по небольшому техническому корпусу материалов по робототехнике, и существенно ли влияет выбранный движок хранения на качество поиска?

https://github.com/gaperton/ROSMASTER-M3PRO

* * *

В общем, эта работа разъебала об стенку несколько мифов. Ряд результатов про которые пишут не удалось повторить.

Теперь берем вариант с sqlite, и делаем на его основе скилл для Гермес — знание о роботе.

И вторая фаза будет — глубокая обработка текста, с созданием онтологии и вики. Это, строго говоря, пост-процессинг материалов и к RAG не относится.

Тем временем, они продолжают говорить о том, как они будут сдавать бога в аренду и никто больше не должен будет думать своей головой. Ура. Наконец-то.

О, в Ватикан уже даже сходили.

https://polymarket.com/event/ai-bubble-burst-by

Я куплю.

Я уже говорил что Qwen3.7 Max хорош?

Вот, он правда очень хорош. Если вы конечно не боитесь заводить аккаунт в Компартии Китая. Бояться наверное есть чего — Qwen делает отличные модели, но плюет на ваше прайваси еще больше чем Гугл.

Qwen мы любим, когда он работает локально.

Грок. Режим ‘Expert’.

Бесполезен примерно полностью. То есть нахуй не нужен ни за какие деньги.

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

Вот это — первая.

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

Кто решил — отпишитесь. После этого покажем вторую, сложную.

Правильный ответ не говорить, просто зарегистрироваться в комментах для второго этапа. Тем кто знает в чем финальное западло — не раскрывать.

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

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

Правильный ответ не говорить, гусарам кто не решал первую — молчать. Сейчас вы увидите невероятное.

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

Наши случайности.

Парное программирование с ИИ и возвращение разговорной разработки ПО — Влад Gaperton Балин

Уже больше двадцати лет историю Agile-разработки часто рассказывают как историю победы Scrum и поражения Extreme Programming. Scrum стал доминирующей организационной рамкой для софтверных команд. XP выжил в основном по частям. Continuous integration стал стандартной практикой. Refactoring вошёл в обычный инженерный словарь. Automated testing во многих местах стал нормой. Но сам XP так и не стал доминирующей методологией.

Обычное объяснение простое: XP был «слишком экстремальным».

Это объяснение не совсем неверное. Но оно поверхностное. Extreme Programming провалился не потому, что его инженерные принципы были ошибочны. Многие из них оказались удивительно живучими. И не потому, что компании иррационально отвергли хорошую инженерную культуру. Более глубокая проблема была в другом: XP требовал такого режима работы, который большинство людей не могли выдерживать.

XP правильно увидел, что разговорное мышление — мощный режим разработки ПО. Проблема была не в когнитивной модели. Проблема была в доступном механизме её реализации: постоянном человеческом парном программировании.

А этот механизм был психологически дорогим.

Современные coding agents меняют механизм реализации. Они позволяют сохранить значительную часть центрального когнитивного процесса XP, убрав многие социальные и психологические издержки, которые исторически мешали XP масштабироваться. Результатом может быть не буквальное возвращение XP как исторической методологии. Возможно, это что-то более важное: первая масштабируемая форма разговорной разработки программного обеспечения.

(продолжение в комментариях)

👆 Это мой гуманистический аргумент в пользу ИИ.

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

Агенты по написанию кода на базе ИИ не смогут буквально «вернуть XP», но они, возможно, наконец-то сделают его основную идею масштабируемой — разработку программного обеспечения как непрерывный диалог, в котором агент выступает в роли критического партнера, а не просто генератора кода.