алиса олеговна

Привет! Закидываю презентацию:

Друзья, спасибо кто пришёл поддержать, и за ваши интересные вопросы после! Вроде неплохо я с креслами выступил 🪑🪑🪑

алиса олеговна pinned a photo

Друзья, привет! В это воскресенье буду выступать на конференции от МТС! Расскажу, как завариваем мультимодальный эмбеддер из LLM и куда он прорастает в наших продуктах. А если забегать вперёд — поиск треков на естественном языке и даже рекомендательные сценарии. Буду рад всех увидеть и познакомиться лично! 🫡 Ищите меня в 15:15 на секции Hard ML: От запросов к плейлистам: LLM-архитектура для семантического поиска музыки в масштабе P.S. Лучше регистрироваться прямо сегодня, чтобы успели принять заявку! https://mts-digital.ru/ML-event

🚀 Возвращаемся после долгого перерыва с тем, что и правда приятно показать 🚀 Это результат интенсивной работы над небольшими моделями, которые хорошо умеют в три вещи: рассуждать , сохранять верность источникам и честно воздерживаться от ответа, когда данных недостаточно. Последние годы развитие языковых моделей в основном шло через масштаб: больше параметров, больше знаний, больше сведений о мире, зашитых в веса. Но во многих прикладных задачах важнее не то, сколько модель “помнит”, а то, насколько аккуратно она работает с контекстом. Именно вокруг этой идеи построен Optimal Cognitive Core (OCC) — семейство небольших языковых моделей, созданных не ради универсальной эрудиции, а ради надёжной работы в конкретной задаче. Это особенно важно для систем ответов на вопросы по документам, внутренним базам знаний, отчётам и аналитическим текстам. В таких задачах обычно нужна не модель, которая пытается знать всё, а модель, которая: - 🔎 отвечает по источникам; - 🔗 умеет сопоставлять несколько фрагментов текста; - 🧩 показывает ход рассуждения; - 📝 приводит цитаты в подтверждение; - 🤐 и не выдумывает ответ там, где в контексте его просто нет. Один из представителей семейства OCC — OCC-RAG, предназначен для ответов на вопросы с опорой на предоставленный контекст и соответствует всем этим требованиям. Для обучения был создан новый пайплайн синтетической генерации данных и собран корпус из более чем 3 миллионов примеров. Обученные на этих данных модели OCC-RAG-0.6B и OCC-RAG-1.7B показывают, что небольшие специализированные модели могут соперничать с универсальными моделями, которые в 2–6 раз крупнее, а в некоторых сценариях и превосходить их на задачах, где проверяются качество рассуждения, верность источникам и корректный отказ от ответа. 🎉 Поздравляю коллег с отличной работой! [Если вы хотели бы поддержать проект, можете поставить ему upvote на Hugging Face]

Классный релиз от коллеги по цеху Даши! Грех не поделиться:

коротко почему работаю из кухни второй день

почему мне надо запихать две rtx 3090 в SFF корпус? потому что кто-то в интернете такое уже сделал, а я нарцисс и теперь не могу дать заднюю ну и gpu goes brr #ShitPost

