Уголок Манса 🌌


Kanal geosi va tili: Qozog‘iston, Ruscha


привет, я Мансур – ai разработчик, закончил университет и работаю в Голландии
пишу о своих идеях, проектах и о жизни

Связанные каналы

Kanal geosi va tili
Qozog‘iston, Ruscha
Statistika
Postlar filtri




как проводить autoresearch?

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

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

ещё важно, чтобы каждый результат был привязан к состоянию кода. поэтому eval сам делает git commit до прогона и после, а в json складывает commit hash вместе с метриками. любой результат после этого можно откатить и посмотреть, что там было.

heuristics

вообще подход очень напоминает то, как раньше ML задачи решали через hard-coded rule-based heuristics. со временем это стало уступать машинному обучению, где алгоритм сам находит закономерности. но агенту намного проще перебрать варианты и подобрать то, что работает лучше. более того, можно взять best of both worlds и разрешить ему поставить классический ML поверх этих heuristics, и так же перебрать, какой алгоритм и какие параметры подходят лучше.

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

как позже сформулировал мой коллега,
это не обычный software engineering и не ML training, а что-то посередине, что стало возможным только сейчас. можно просто взять большую языковую модель и поставить её оптимизировать deterministic программу, чтобы она hill-climb какую-то задачу


autoresearch

disclaimer, это моя интерпретация того что Karpathy называет autoresearch. я в то же время думал о схожей идее, но его setup был красиво сделан, поэтому много идей позаимствовал

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

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

мой опыт

проект, над которым я работаю уже 3 года: надо по данным собрать модель здания, то есть понять, как в нём управляется отопление и охлаждение. AI системы, которые ставят поверх building management систем, требуют, чтобы пришёл человек и разметил, какой сенсор чему соответствует и что надо крутить, чтобы поменять температуру. в многоэтажке таких сенсоров бывает больше десяти тысяч, и раньше их размечали руками.

этим у нас занимался Bart. он открывал метаданные сенсоров и разбирал их по одной строке, а метаданные это открытые поля, куда при постройке здания писали кто что хотел. поэтому AI, который должен был лишить его работы, мы назвали Bartender.

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

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

и тут autoresearch всё сложил.
не надо пускать агента по метаданным в runtime, надо чтобы он написал алгоритм, который собирает модель здания.

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

агент начал итерировать regex, и модель стала собираться примерно наполовину, причём вторая половина была скорее угадана. потом он поставил сверху gradient boosting, и то, что раньше угадывалось, стало попадать почти каждый раз. это результат, которого я не ожидал. и подход по метаданным в итоге оказался в разы лучше, чем корреляции.

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


thoughts on building LLM based apps

сейчас у меня каждый проект каким-то образом завязан на LLM. и я заметил что как клиенты так и коллеги не особо видят LLM-ки вне рамок какого-то чата.

то есть, приходит заказ, и либо клиент хочет чтобы была LLM, либо коллеги решают что это идеальный кейс для LLM. и строят прототип где всё завязано вокруг чата. все используют LLM как intelligence двигатель: чтобы он чатился, думал, делал и выдавал результаты.

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

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

llm + embeddings + bm25 + агенты стали современным молотком.


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

моё видение того что работает: использовать LLM не как intelligence двигатель, которому через промпты пытаешься объяснить как что-то сделать и молишься что так и произойдёт всегда. а как инструмент для того чтобы выводить структуры из неструктурированных документов. типичный structured output.

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

это напоминает то что говорил Dijkstra:
чем больше логики уходит в естественный язык, тем сложнее задача для машины. формализм это не неудобство, а привилегия — он позволяет точно выражать мысли и проверять их.


хороший пример этого принципа это hooks в Claude code и других инструментах. это кусок кода который запускается при каком-то event и делает что-то автоматически. например, LLM пытается вызвать npm install или pip install, а у вас надо использовать pnpm или uv. hook останавливает вызов если видит паттерн и сообщает LLM как правильно. таким образом оно всегда будет знать как правильно сделать, а не забывать в длинном разговоре.

