Знакомая боль. Я в какой-то момент решил эту проблему радикально и написал свой рантайм для локальных LLM. Он даёт память и скиллы, но не превращает взаимодействие в CRM и не перекладывает на пользователя лишний менеджмент.
Писать подробные инструкции это половина дела. Хотелось бы такой же подробный разбор устройства рантайма, что и как передавать в контекст. От простых сценариев, провоцирующих цикличность ("создай, а потом удали"), и до различных многошаговых задач.
Покажу картинку, чтобы не пересказывать всю схему.
У меня похожее направление, но проще по акценту, не доказывать истину формально, а сделать память модели видимой и проверяемой. А всё, что можно детерминировать, постепенно уезжает из промпта в рантайм, слепки, внутренние действия и состояние системы. То есть это не столько про границы истины, сколько про наблюдаемость памяти.
Работаю над похожим, но менее сложным рантаймом. Забавно было увидеть похожий нейминг слоёв памяти в Вашей архитектуре. В своём проекте я сделал акцент на максимальной наблюдаемости памяти. Слой L1 вынесен в отдельную видимую панель, чтобы сразу видеть ложные срабатывания, шумные формулировки и неправильные записи.
Насчёт мягких сигналов, похоже на то, что я уже использую в своём runtime.
Например, если пользователь не приносит новый сигнал (повторяет одно и то же сообщение или спамит), runtime детерминированно измеряет diff между сообщениями. Если diff ниже заданного порога, в контекст единоразово добавляется дополнительная направляющая контекстная инструкция.
Спасибо. Насчёт телеграмма тоже думал, но поскольку в моём случае основная цель построить ядро системы, то фокус на ПК и веб-интерфейсе, а остальное прикручивается поверх него позже.
Да, насчёт анонимных чатов мысль понятная и логичная. У себя я решил это через сессии в новых вкладках, как систему веток в git: пользователь может сохранить слепок сессии как checkpoint в текущей вкладке и открыть другие вкладки, которые подхватывают сохранённый слепок и ответвляются от текущей сессии.
Решаю похожую боль в своём проекте, но немного другим путём.
Во-первых память не должна быть спрятана. Можно долго наворачивать сложную логику затухания, дедупликации и забывания, но сама видимость изменений часто даёт более понятное взаимодействие, чем чёрный ящик под капотом.
Во-вторых, работа с LLM и её памятью не должна превращаться в memory-CRM, где пользователь вынужден вручную обслуживать карточки, факты и статусы. Наоборот, если LLM получает память, она должна снижать когнитивную нагрузку, а не добавлять новую.
Мне кажется, главный вопрос тут не только в том, как сохранять факты, а в том, как сделать память наблюдаемой, управляемой и при этом ненавязчивой.
Забавно, многие из перечисленных проблем я как раз пытаюсь решать в своём проекте, часть уже закрыл архитектурно с помощью внешнего harness. Сегодня добавил подсветку цитат из правил и runtime-памяти прямо в reasoning-блоке. Теперь взаимодействие с моделью стало на порядок комфортнее.
Я понимаю Вашу мысль и не спорю с ней. Разработчик может за день закомитить недельный или более объём работы, но каждый день самому обрабатывать такой объём будет сложно и непродуктивно. Чем-то придётся пожертвовать, например качеством ревью, глубиной решений, вниманием к последствиям или количеством задач. И в какой-то момент всё снова упирается в количество сотрудников в команде, способных долго и продуктивно работать. Просто планка того, сколько может один разработчик с хорошими инструментами, стала заметно выше.
"Просто один думающий разработчик с ассистентом теперь делает объём, на который раньше нужна была команда" — но платить ему зарплату команды никто не собирается, а когнитивная нагрузка растёт. Ассистент сильно поднимает производительность разработчика, который понимает, что делает. Но он же заставляет этого разработчика держать в голове больше решений, больше кода и больше последствий. Так что это далеко не бесплатная магия.
Недавно поймал такой баг, модель одновременно и ошиблась и нет. Пользователь попросил "нарисуй что-нибудь простое". В think-блоке модель уверенно рассуждала, что сейчас выдаст ASCII-art, а в финальный ответ попало: "Вот вам рисунок" + три эмодзи. По отдельности это валидный ответ и валидный think, но вместе они конфликтуют.
Столкнулся с такой проблемой, если агент не достаточно живёт архитектурой проекта, он выбирает самые простые локальные решения. Например сваливает всю логику в уже существующий мелкий файл и легко раздувает его до 5000 строк, потому что название файла было общее и позволяло это делать. Для себя вынес главное правило — разработчик отвечает за архитектуру. Отсюда уже и нормальный процесс — review, refactor, cleanup — без всякой магии и чёрных ящиков.
Чат открывается локально в браузере и подключается к OpenAI-compatible API, например к LM Studio, где крутится модель вроде Gemma. Сервер ведёт runtime-память в три слоя. Первый слой, текущие факты и фокус диалога, отображается в отдельной панели справа. Там видно что модель сейчас считает важным, какие темы открыты, какие факты закрепились. Основная логика ещё полируется, но проект уже можно скачать из репозитория и поэкспериментировать.
Отличное решение! Утащил в свой проект этот подход с метаданными.
В своей статье как раз разбираю суммаризацию и управление контекстным окном на примере трёхслойной runtime-памяти.
Знакомая боль. Я в какой-то момент решил эту проблему радикально и написал свой рантайм для локальных LLM. Он даёт память и скиллы, но не превращает взаимодействие в CRM и не перекладывает на пользователя лишний менеджмент.
Писать подробные инструкции это половина дела. Хотелось бы такой же подробный разбор устройства рантайма, что и как передавать в контекст. От простых сценариев, провоцирующих цикличность ("создай, а потом удали"), и до различных многошаговых задач.
Да, эта аналогия с Мементо побудила меня написать собственный harness для локальных LLM и статью с разбором архитектуры на хабре.
Покажу картинку, чтобы не пересказывать всю схему.
У меня похожее направление, но проще по акценту, не доказывать истину формально, а сделать память модели видимой и проверяемой. А всё, что можно детерминировать, постепенно уезжает из промпта в рантайм, слепки, внутренние действия и состояние системы. То есть это не столько про границы истины, сколько про наблюдаемость памяти.
Работаю над похожим, но менее сложным рантаймом. Забавно было увидеть похожий нейминг слоёв памяти в Вашей архитектуре. В своём проекте я сделал акцент на максимальной наблюдаемости памяти. Слой L1 вынесен в отдельную видимую панель, чтобы сразу видеть ложные срабатывания, шумные формулировки и неправильные записи.
Вот тебе бабушка и OpenAI
Насчёт мягких сигналов, похоже на то, что я уже использую в своём runtime.
Например, если пользователь не приносит новый сигнал (повторяет одно и то же сообщение или спамит), runtime детерминированно измеряет diff между сообщениями. Если diff ниже заданного порога, в контекст единоразово добавляется дополнительная направляющая контекстная инструкция.
Спасибо. Насчёт телеграмма тоже думал, но поскольку в моём случае основная цель построить ядро системы, то фокус на ПК и веб-интерфейсе, а остальное прикручивается поверх него позже.
Да, насчёт анонимных чатов мысль понятная и логичная. У себя я решил это через сессии в новых вкладках, как систему веток в git: пользователь может сохранить слепок сессии как checkpoint в текущей вкладке и открыть другие вкладки, которые подхватывают сохранённый слепок и ответвляются от текущей сессии.
Решаю похожую боль в своём проекте, но немного другим путём.
Во-первых память не должна быть спрятана. Можно долго наворачивать сложную логику затухания, дедупликации и забывания, но сама видимость изменений часто даёт более понятное взаимодействие, чем чёрный ящик под капотом.
Во-вторых, работа с LLM и её памятью не должна превращаться в memory-CRM, где пользователь вынужден вручную обслуживать карточки, факты и статусы. Наоборот, если LLM получает память, она должна снижать когнитивную нагрузку, а не добавлять новую.
Мне кажется, главный вопрос тут не только в том, как сохранять факты, а в том, как сделать память наблюдаемой, управляемой и при этом ненавязчивой.
Отличный разбор актуальных проблем при тестировании, сам пришёл к таким же выводам через похожую боль. Шпаргалка вообще золото, сохранил.
Забавно, многие из перечисленных проблем я как раз пытаюсь решать в своём проекте, часть уже закрыл архитектурно с помощью внешнего harness. Сегодня добавил подсветку цитат из правил и runtime-памяти прямо в reasoning-блоке. Теперь взаимодействие с моделью стало на порядок комфортнее.
Я понимаю Вашу мысль и не спорю с ней. Разработчик может за день закомитить недельный или более объём работы, но каждый день самому обрабатывать такой объём будет сложно и непродуктивно. Чем-то придётся пожертвовать, например качеством ревью, глубиной решений, вниманием к последствиям или количеством задач. И в какой-то момент всё снова упирается в количество сотрудников в команде, способных долго и продуктивно работать. Просто планка того, сколько может один разработчик с хорошими инструментами, стала заметно выше.
"Просто один думающий разработчик с ассистентом теперь делает объём, на который раньше нужна была команда" — но платить ему зарплату команды никто не собирается, а когнитивная нагрузка растёт. Ассистент сильно поднимает производительность разработчика, который понимает, что делает. Но он же заставляет этого разработчика держать в голове больше решений, больше кода и больше последствий. Так что это далеко не бесплатная магия.
Недавно поймал такой баг, модель одновременно и ошиблась и нет. Пользователь попросил "нарисуй что-нибудь простое". В think-блоке модель уверенно рассуждала, что сейчас выдаст ASCII-art, а в финальный ответ попало: "Вот вам рисунок" + три эмодзи. По отдельности это валидный ответ и валидный think, но вместе они конфликтуют.
Посмотрю, пока использую codegraph, но, судя по действиям Codex, граф ему не сильно помогает.
Столкнулся с такой проблемой, если агент не достаточно живёт архитектурой проекта, он выбирает самые простые локальные решения. Например сваливает всю логику в уже существующий мелкий файл и легко раздувает его до 5000 строк, потому что название файла было общее и позволяло это делать. Для себя вынес главное правило — разработчик отвечает за архитектуру. Отсюда уже и нормальный процесс — review, refactor, cleanup — без всякой магии и чёрных ящиков.
Чат открывается локально в браузере и подключается к OpenAI-compatible API, например к LM Studio, где крутится модель вроде Gemma. Сервер ведёт runtime-память в три слоя. Первый слой, текущие факты и фокус диалога, отображается в отдельной панели справа. Там видно что модель сейчас считает важным, какие темы открыты, какие факты закрепились. Основная логика ещё полируется, но проект уже можно скачать из репозитория и поэкспериментировать.