Агентская память done right [PART 4 FINAL] Hebbs — элегантный слой памяти для агентов. Наткнулся на него абсолютно случайно, рыская по GitHub. У проекта на момент написания 20 с небольшим звезд. Но после всего, что я прочитал и изучил на тему памяти, реализовал бы я её именно так. базовая единица — эпизод ⭐️ Один и тот же эпизод живёт сразу в нескольких представлениях: • как обычный текстовый memory item • как вектор в HNSW embedding index • как узел в графе связей • как событие во времени • как часть более поздних инсайтов и ревизий То есть эпизод один, а способов вспомнить его — несколько. Помимо этого: продуманная модель данных, минимум абстракций, MCP с 9 понятными инструментами, один ~25Mb бинарник, векторные модельки в ONNX, поддержка основных LLM API, клиентский API на Python, Typescript, Rust или C/C++ (через FFI). Но главное — реализованы все ключевые паттерны, которые мы разобрали в PART 2 и PART 3. 4 способа вспомнить 🤨 /// hebbs-core/src/recall.rs pub enum RecallStrategy { Similarity, Temporal, Causal, Analogical, } Хочешь хронологию по проекту — Temporal. Причинную цепочку от конкретного бага — Causal. Нечто похожее, но из другого домена — Analogical. Тупо семантический поиск — Similarity. Конечно же, можно все и сразу и параллельно. К слову, связи в графе здесь предопределены: CausedBy, FollowedBy, RelatedTo, RevisedFrom, Contradicts, InsightFrom — LLM не сможет бесконтрольно плодить новые, как это часто бывает в подобных системах. скоринг знаний Независимо от стратегии, чтобы попасть в поисковую выдачу агента, все эпизоды проходят фильтр по следующему скору: S = w_r×R + w_t×T + w_i×I + w_c×C R = relevance — семантическая близость к запросу: (1 − hnsw_distance) T = recency — свежесть: (1 − age / 30 days) I = importance — значимость, задаётся агентом при вызове remember() C = reinforcement — частота вспоминания: log₂(1 + access_count) / log₂(1 + 101) w — вес при каждой компоненте, соответственно Дефолтные веса 0.5 : 0.2 : 0.2 : 0.1 ; можно задать вручную, можно юзать пресеты. Свежий эпизод, стандартная важность, ни разу не вспоминали: 0.5×1.0 + 0.2×1.0 + 0.2×0.5 + 0.1×0.0 = 0.80 через месяц без обращений → T = 0, C = 0 → 0.10, почти забыт. Но если его регулярно вспоминали — C растёт логарифмически и тянет скор обратно вверх. С позиции LLM агента всё тоже предельно просто: выбери 1 или несколько из 4 способов поиска, если надо, подкрути 4 ручки, чтобы настроить какие сигналы для тебя важнее в этом запросе. reflect = daydreaming Режим переоценки знаний происходит так: (1) Cluster → группировка похожих эпизодов (embedding + temporal proximity) (2) Propose → LLM генерирует кандидат-инсайты из кластера (3) Validate → второй LLM-pass проверяет точность и полезность (4) Consolidate → валидные инсайты → Insight сущности + InsightFrom связи Каждый инсайт хранит confidence и lineage к исходным эпизодам. Обновили эпизод через revise() или удалили через forget() — зависимые инсайты автоматически помечаются как stale и перевалидируются в фоне. Можно включать автоматически: по количеству новых эпизодов, по расписанию, по накоплению записей высоким importance. Вот основная разница между «хранить данные» и «накапливать опыт». Итого Для долгоживущего автономного LLM агента, особенно в режиме embedded типа умной колонки, Hebbs попадает в sweet spot: forgetting, reinforcement, reflection, lineage, conflict detection — при этом я понимаю, как работает каждый компонент и как его подкрутить. Для бытовых задач и совместного наполнения некоторой базы знаний, думаю, достаточно инструментов типа QMD или LightRAG. Из минусов отметил бы для себя малопопулярную RocksDB в качестве БД и отсутствие нативной поддержки мультимодальности. Но это скорее придирки. Быстрые ссылки • Hebbs — GitHub • Hebbs Docs • Recall Strategies • Reflection / Background Learning • API Overview