второй метод это auto research, но о нём в следующем посте.


*первый день работы над проектом*

так же я и мои два небольших PR:


Секрет лапшичного супа dan repost
Я не большой любитель прикладного fit/predict ML-инжиниринга и кодинга алгоритмов для решения оптимизационных задач. Мне это скучно.

Мне кажется, самое сложное, что в жизни, что в бизнесе — правильно оптимизационную задачу сформулировать. Это интересно и всегда ново. А конкретный алгоритм — это инженерное "сведение задачи к уже решенной".

Ну кто вот, например, мог подумать, что искусственный интелект появится как результат предсказания следующего слова в тескте? Вот это, я понимаю, — классная постановка! Это вызывает максимум моего восхищения.

И вы наверняка знаете, что сейчас машины учатся супер-неэффективно, поэтому человечество в развитых странах переживает, хватит ли у них электричества для AI.

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

Для простоты взяли мир Mario Brothers и 6 кнопок от Nintendo на вход.

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

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

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

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

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

Держите классный подкаст про это на русском:
https://music.yandex.ru/album/10330389/track/81437187

И исходную статью на английском:
https://pathak22.github.io/noreward-rl/

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

А в комментах поделитесь неочевидными постановками задач, с которыми вы сталкивались!


Harness Engineering

I asked our CTO what is the most important problem to work on? The question came from reading Richard Hamming's book: If you do not work on important problems how can you expect to do important work?

CTO's answer was: to build the harness. Build a system where you can make tickets, and those tickets are converted to code by agents, and tickets are produced from design files. Finally, the loop is closed when someone makes a code change that is reflected in the design files, which reflects in done tickets and in code. So, a product can be viewed from three angles: design, tickets and the actual code. Change in any reflects everywhere else. This way anyone, programmer, designer or product manager, can contribute to work done.

This way, we as developers should focus on building the harness for this to be possible. While the products build themselves.

Is this the most important problem? It's risky and ambitious, but that doesn't disqualify it, it might be exactly why it qualifies. The goal should be ambitious and unattainable, serving as a North Star. Better to have a direction than wander aimlessly, another idea from Hamming. The star can be adjusted along the way. And the business case is real: this is what leads to a scale of development that compounds output without compounding headcount.

Harness engineering is not a new idea that came with LLMs. First came RAGs, then tools, then skills. Each time, the work was building the app around the model to get the most out of it.

Boris Cherny, the head of Claude Code at Anthropic, said he no longer prompts Claude directly. "My job is to write loops." In the early days of Claude Code, he wasn't writing code, he was prompting. Now he doesn't prompt, he writes loops, which in turn prompt. The work goes into building the harness which does the work for them.

I don't want to use Claude or ChatGPT's harness. I want a good harness where I can swap the models and customize it. For the last two years I've been trying to build it, but something keeps not adding up. Everyone has their own way of doing subagents, handoffs, remote agents, skills. There's no good reference, you try to reverse engineer their source code.

There is a common denominator to these harnesses, yet it's so hard to pin down. Once you do, it's already outdated and the newest features you want are incompatible with it.

What I've learned is this: I know how to build the chat interface, render tools, wire up a model, ship something that works. What I don't know is how to design what the chat interface is for. The architectural decisions: how to make it extendable, how subagents hand off to each other, how to sandbox it and give it real file system access, how the human actually interacts with it. A remote desktop where they can upload and work with files? An agent linked to the local machine like Claude Code? Either direction is hard to execute.

The scope keeps creeping. I focus on the UI, or I focus on the agent loop, and I can't figure out what the minimal thing is that makes it actually feel like an agent. And when it does, it feels useless. Can't code, can't exit its environment, can't use git.

