OpenAI и жиза про память от Дяди.

Все уже слышали про новый апдейт памяти от OpenAI? Кстати, прошел ровно год считай с анонса этой фичи, и Дядя по этому поводу писал об этом и о своих мыслях о памяти. Дядя занимается памятью тоже, ибо для ассистентов и агентов это важная фича.

Самое интересное,что по обещанным новшествам:
- помнит не только факты, но и старые контексты с чатов
- как следствие понимает стиль юзера и апает персонализацию.

Далее прокомментирую апдейт. Но начну с личного опыта – расскажу вам, как сейчас на рынке +/- устроена память:

1. Old style. 😦
На сценарном движке зашито в виде слотфиллинга. Слотфиллинг это алгоритм заполнения автоматом с учетом распознования намерения слотов (ключей в json), позволяет лучше держать контекст и не перезадавать тупых вопросов.
Сюда же относится всякий NER/ классификаторы, которые и могут делать span extraction и классификацию тематик интересов, к примеру. Они же в слотфиллинге занимают роль моделек для заполнения.

2. In long context we trust. 😏
Предлагается "бесконечная память" на основе жирного и потенциально эффективного контекста (нет), тк в вашей системе врядли найдутся юзеры с диалогами на 10М токенов. Тут все понятно, писал об этом здесь. Главное,что на практике совать память в контекст, без вырезки как это делает, к примеру DeepSeek R1 с "думающими" токенами и областью между ними, будет больно. На нашем опыте глюки обеспечены. Поэтому нужно предусмотреть механизм: "контекст-последняя реплика-память-ответ-вырезать память из контекста и по кругу".

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

4. Готовим из памяти RAG'у.
Есть любители и такой кухни. Могут тупо хранить эмбы диалогов+сам текст по юзеру с dialogue_id. Далее, использовать в контексте или всегда по умолчанию делая ретрив или умно, к примеру, отсекая по скору ранкера или вовсе перенося на функцию памяти принятие решения. Также можно умно нарезать диалог, прося саму LLM вырезать те спаны текста,что она считает полезными для хранения,тем самым не хранить диалоги, а только их важные кусочки. Можно и не LLM просить, а те ner extractor, из пункта выше, вариантов масса. А так действительно зачем нам всякие смолтоки мусорные аля: "
-привки,
-даров,
-как дела?
-,ок,
-ну лан".

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

Вызовы с RAG памятью состоят в том,чтобы думать за инфру хранения: обновления индекса по юзеру "на лету", памяти где бы столько взять (юзер-то не один) и т.п. В остальном вполне себе решение. Это помимо логики нарезки и ретрива.

4. Structured output (SO) +Function calling 🧠.
Пример глобальной памяти на SO. Необходимо создать систему, которая понимает, когда забрать инфо из контекста и положить в память, или наоборот, выдать релевантные факты из памяти в контекст для использования. Остаются вопросы, кто экстрактит данные, как писать в память и возвращать обратно. Продумать шаблон хранения памяти и форматирования контекста. Сделав это, можно жить и так, а можно все фишки сверху накрутить. Хранить при помощи саммари в ключах SO памяти, или иметь доп ретрив логику. Экстрактить можно LМкой в память инфо, а можно аля слотфиллинг, при помощи NER. Функции можно роутить LLM, можно юзать классификатор или эмбеддер аля, как в RAG. В общем этот пункт может быть наиболее зрелым, но свои вызовы тут тоже есть, особенно если микстить с предыдущими подходами и наследовать их проблемы.

Итого, что может быть у OpenAI. Дядя думает,что микст long context + RAG или + SO/function call.

А что выберите или выбрали вы? Пишите в комментариях.

Интересно, реально или вранье, чтобы нагнать классы? 🤔

https://lifehacker.ru/perplexity-v-telegram/

AirFlow, MLFlow, DVC, ClearML?? Пффф. InstructPipe от Google!!!

Вот тебе шкет, к вайб кодингу еще и вайб пайпинг. Фу, звучит даже противно.
Крч берёшь, пишешь инструкцию к LLM для ML пайпа и получаешь псевдокод, псевдо инструкцию, и псевдо интерпретацию. 🤣🤣🤣
Шучу, получаешь крч ток псевдо код, пайп и блоксхемку.
Делоешь, вайб автомотизируешь и койфуешь.


https://research.google/blog/instructpipe-generating-visual-blocks-pipelines-with-human-instructions-and-llms/

Говорил ж Дядя, что не верь ушам своим, верь глазам и рукам. 🛑 И что сам можешь проверить и убедиться. А не то, что там они в своих тех. репортах пиарят. 😩

Мало иметь большой контекст, когда нужен эффективный. И дай бог он 128к будет. 🥲

Вот смотрите, ребятки разобрали NoLiMA об этом. 😘

Читаем, образовываемся.

GenAI в угоду юзеру.

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

Первое. Снова мастер стандартизации в ИИ - Антропик опубликовали исследование об использовании копайлотов для кодирования. По результатам анализа фокус группы получаем цифры.
Code Claude используется для кодинга вместо юзера в 79% случаев, т.е. юзер делает минимум работы по проверке и правке и почти сразу переиспользует генерацию.

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

И тут врубается второе исследование Стенфордского университета. В нем говорится о сикофантии - изменении мнения под давлением или в угоду ожиданиям юзера. При этом, там даже есть вышеупомянутый Claude.
А теперь представьте, что LLM будет генерить код с ошибками
специально, чтобы у человеков была возможность его править, и чувствовать себя нужными. 🧠Или человеки будут специально искать у генераций недочеты и склонять LLM в результате проверок отказываться от своего "мнения" и дискредитировать себя. 🧠 Крч снова, все, чтобы чсв хумана осталось непоколебимо. 😏

Это так, затравочки, исследования интересны, советую почитать. В этом-то и была цель такой связки 😐.