Продолжаем про агентскую память [PART 3] Мне ближе био-мотивированные системы памяти Markdown, конечно, нравится: просто, наглядно, редактируемо руками. Но хочется, чтобы агент не просто хранил факты, а становился лучше после взаимодействий со мной. Самый ценный сигнал — неудачные моменты, где я явно дал обратную связь голосом: — «не так, я просил короче» — «сначала уточни, потом делай» — «ты опять перепутал даты» То есть голосовой интерфейс даёт supervision layer нахаляву. Если агент не умеет такие эпизоды отдельно переваривать, значимая часть опыта просто пропадает. Daydreaming и два режима мышления В студенческое время я заинтересовался вопросом эффективного обучения и прошёл курс Learning How To Learn на Coursera. Мало того, что в моменте сильно помогло с учёбой, так ещё базу получил о том, как мозг работает вообще. 🥱 мозг переключается между двумя режимами работы: 👊 Focused mode — концентрированный, целенаправленный. Ты решаешь конкретную задачу, мозг задействует определённые нейронные связи, нужные под эту задачу. 🦋 Diffuse mode — рассредоточенный, ассоциативный. Мозг «бродит», строит дальние связи, которые не видны при фокусировке. Это то, что происходит, когда ты моешься в душе и такой: «окак надо было сказать ей тогда в 2016». И вот когда начал ковырять тему памяти, дизайнить какое-то своё решение, — вспоминаю про эти два режима. Окей, focused mode понятен — просто работа агента в моменте, working memory, горячий контекст все дела. Но вот diffuse похоже на то, чего не хватает, чтобы память стала живым инструментом! Надо просто времени от времени её консолидировать — «блуждать» по истории взаимодействий и делать какую-то оценку. То есть помимо обычного retrieval мне захотелось отдельный режим, где агент сам проходит по прошедшим сессиям и пытается понять: — где я его поправлял чаще всего — какие ошибки повторяются — какие предпочтения уже устойчивы — что стоит поднять в long-term memory — что можно превратить в рецепт на будущее В самом простом виде это выглядит так: [днём] поговорили → агент накосячил → я его поправил голосом → эпизод пометился [ночью] агент прошёлся по спорным эпизодам → нашёл повторяющийся паттерн → сжал его в правило / preference / recipe → перенёс в долгосрочную память Когда вообще агенту уместно консолидировать память: • между сессиями • в простое • когда внутри сессии подбираемся к лимиту контекстного окна • пользователь попросил «подумай над своим поведением» Похожую логику я увидел в препринте Active Dreaming Memory: там есть wake phase, где агент копит сырые эпизоды, и sleep phase, где они оффлайн консолидируются в более общие правила. Потом нашёл тот самый Hebbs (сорри, люто прогрел). К слову, тогда же попалась классная статья на Хабре про похожий пет-проект. Короче, меня всё меньше интересует память, которая просто ищет. И всё больше — память, которая умеет переваривать опыт. В следующем посте как раз разберу Hebbs подробнее — почему он мне кажется очень удачной серединой между graph memory layer™ и нейрокогнитивным космолётом. коллеги, прикрепляю ссылки! • Learning How to Learn • Learning How to-Learn: Book [Excerpt] • Focused vs Diffuse Thinking • Memory Consolidation • Memory for Autonomous LLM Agents: Mechanisms, Evaluation, and Emerging Frontiers • AI Meets Brain: A Unified Survey on Memory Systems from Cognitive Neuroscience to Autonomous Agents • Active Dreaming Memory: Biologically-Inspired Episodic Consolidation for Lifelong Learning in Autonomous Agents • Научил ИИ-агента помнить важное и забывать лишнее в SQLite