There's an example worth looking at: Pi agent claims to be the simplest possible harness, stripped of complexity, letting the user ask it to extend itself. The right shape is probably something like that, the slimmest common denominator, extendable from there. My intuition for the interface: a chat UI combined with a file explorer and file worker. Not an IDE, but something adjacent. Cursor is exactly what I picture, but built for programmers.

The common denominator exists. The question is whether anyone will pin it down before it shifts again.


эйай ньюз dan repost
Как попасть на работу в Frontier AI Lab

Вышел хороший пост от чела из DeepMind про то, как попасть в frontier lab сегодня. Автор сейчас lead for Gemini pretraining в GDM, а до этого дропнулся с PhD и пошел в стартап Sisu, где быстро стал Head of ML.

Суть поста коротко: если хочешь попасть в топовую AI-лабу, надо прокачивать mathematical maturity, жутко потеть во время универа (причем задрачивать без использования LLM), уметь очень хорошо кодить, и делать работу на “краях” LLM-стека – снизу kernels / inference / systems / quantization, сверху agents / rigorous evals / agentic loops. Не просто “поиграться с агентами”, а делать технически строгие эксперименты и показывать вклад, который реально нужен frontier labs.

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

Не весь интересный frontier-level research вне топ-лаб ограничивается разработкой кернелов, low-level оптимизациями LLM и написанием агентских врапперов.

И чтобы заниматься frontier research, не обязательно идти только в большие лабы типа OpenAI, Anthropic, Meta Superintelligence Labs или GDM.

Frontier-level research можно делать и в стартапах на более ранних стадиях. И часто там у вас будет в разы больше ownership, а рост по карьере и по скиллам будет намного быстрее.

Иронично, что сам автор как раз так и сделал: дропнулся с PhD, пошел в стартап, быстро стал Head of ML – и уже после этого попал в Google, причем сразу на Staff-level позицию.

В стартапах есть куча фундаментально интересных задач, где не нужны $100M+ бюджеты. Есть задачи, для которых достаточно “двузначных миллионов”, сильной команды и правильного технического фокуса.

А в бигтехе, если ты не Director+, ты часто просто взаимозаменяемый винтик, которому дают потрогать маленькую фичу в огромной системе. Ownership минимальный, scope ограничен, выбиться на следующий уровень очень и очень трудно. Большинство людей до Staff+ никогда в жизни так и не дорастают.

Да, стартапов, где реально сильная команда и где можно делать фундаментальные вещи, не так много. Но именно в такие стартапы можно попасть на восходящей траектории карьерного роста — когда у тебя еще нет крутого track record, который нужен, чтобы хотя бы пройти скрининг в топовую большую лабу, но видно как ты резко ускоряешься. (Именно такой принцип я и применяю, когда отбираю более молодых кандидатов к себе в стартап)

И там намного больше пространства для роста. Никто не будет искусственно ограничивать тебя в scope. Всё зависит от тебя: насколько ты готов ебашить, брать ответственность и тащить сложные куски.

Кстати, раз уж заговорили про стартапы: мы в GenPeach AI всегда рады пообщаться с выдающимися кандидатами на позицию AI Research Scientist. Это как раз роль про работу над foundation models - не “AI wrappers”, а pre-train и post-train своих large-scale моделей, O(PB) данные, SOTA ресерч по кастомным архитектурам и методам контроля генерации.

@ai_newz #карьера


mind the gap


HN Best Comments dan repost
Re: Talking to 35 Strangers at the Gym

One of the things I like about this is that OP is giving people genuine compliments without any particular agenda.

It reminds me of one of my favorite parts of How to Win Friends and Influence People by Dale Carnegie, where he tells a story about complimenting someone, and a student asks what he was hoping to gain from offering the compliment. Carnegie is incensed:

> I was waiting in line to register a letter in the Post Office at Thirty-Third Street and Eighth Avenue in New York. I noticed that the registry clerk was bored with his job[...] So while he was weighing my envelope, I remarked with enthusiasm: “I certainly wish I had your head of hair.”

