Gaperton's Tech Corner
В роботе оказалось AI приложение, построенное на Dify. И это первая вещь, про которую они рассказывают в своем учебном курсе. Dify — это платформа с открытым исходным кодом для создания рабочих процессов с использованием агентов. Она позволяет визуально…
🤖 RAG и роботы
После разбирательства с роботом выяснилось, что RAG внутри используют не столько для поиска по большим текстам, сколько для сборки точных промптов под конкретные ситуации — из небольшой базы заранее подготовленных правил.
И это оказалось вполне реальной альтернативой файнтюнингу. Причём работает оно неожиданно хорошо.
По сути, под RAG кладут список условных рефлексов: “если ситуация такая, надо действовать так-то и так-то”. База небольшая, но RAG вытягивает из неё нужный фрагмент под текущий контекст и точечно дополняет промпт. Получается что-то очень похожее на ассоциативную память у человека.
С этим пониманием я решил сделать из агента Hermes в моём роботе настоящего специалиста по самому роботу. Сейчас собираю RAG-поиск по учебным материалам и курсам для Rosmaster.
Требования к поиску очень простые:
1. Никаких сервисов: всё должно работать на файлах и скриптах командной строки.
2. Система должна работать поверх папки с множеством Markdown-файлов.
3. При построении индекса нужно учитывать структуру Markdown: заголовки, секции, абзацы.
4. Поиск должен быть гибридным: и по смыслу, и по ключевым словам.
Сейчас сравниваю два варианта: простые скрипты поверх SQLite и отдельное решение на LanceDB.
Честно говоря, я меньше всего ожидал, что первым серьёзным шагом в робототехнике окажется разбирательство с RAG. Но мне нравится этот поворот. Я всё равно давно хотел этим заняться, а тут появился идеальный повод.
После разбирательства с роботом выяснилось, что RAG внутри используют не столько для поиска по большим текстам, сколько для сборки точных промптов под конкретные ситуации — из небольшой базы заранее подготовленных правил.
И это оказалось вполне реальной альтернативой файнтюнингу. Причём работает оно неожиданно хорошо.
По сути, под RAG кладут список условных рефлексов: “если ситуация такая, надо действовать так-то и так-то”. База небольшая, но RAG вытягивает из неё нужный фрагмент под текущий контекст и точечно дополняет промпт. Получается что-то очень похожее на ассоциативную память у человека.
С этим пониманием я решил сделать из агента Hermes в моём роботе настоящего специалиста по самому роботу. Сейчас собираю RAG-поиск по учебным материалам и курсам для Rosmaster.
Требования к поиску очень простые:
1. Никаких сервисов: всё должно работать на файлах и скриптах командной строки.
2. Система должна работать поверх папки с множеством Markdown-файлов.
3. При построении индекса нужно учитывать структуру Markdown: заголовки, секции, абзацы.
4. Поиск должен быть гибридным: и по смыслу, и по ключевым словам.
Сейчас сравниваю два варианта: простые скрипты поверх SQLite и отдельное решение на LanceDB.
Честно говоря, я меньше всего ожидал, что первым серьёзным шагом в робототехнике окажется разбирательство с RAG. Но мне нравится этот поворот. Я всё равно давно хотел этим заняться, а тут появился идеальный повод.
👍11❤3
Gaperton's Tech Corner
🤖 RAG и роботы После разбирательства с роботом выяснилось, что 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
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. Там внутри в репозитории, если кому интересны детали.
GitHub
GitHub - gaperton/ROSMASTER-M3PRO: ROSMASTER M3 Pro ROS2 Robot for Jetson NANO B01/Orin NX SUPER/Orin NANO SUPER/RPi 5
ROSMASTER M3 Pro ROS2 Robot for Jetson NANO B01/Orin NX SUPER/Orin NANO SUPER/RPi 5 - gaperton/ROSMASTER-M3PRO
🔥6👍3
Gaperton's Tech Corner
Результаты первого этапа экспериментов с RAG https://github.com/gaperton/ROSMASTER-M3PRO 1. Все руководства переведены из pdf в markdown. Это необходимый первый шаг. Я наконец научился делать это хорошо не руками а автоматически. 2. Написана базовая версия…
👨🔬 А жена, посмотрев на все это, сказала, что она не ожидала, что ее муж превратится в безумного ученого из "назад в будущее". Но ит из вот ит из.
🌧 Я же ответил, что газон не пострижен не поэтому, а потому, что дождь идет второй день. Что я могу поделать?
🌧 Я же ответил, что газон не пострижен не поэтому, а потому, что дождь идет второй день. Что я могу поделать?
😁7❤5🤷♂1🤝1
Gaperton's Tech Corner
👨🔬 А жена, посмотрев на все это, сказала, что она не ожидала, что ее муж превратится в безумного ученого из "назад в будущее". Но ит из вот ит из. 🌧 Я же ответил, что газон не пострижен не поэтому, а потому, что дождь идет второй день. Что я могу поделать?
This media is not supported in your browser
VIEW IN TELEGRAM
https://github.com/gaperton/ROSMASTER-M3PRO/blob/main/PS-LEDGER.md
Состояние эксперимента, формат для людей и ИИ.
Этот файлик помогает и мне и ИИ помнить что и зачем мы делаем.
Состояние эксперимента, формат для людей и ИИ.
Этот файлик помогает и мне и ИИ помнить что и зачем мы делаем.
Gaperton's Tech Corner
Результаты первого этапа экспериментов с RAG https://github.com/gaperton/ROSMASTER-M3PRO 1. Все руководства переведены из pdf в markdown. Это необходимый первый шаг. Я наконец научился делать это хорошо не руками а автоматически. 2. Написана базовая версия…
Локальный 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 не относится.
Фаза 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 не относится.
GitHub
GitHub - gaperton/ROSMASTER-M3PRO: ROSMASTER M3 Pro ROS2 Robot for Jetson NANO B01/Orin NX SUPER/Orin NANO SUPER/RPi 5
ROSMASTER M3 Pro ROS2 Robot for Jetson NANO B01/Orin NX SUPER/Orin NANO SUPER/RPi 5 - gaperton/ROSMASTER-M3PRO
👏2
Занимательная задачка. Состоит из двух частей — первая простая, вторая сложная.
Вот это — первая.
Разделить фигуру на четыре равных части. Не обязательно по границам клеток, можно рисовать где угодно.
Кто решил — отпишитесь. После этого покажем вторую, сложную.
Правильный ответ не говорить, просто зарегистрироваться в комментах для второго этапа. Тем кто знает в чем финальное западло — не раскрывать.
Вот это — первая.
Разделить фигуру на четыре равных части. Не обязательно по границам клеток, можно рисовать где угодно.
Кто решил — отпишитесь. После этого покажем вторую, сложную.
Правильный ответ не говорить, просто зарегистрироваться в комментах для второго этапа. Тем кто знает в чем финальное западло — не раскрывать.
Стоимость моделей.
OpenAI и Anthropic — говенные модели, которые они продают себе в убыток. Пользуйтесь пока дают.
А так — сюрприз. Нормальные модели у гугл и квен.
OpenAI и Anthropic — говенные модели, которые они продают себе в убыток. Пользуйтесь пока дают.
А так — сюрприз. Нормальные модели у гугл и квен.
Gaperton's Tech Corner
Занимательная задачка. Состоит из двух частей — первая простая, вторая сложная. Вот это — первая. Разделить фигуру на четыре равных части. Не обязательно по границам клеток, можно рисовать где угодно. Кто решил — отпишитесь. После этого покажем вторую,…
Первая была разминка, вторая по настоящему сложная.
Разделить фигуру на пять равных частей. Не обязательно по границам клеток, можно рисовать где угодно.
Правильный ответ не говорить, гусарам кто не решал первую — молчать. Сейчас вы увидите невероятное.
Тем кто все-таки смог это решить после первой — пишите сколько это у вас заняло. Тем кто не смог — не расстраивайтесь, на нейпосле первой даже международные олимпиадники втупливают. Когда я покажу решение — будете на стенку лезть клацая зубами.
Разделить фигуру на пять равных частей. Не обязательно по границам клеток, можно рисовать где угодно.
Правильный ответ не говорить, гусарам кто не решал первую — молчать. Сейчас вы увидите невероятное.
Тем кто все-таки смог это решить после первой — пишите сколько это у вас заняло. Тем кто не смог — не расстраивайтесь, на ней
🥰3❤1
Парное программирование с ИИ и возвращение разговорной разработки ПО — Влад Gaperton Балин
Уже больше двадцати лет историю Agile-разработки часто рассказывают как историю победы Scrum и поражения Extreme Programming. Scrum стал доминирующей организационной рамкой для софтверных команд. XP выжил в основном по частям. Continuous integration стал стандартной практикой. Refactoring вошёл в обычный инженерный словарь. Automated testing во многих местах стал нормой. Но сам XP так и не стал доминирующей методологией.
Обычное объяснение простое: XP был «слишком экстремальным».
Это объяснение не совсем неверное. Но оно поверхностное. Extreme Programming провалился не потому, что его инженерные принципы были ошибочны. Многие из них оказались удивительно живучими. И не потому, что компании иррационально отвергли хорошую инженерную культуру. Более глубокая проблема была в другом: XP требовал такого режима работы, который большинство людей не могли выдерживать.
XP правильно увидел, что разговорное мышление — мощный режим разработки ПО. Проблема была не в когнитивной модели. Проблема была в доступном механизме её реализации: постоянном человеческом парном программировании.
А этот механизм был психологически дорогим.
Современные coding agents меняют механизм реализации. Они позволяют сохранить значительную часть центрального когнитивного процесса XP, убрав многие социальные и психологические издержки, которые исторически мешали XP масштабироваться. Результатом может быть не буквальное возвращение XP как исторической методологии. Возможно, это что-то более важное: первая масштабируемая форма разговорной разработки программного обеспечения.
(продолжение в комментариях)
Уже больше двадцати лет историю Agile-разработки часто рассказывают как историю победы Scrum и поражения Extreme Programming. Scrum стал доминирующей организационной рамкой для софтверных команд. XP выжил в основном по частям. Continuous integration стал стандартной практикой. Refactoring вошёл в обычный инженерный словарь. Automated testing во многих местах стал нормой. Но сам XP так и не стал доминирующей методологией.
Обычное объяснение простое: XP был «слишком экстремальным».
Это объяснение не совсем неверное. Но оно поверхностное. Extreme Programming провалился не потому, что его инженерные принципы были ошибочны. Многие из них оказались удивительно живучими. И не потому, что компании иррационально отвергли хорошую инженерную культуру. Более глубокая проблема была в другом: XP требовал такого режима работы, который большинство людей не могли выдерживать.
XP правильно увидел, что разговорное мышление — мощный режим разработки ПО. Проблема была не в когнитивной модели. Проблема была в доступном механизме её реализации: постоянном человеческом парном программировании.
А этот механизм был психологически дорогим.
Современные coding agents меняют механизм реализации. Они позволяют сохранить значительную часть центрального когнитивного процесса XP, убрав многие социальные и психологические издержки, которые исторически мешали XP масштабироваться. Результатом может быть не буквальное возвращение XP как исторической методологии. Возможно, это что-то более важное: первая масштабируемая форма разговорной разработки программного обеспечения.
(продолжение в комментариях)
❤12🔥1
Gaperton's Tech Corner
Парное программирование с ИИ и возвращение разговорной разработки ПО — Влад Gaperton Балин Уже больше двадцати лет историю Agile-разработки часто рассказывают как историю победы Scrum и поражения Extreme Programming. Scrum стал доминирующей организационной…
https://x.com/gaperton/status/2060586049705812467
AI coding tools may finally make the best idea of Extreme Programming practical.
XP was not really about rituals. Its core idea was simple: software gets better when programming becomes a continuous conversation — explain the idea, question the design, write tests, refactor, correct mistakes early.
The problem was that doing this with another human all day is exhausting. Pair programming works, but it is socially and mentally expensive.
AI changes that. A good coding agent can act as a tireless second mind: challenge assumptions, suggest tests, notice inconsistencies, help refactor, and keep architectural context in view.
This is not “AI writes code, human approves.” That is just delegation.
The interesting model is AI as a real programming pair: not an oracle, not a servant, but a critical partner in the thinking process.
If that works, AI will not just make coding faster. It may bring back the part of XP that mattered most: continuous feedback while the software is still being shaped.
X (formerly Twitter)
Vlad Balin (@gaperton) on X
AI Pair Programming and the Return of Conversational Software Engineering
👏4
👆 Это мой гуманистический аргумент в пользу ИИ.
Он, как вы видите, существенно отличается от того, что звучит сейчас в публичном пространстве.
Агенты по написанию кода на базе ИИ не смогут буквально «вернуть XP», но они, возможно, наконец-то сделают его основную идею масштабируемой — разработку программного обеспечения как непрерывный диалог, в котором агент выступает в роли критического партнера, а не просто генератора кода.
Он, как вы видите, существенно отличается от того, что звучит сейчас в публичном пространстве.
Агенты по написанию кода на базе ИИ не смогут буквально «вернуть XP», но они, возможно, наконец-то сделают его основную идею масштабируемой — разработку программного обеспечения как непрерывный диалог, в котором агент выступает в роли критического партнера, а не просто генератора кода.
👍5❤3
Gaperton's Tech Corner
👆 Это мой гуманистический аргумент в пользу ИИ. Он, как вы видите, существенно отличается от того, что звучит сейчас в публичном пространстве. Агенты по написанию кода на базе ИИ не смогут буквально «вернуть XP», но они, возможно, наконец-то сделают его…
Да, парно к этому я сейчас свою теорию эмоций заканчиваю, в которой предлагается новый режим интеграции LLM в рассуждения (имеется в виду под моим схоластическим промптом, конечно же).
Это очень хорошая и практичная теория эмоций, увидите.
Коучем я работать не собираюсь, так что мне искренне пох на популярность. Это из любви к искусству.
Это очень хорошая и практичная теория эмоций, увидите.
Коучем я работать не собираюсь, так что мне искренне пох на популярность. Это из любви к искусству.
Люди представляют собой многоуровневые системы управления, а не прозрачные рациональные агенты. Телесно-аффективный уровень генерирует быстрые оценки посредством телесных ожиданий, валентности и готовности к действию. Лингвистико-символический уровень преобразует эти оценки в доводы, истории, планы и обоснования. Несогласованность возникает, когда эти два уровня по-разному оценивают одну и ту же ситуацию или когда вербальный уровень рационализирует аффективное движение, которое он не понял.
Стоическая теория эмоций определяет решающий регуляторный момент: переход от впечатления к согласию. Теория оценки объясняет, как впечатление приобретает эмоциональное значение. Внимательность улучшает доступ к ранним телесным сигналам, делая впечатление видимым, прежде чем оно затвердеет в страсть.
LLM можно добавить в качестве внешнего диалогического слоя, который усиливает рефлексивную оценку, но только при критическом использовании; в противном случае он становится машиной для рационализации импульсов Системы 1.
👍4👀3🔥1
Через четыре дня после того, как OpenAI в тайне подала заявку на IPO с оценкой в 1 триллион долларов, Альтман вышел на сцену в Сиднее и заявил, что «рад тому, что ошибался» в отношении того, что ИИ уничтожит рабочие места.
В ту же неделю Амодей изменил свой прогноз. Компания Anthropic планирует провести собственное IPO в октябре с оценкой в 900 миллиардов долларов.
Журнал Fortune назвал это скоординированными действиями, и они не ошибаются.
https://x.com/Ric_RTP/status/2060724933248831725?s=20
Я реально поражаюсь, как им сходит с рук этот откровенный скам. И почему у меня ощущение, что я один, кто это видит.
Впрочем это как раз понятно почему. Ощущают-то почти все. Но пока эта интуиция не вербализована правильно, её нельзя ни понять ни рассказать. И пока это так, есть plausible deniability, и эти мерзавцы могут продолжать делать вид что все нормально.
Почему собственно и важно иметь нормальные соцсети без цензуры.
X (formerly Twitter)
Ricardo (@Ric_RTP) on X
Sam Altman and Dario Amodei just got caught running a $2 trillion scam on the entire world.
The timing exposes EVERYTHING:
Four days after OpenAI secretly filed for a $1 trillion IPO, Altman wen…
The timing exposes EVERYTHING:
Four days after OpenAI secretly filed for a $1 trillion IPO, Altman wen…
Результаты этого опроса показывают, что более 80 % компаний пока не зафиксировали роста производительности благодаря ИИ, несмотря на миллиардные вложения.
Среди 6 000 руководителей треть опрошенных заявили, что используют ИИ, но лишь в течение 90 минут в неделю.
И это несмотря на то, что большинство респондентов считают, что в ближайшие 3 года ИИ повысит производительность на 1,4%, сократит штат на 0,7% и увеличит объем производства на 0,8%.
Из числа руководителей треть заявила, что использует ИИ в работе, но в среднем лишь около 1,5 часа в неделю. При этом 25% опрошенных пока не используют ИИ.
https://x.com/rohanpaul_ai/status/2060679110826094724?s=20