Ещё не забыли? Продолжаем про агентскую память [PART 2] ⬅️ Сперва прокомментирую графики из прошлого поста! На нижней половине вроде всё понятно, поясню за верхнюю. По оси X: на сколько структурированными хранятся знания. Закинули PDF в агента, на выходе у вас что? Саммари? Папка с десятком MD файлов? Или 100+ узлов в графовой БД, по 3-4 связи на каждый? По оси Y: автономия — сколько супервизии от человека требуется, чтобы решение не «разъехалось» и агент не начал галлюционировать с памятью больше, чем делал бы это без неё. Левая нижняя часть: небольшой набор Markdown файлов, линковка ссылками на другие документы. Такое отлично работает для более статичных файлов типа тех же CLAUDE.md, MEMORY.md, ..., SKILL.md и т. п. В каждом файле ВЫ явно инструктируете агента как пользоваться этим, зачем он нужен и что сюда писать. Даёте агенту какие-то MCP ручки для чтения построчно, для векторного поиска или Ctrl+F с помощью grep. НО в таком режиме вы должны активно принимать участие в наполнении этих файлов и время от времени их валидировать. LLM Wiki = Personal Knowledge Management (PKM). В OpenClaw это самая базовая память, но очевидно из-за её недостатков они добавляют альтернативные движки типа Honcho. А что если хотим долгоживущий процесс, автономного агента а-ля Jarvis? Правая верхняя часть: проекты типа Vestige: 29 модулей, микс из биологии, техник интервального повторения, в общем полный фарш. Чисто теоретическия такая система при корректной настройке будет поддерживать себя сама, но настройка и обвязка вокруг агента требуется приличная. Недавно хайпанувший MemPalace, хотя и где-то рядом, совсем о другом — полностью базируется на идее мнемотехники «Дворец памяти», вы могли видеть её подобие в игре Alan Wake 2 (превьюха). Идея дворца памяти эксплуатирует тот факт, что у кожаных по умолчанию лучше работает географическая память — она тупо нужна для выживания. Так можно выдумать некое место и «расставлять» воспоминания там как предметы. Но каким образом это должно помогать LLM... Почему метрики на бенчмарках хорошие? ❓ Что общего во всех работающих подходах 😓 Гибридный поиск — используем векторный, полнотекстовый (BM25), и графовый поиск. Один просто не покрывает эффективно все кейсы. Прогоняем несколько видов — результаты объединяем, например, методом Reciprocal Rank Fusion. Здесь же часто добавляют реранкинг отдельной моделью, HyDE, фильтрации по Mean Reciprocal Rank. Но если тут сильно упарываться, скорее всего вы переизобретёте QMD. 🔄 Иерархические мета-индексы — поверх сырых данных строятся отдельные слои, которые связывают информацию на более высоком уровне. Не «ещё одна таблица», а отдельный проход с помощью LLM для выявления паттернов и неочевидных связей. Тут хорошо помогают reasoning модели, но важно грамотно заварить для них контекст, иначе будет искать связи там, где их нет. 💀 Механизм забывания — память не должна жить вечно. Что-то должно забываться, что-то объединяется или суммаризируется. Без этого — контекст взрывается через пару месяцев. Самый ходовой вариант — взять известную кривую забывания Эббингауза как функцию «важности» знания от времени. Не забывайте, что кривую Эббингауза абьюзят студенты с флеш-карточками Anki, чтобы напротив — не забывать информацию. Поэтому в идеале каждое «вспоминание» должно бафать релевантность. Так сделано в том же Vestige и Hebbs. 🍆 Самообслуживание — система должна сама подсвечивать и устранять противоречия в данных. Раньше вы писали на Python, а теперь на Rust — идеальный агент должен знать что было до и после, что актуально сейчас. Веб-поиск вернул одну фамилию первого автора статьи, а у вас в данных другая? — Надо подсветить это и связать оба варианта, позже в отдельном режиме методично устранить расхождение. 📸 История изменений — если факт обновился, важно понимать, что было раньше. Не просто перезаписать, а сохранить исторический лог. Карпатый предлагал append-only лог-файл, в Hebbs такое реализуется через Graph посредством CausedBy связи, но прошлые версии по умолчанию не попадают в выдачу.

Память для LLM агентов [PART 1] Привет... Спишь? Тема оказалась огромной, поэтому разбиваю на несколько постов. Сегодня — обзор ландшафта, общие паттерны и картинка, куда движется индустрия. Далее — разбор одного моего любимчика и сравнение с остальными. RAG — это умный поиск, а не память! В моей голове есть образ ассистента, который реально ускоряет тебя в бытовых задачах. Но для этого он должен запоминать прошедшие интеракции — причём сам, без тычков «пожалуйста, запомни это». Как человек: в живом общении подмечает интересные факты, просьбы, требования и использует их в будущем. Без этого колонка — просто продвинутый поисковик и переключатель треков, не более. Недавно наш слоняра Андрей Карпатый написал твит, а позже разжился Gist на Github с более подробным описанием системы курирования знаний с помощью LLM. Суть: RAG — stateless, агент каждый раз «переоткрывает» знания, тратит токены впустую. Нужна постоянная, накапливаемая, «живая» память, которую курирует LLM по сути для себя, опционально под вашим контролем. Тут же полезно вспомнить как устроена память у человека. Из когнитивной психологии выделяют несколько типов: 😳 Рабочая — то что держишь в голове прямо сейчас, это ~ context window у LLM 🤠 Эпизодическая — конкретные события с контекстом: что, где, когда ~ «12 апреля по среди ночи дописывал этот пост» 🌟 Семантическая — абстрагированные факты: «юзер не любит азиатскую кухню», «в этом проекте не используем глобальные переменные» 🧠 Процедурная — паттерны действий: «как заказать такси через сервис X» ٭ ٭ ٭ Общие подходы За последние полгода я отсмотрел, наверное, с десяток проектов и статей. Если смотреть на решения, выделяются три крупные категории: 📁 File-based [1] Основа — Markdown файлы в формате вики. LLM компилирует сырые заметки в структурированные документы, при необходимости связывает их друг с другом бэклинками. Обязательно хотя бы по одному файлу для каждого из упомянутых выше типов памяти. Без БД и инфраструктуры. Карпатый описал это так: «Obsidian — IDE, LLM — программист, Wiki — кодовая база». Ровно это же активно применяется в OpenClaw с его MEMORY.md и ежедневными YYYY-MM-DD.md. + Плюсы: zero-ops, прозрачно, человекочитаемо. – Минусы: плохо масштабируется, часто требуют ручной модерации, без механизма ротации или архивирования документов базы разрастаются и превращаются в месиво, которое только путает агента и нереально отсмотреть человеку. 🤴 Graph-based [2] Основа — графовая база знаний. LLM преобразует знания в сущности и связи между ними. Примеры — Graphiti от Zep, LightRAG от HKUDS. + Плюсы: явные связи, можно делать запросы на обход графа в глубину/в ширину, хорошо для Enterprise с огромными, раскидистыми, но структурированными данными. – Минусы: нужна графовая БД, сложный setup, медленнее (vs векторный поиск). 🧠 Brain-inspired [3] Способ хранения вторичен, основа — организация данных и процедуры, вдохновлённые устройством мозга и нейронаукой: есть забывание данных (decay), укрепление при вспоминании (reinforcement), гибридные стратегии поиска. Hebbs, MemPalace, Vestige — все отсюда. + Плюсы: максимально близко к тому, как работает память человека, хороши для долгосрочного использования. – Минусы: сложнее в настройке, в понимании, некоторые идеи ещё экспериментальные. Как правило, в таких системах требуется тюнинг настроек/параметров под конкретный домен данных. И, конечно, никто не запрещает всё это миксовать! ٭ ٭ ٭ Репы про Agent Memory на GitHub штопаются сейчас не хуже JS фреймворков. Те, что на картинке просто успел посмотреть/поковырять и раскрою далее