> He looked up, half-startled, his face beaming with smiles. “Well, it isn’t as good as it used to be,” he said modestly. I assured him that although it might have lost some of its pristine glory, nevertheless it was still magnificent. He was immensely pleased. We carried on a pleasant little conversation, and the last thing he said to me was: “Many people have admired my hair.”

> I told this story once in public; and a man asked me afterwards: “What did you want to get out of him?”

> What was I trying to get out of him!!! What was I trying to get out of him!!!

> If we are so contemptibly selfish that we can’t radiate a little happiness and pass on a bit of honest appreciation without trying to screw something out of the other person in return—if our souls are no bigger than sour crab apples, we shall meet with the failure we so richly deserve.

> Oh yes, I did want something out of that chap. I wanted something priceless. And I got it. I got the feeling that I had done something for him without his being able to do anything whatever in return for me. That is a feeling that glows and sings in your memory long after the incident is passed.

mtlynch, 2 hours ago


с прошлых Рамаданов понял что лучше не пить кофе на сухур, а то будет сушняк и не пить кофе на ифтар, так как не усну. так и не пил кофе весь месяц. мой друг потом мне сказал что самый лучший кофе будет на день айта, and it was :)

eid mubarak ✨


is there a seahorse emoji?

a simple way to eat all of someone's tokens... I had to restart my server to make sure the request was stopped omg

i like how it tries to make one, realises it's not it and gets stuck in an inf loop


Devs.kz dan repost
Стартуем стрим через 5 минут https://www.youtube.com/watch?v=2tTWxv5qelM


Рад поделиться, что буду выступать на AMA session для @devs_kz! Обязательно приходите завтра 🙂

За 3 года я и Амир работали вплотную с нашими родителями, чтобы автоматизировать их оптовый бизнес. Мы сделали 9+ приложений для разных задач: импорт товаров, планирование заказов и дистрибуции, генерация стикеров для продуктов, управление складскими запасами и многое другое.

Бизнес был сильно зависим от таких инструментов, как 1С, Excel, жесткий диск моей мамы (десятилетие данных, никаких бэкапов), чаты в WhatsApp для управления задачами, планирование логистики без карт, а склад полностью зависел от чьей-то памяти.

Для меня it clicked, когда мы завершили наше первое веб-приложение, Marketplace. Раньше, чтобы найти хороший продукт, маме нужно было перебирать сотни Excel файлов и копипастить строки из нескольких таблиц, чтобы просто составить предложение. Представьте, потратить часы на составление предложения, а клиент смотрит на него 10 минут и ничего не выбирает. Это делает работу такой мучительной. Теперь у неё есть веб-приложение, похожее на интернет-магазин, где всё присутствует, отмечено тегами, записано с заметками и т.д. Я рад, что ей больше не нужно через это проходить, и она может тратить время на soft stuff — ездить в поисках новых идей, общаться с клиентами и т.д.


В целом, мы заметили эффект: количество работников не изменилось, но объём выполненной работы выше, люди счастливее, и некоторые даже уходят с работы раньше.

Думаю, нам есть чем поделиться, так что присоединяйтесь завтра — ждем ваших вопросов!!!! так же можете оставить их в комментарии под постом :)

🤩 ссылка на стрим
🤩 5 февраля, 16:15 (GMT +5)


low-level agentic loops

сейчас для имплементации популярны provider agnostic библиотеки типа ai/sdk или pydantic ai. это реально удобно когда не надо париться об api calls разных провайдеров и можно в любой момент просто свапнуть модельку не переписывая код. я сам ими пользовался с самого начала и мне очень заходило.

но есть нюанс, который я сначала не замечал: эти библиотеки навязывают свои абстракции поверх обычных raw api calls.

типичный пример – класс Agent. он берет prompt, tools, ставишь ему max steps и он сам там внутри крутит цикл. но ты хз как(*). и как только нужен more low level control, начинаются костыли.

например, я хочу динамически менять prompt или tools прямо во время работы агента. в библиотеках для этого приходится либо все прерывать и перезапускать заново, либо пытаться использовать библиотеку как raw api, но это такой гемор, что проще уже без неё.

этой зимой решил написать проект вообще без этих оберток, на raw api calls(**). и это был прям отличный learning experience. оказалось, что в логике агента вообще ничего сложного нет (см. код выше прикрепил), зато у тебя полный контроль над всем процессом.

хочешь ограничить шаги? используешь for или break condition вместо while. хочешь обновить системный промпт? обновляешь message array перед след шагом. need to stream tool call progress to client? тоже просто.

даже сам факт того что ты видишь где tools вызываются у себя на бэкенде, думать о agent patterns становятся намного понятнее.

юзать библиотеки прикольно для скорости на старте, но когда нужен more granular control, реально стоит переходить на уровень api. а то получается, что вместо решения задачи ты борешься с ограничениями библиотеки, типа, пытаясь «упростить» тебе жизнь.

* – даже этот факт усложныет. для дебагинга нужно добавлять traces telemetry, иначе никак
** – я все равно использовал библиотеку, litellm, но это реально raw


самое relatable описание что я читал

И человек с идеями теряется – у него впервые в истории ИТ развязаны руки, он перепробовав все, не знает из чего выбрать, потому что идей, впервые, не больше чем ресурсов и терминал теперь источник эндорфина, не рилсы-тиктоки, даже не игры – мечта детства, всемогущая терминальная сила теперь стоит 200$ в месяц


I guess, I'm a vibe addict ☕️

src: https://t.me/denissexy/11183


I really want to spend some time improving my ai workflow


привет!

меня зовут мансур. я из казахстана, но уже три года живу и работаю в голландии мл инженером.

этот канал долго был просто местом для друзей, но сейчас нас уже 200+, так что пора знакомиться :))

я работаю в аутсорсе, поэтому проекты меняются каждые полгода. сейчас в основном занимаюсь стартапом в сфере building automation — помогаем экономить энергию с помощью данных. на стороне много погружаюсь в llm проекты.

начал учить мл еще в школе, а работу нашел в конце первого курса универа – рассказал о себе, а CEO спросил на каком я курсе магистратуры. на следующий день получил оффер. alhamdulillah, серьезно так я и начал 😳

помимо мл, я люблю фронтенд и сейчас плотно закрываю пробелы в бэкенде.

▫️ почему уголок манса?
манс — так меня называют братишки/друзья.

▫️ о чем этот канал?
я пишу о своем пути и о том, что узнаю по ходу.
иногда это про ии и технологии, иногда — душевно о том, как я учу свою сестренку кодить. это пространство для рефлексии, моих маленьких опытов и пет-проектов.

я люблю структурировать знания, поэтому скоро будут ссылки на лонгриды на сайте, а здесь самое важное и to the point 😉

▫️ кто я еще?
я jack of all trades. обожаю коллекционировать скиллы: от карточных фокусов (занимался 8 лет) и жанглерства до починки велосипедов и пленочной фотографии. бегаю, занимаюсь калистеникой и читаю (*)

мне нравится пробовать новое и делиться этим.

рад, что вы здесь. welcome to the journey.

(*) делитесь своими рекомендациями для книг, вот мои, я им всегда рад ;)

@mansur_corner


AI и грабли dan repost
Делать прогнозы – дело неблагодарное. Но полезное. Заставляет оглянуться назад и отделить хайп от долгосрочных трендов. Пока катался по горам на байке, наформулировал три прогноза, которые меняют мои планы в 2026ом

1️⃣ Claude Code как агентное ядро для любой нишевой херни.

Что произошло ближе к концу 2025 года – агентность моделей прокачалась достаточно, чтобы уйти от фиксированных воркфлоу к гибким агентным системам. Теперь системы принимают решения о следующем шаге на основе инфы с предыдущего. И это наконец-то работает не только в презентациях