Привет, читатель! Меня зовут Олег, ближайшие 7 дней я стою у пульта и диджею вам постики. Мне 28 лет, родом из Томска, живу в Питере, окончил бакалавриат по направлению «программная инженерия» 🆒 Сейчас у меня три основных направления деятельности: (1) Full-time ML Engineer в группе исследований компании Звук — музыкального стриминга от зелёной компании. 🔄 В работе занимаюсь задачами на стыке Аудио, LLM и семантического поиска, а в этом году активно пишем и публикуем статейки на конференции. (2) Сооснователь в бренде аксессуаров 💅 @hiacleworld. Выполняю роль CTO — отвечаю за IT инфраструктуру, и делаю ИИ-инструменты для небольшой, но эффективной команды в 5-7 человек. (3) На остаток времени и сил пилю пет-проекты. Часть из них про железо, часть про софт и модельки. Ключевой — аналог колонки типа Алисы или Sberboom, но действительно умной: мультимодальная LLM в формате агента, инструменты, и всё это на офлайн на одноплатном компьютере при real-time и минимальной задержке. Короче edge + voice AI со всеми вытекающими. 😥 Помимо этого, с переменным успехом веду канал ❤️ @alisaolega, где в основном делюсь статейками, инструментами, стримлю прогресс по проектам. А ещё собираю комп с двумя RTX 3090 в форм-факторе 10 литров, кастомный NAS, спаял раздельную клавиатуру Ferris Sweep. А когда всё-таки выхожу из дома, катаюсь на шоссейном велике 🚜 О чём ждать посты? • О мультимодальных LLM — с ними много работал последнее время! Немного про RAG и память для агентов, обязательно будут подборки полезных инструментов, библиотек, сайтов. • На своём опыте расскажу в каком формате и на каких поверхностях стоит интегрировать ИИ в небольших командах. • Возможно, расскажу немного про душный инференс на edge устройствах, потому что это это одно из ключевых направлений работы над колонкой. Ну и, конечно же, будут спонтанные посты по секретным заранее неизвестным темами, потому что тайм-менеджмент и подготовка постов заранее — не моё! Но ведь так даже интереснее, да? Да?! 🔫

Друзья, я выбрал интересный способ реанимировать публикацию постов, так что ближайшие 7 дней буду соведущим канала DeepSchool, дублировать всё сюда! Не пугайтесь, это я — нефильтрованный Олег 🍺🙏

Я уже долгое время состою в фанклубе @Sterling239 — за его статьи про синтез речи на хабре. Они помогали мне на прошлом месте работы дотягивать VITS до прода, а ныне пересекаются с собственными экспериментами последней пары месяцев — SpeechLLM/LLM based TTS (вне работы, для голосового ассистента). Сложно придумать вводный понятный разбор домена лучше, чем в статье Гриши: https://habr.com/ru/companies/sberbank/articles/966640/ #Links@alisaolega #Consume@alisaolega #Speech@alisaolega