Вот только делать свою агентную систему – запарно. А хорошую агентную систему – еще запарнее. И особенно бомбит от осознания, что повторяешь все шишки, которые уже набили разработчики топового general-purpose агента – Claude Code

Вы скажете, что это специализированный агент для кодинга, но это не так. Любой кастомный агент так же обрастает вызовом тулов, сэндбоксом для запуска скриптов и динамическими промптами aka skills

Все больше команд вместо костыляния своих агентнов, будут брать Claude Agent SDK, докидывать ему нужные скиллы, MCP, рулсы и оборачивать в понятный простому пользователю UI вместо терминала. В конце поста – ссылка на крутой кейс от Рефата

2️⃣ Skills станут более популярными, чем MCP

Для меня и MCP выглядел странно как стандарт. Типа, просто зафиксировали формат вызова внешнего API в виде function calling. А где рокет саенс?

Но это дало простой унифицированный способ подключать внешние инструменты к LLMкам. А во многих компаниях "мы делаем свой MCP" вообще стало самым простым способом для топов отчитаться о наличии "AI стратегии" 📈

Skills – еще более простая штука. По сути – просто папочка с промптами + набор скриптов. У большинства опытных пользователей это и так было – помогает не засирать контекст сотней тулов какого-нибудь github mcp, а просто описать как пользоваться такой волшебной командой как git. А в большинстве случаев даже детали не нужны – ведь агент может просто вызвать --help

А тот факт, что они подгружаются динамически (в зависимости от текущей задачи) – убирает главное ограничение MCP

3️⃣ Стандартный работающий подход к архитектуре постоянной памяти агентов

Это прям новый тейк, родившийся во время разбора лидерборда ERC-3 (соревнование по построению агентских систем)

Я если честно думал, что мы еще далеко от самообучающихся систем. Да, что-то понемногу начинает работать, и даже Claude Code может сам корректировать свой CLAUDE.md, но это детский сад, если честно.

А тут кейс, где цифры говорят сами за себя. В ERC-3 с отрывом аж в 10 процентных пунктов (71.8% vs 62.1%) побеждает решение, где агент сам обучается и "запоминает" результаты предыдущих неудачных попыток.

Да, там это скорее хак – агент делает выводы по прогону сразу на всей паре сотен задач, а не на каждой индивидуально, но это не важно. Важно – что система вообще сходится к оптимуму, сама переписывая свой промпт. В 2024ом у меня такое не работало – ее болтало из стороны в сторону.

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

4️⃣ (бонус)

Нормальные Tools уже есть – модели уже берут инфу из внешнего мира (и помещают в него обратно). Если будет нормальная внешняя память, то собственные знания модели обо всем на свете – не нужны.

Даже маленькая модель, которая почти ничего не знает, но умеет обращаться с тулами, выявлять паттерны и запоминать точечную информацию – будет эффективнее, чем жирная модель без всего этого. Жду появления быстрых и дешевых LLMок на 1-2b параметров, в которых большая часть весов – не знания, а навыки. Такие execution engine

Ставим ставки?
Если есть другие любопытные прогнозы – делитесь в комментах, интересно, что думаете

Почитать:
- Пост Рефата про Claude Code в качестве agentic core
- Лидерборд соревнования ERC3 с описанием архитектур


тул чтобы чистить память на макбуке – освободил 30гб!

каждый день начинаю с уведомления "у вас почти закончилась память" , всего у меня 256гб

куча проектов; всякие .venv и node_modules, uv папки с гигабайтами кода, не говоря уже о docker и другом кэше

mole чистит все эти файлы

запусакется одной коммандой mo clean , всегда под рукой, бесплатно

как только очистил сразу захотел написать пост, кайф, как буд-то заложенный нос отпустило вахвхах

оч рекомендую, drop them a star on github :)

https://github.com/tw93/Mole

20 ta oxirgi post ko‘rsatilgan.