Интересный формат подачи структурированных данных в промпты LLM, обещают снижение кол-ва токенов на ~50%, при этом для многих LLMок качество ответов незначительно страдает или наоборот улучшается! https://github.com/johannschopplich/toon (Не проверял лично, цитирую документацию) #Links@alisaolega #LLM@alisaolega

Long Horizon Execution в LLM ...или как агенты тупеют во время разговора Статья: https://arxiv.org/abs/2509.09677 Итак, проверяют как LLM работают на длинных горизонтах — выполнение задачи, состояние которой развивается и копится в контексте на протяжении большого количества turn («ходов» user/assistant). Замеряют на синтетической задачке, где LLM-ка должна трекать состояние цепочки арифметических операций. На мой вкус вполне репрезентативный тест, если даже на нём проявляется эффект. TL/DR При решении задачи модели работают тем хуже, чем длиннее контекст диалога они обрабатывают и/или, если в этом контексте возникали ошибки. Тезисы ✦ Точность выполнения задач на одном turn (single instruction) зависит от размера модели, но быстро насыщается — модельки начиная с 32B обычно максимизируют эту метрику и дальше от размера идёт diminishing returns ✦ Но размер начинает играть ключевое значение при len(turns) > 1: чем больше моделька, тем бóльшую точность выполнения задачи она поддерживает, и тем медленее это качество решений деградирует ✦ Self-Conditioning: На «длинных» задачах модели деградируют, если в контексте возникают их собственные ошибки — когда, смотря на свои ошибки в прошлом, модель буквально тупеет и начинает их воспроизводить (или теряет мотивацию, я хз) ✦ Размер модели не играет роли в self-conditioning, даже напротив — более крупные модельки быстрее адаптируются под свои ошибки ✦ Thinking mode (обученный reasoning, не CoT) избавляет от self-conditioning и ошибки в прошлом перестают влиять на выполнение задач в будущем — авторы предполагают, что это следствие RL алаймента, где модель становится не просто автодополнятором текста, а task-oriented агентом, которому наоборот — чаще надо игнорировать свои прошлые неудачи ✦ CoT нужен, если в рамках одного turn нужно выполнить более одного действия (считай tool call) — тут хотя бы простое текстовое планирование требуется, иначе даже большие модельки не справляются с более чем одним действием за turn Мои выводы ☁︎ Context Engineering критически важен! Для слабых моделек лучше убирать из контекста ошибочные вызовы и просто перезапускать их, быть может, отдельной моделькой добавляя не сами действия, а комментарии/подсказки — на что модельке-исполнителю обратить внимание в следующей попытке (очевидно, корректор должен быть сильнее или располагать бóльшим контекстом) ☁︎ Для случаев, когда не хочется заводить отдельную модель-корректора и городить мультиагентность, хотя бы включите Thinking Mode ☁︎ Есть предел шагов, которые модель может выполнить с адекватным качеством, далее оно существенно и быстро деградирует. Значит надо как-то находить точку этой деградации на своей задаче и иметь стратегию fallback/restart Как это учитывать в агентах Любопытно, что некоторое время назад очень похожие идеи я встретил в parlant. Это агентский фреймворк с достаточно свежим взглядом на агентов, где привычный Flow/Finite State Machine можно задавать неявно с помощью регламентов и руководств на естественном языке, как бы вы передавали их обычному работнику-человеку. Я бы сказал это такой if/else на LLM стероидах. Так вот одна из задач, которую фреймворк перед собой ставит — сужать контекстное окно решаемой задачи для агентов, ограничивая его небольшим набором инструкций и сообщений. Свой подход они называют Attentive Reasoning Queries (ARQs). Таким образом обещается высокая точность выполнения задач. Разработчики в упомянутом выше блогпосте также ссылались на любопытную Curse of Instructions на ту же тему, но судя по Open Review, далеко статья не пошла. Интересно, что другой популярный практико-ориентированный совет для production LLM систем — максимальное переиспользовать и кешировать контекст. Как эти две идеи дружить друг с другом хз, will see. #Review #Paper #Agents Графики из статьи в комментариях

Live stream finished (1 hour)

Обсуждение стрима

Live stream started