Инсайт про архитектуру продукта c LLM Внутри наших практикумов в ИнженеркаТех живет PumpRoom. Это наше ядро с ИИ, где студенты решают задачи: там встроенная проверка ответов, наша IDE, умный помощник и система оценки. Сейчас архитектура платформы выросла настолько, что мы выходим за рамки обычного практикума в LMS и готовим к релизу полноценный задачник с ИИ-тьютором. Это будет отдельное пространство, где и задача, и среда для решений, и персональный наставник соединены в одну экосистему. Вчера в очередной раз штормили архитектуру и сформулировали главный вывод для всех, кто внедряет LLM в продукт: нанимайте ИИ на узкую задачу. Чем больше вы грузите её контекстом и лишними сущностями, тем сильнее она тупит. Вот пара кейсов из нашей «внутрянки»: 01 Не пихайте в ИИ то, что можно захардкодить. Один из простых примеров: у нас была установка, что условие задачи должен выдавать ИИ-персонаж в чате. Но в процессе мы поняли - это бред. Зачем тратить ресурсы LLM и заставлять студента ждать ответа в чате, если условие должно быть всегда перед глазами статичным текстом? Мы вырезали это и «захардкодили» постановку задач по классике в отдельный блок интерфейса обычным текстом без выпендрежа. Теперь ИИ не отвлекается на ерунду. 02 Контекст - это не всегда благо. Частый запрос от пользователей: «сохраняйте историю чата». Кажется, что ИИ будет адаптироваться под человека с течением времени😜 Мы используем последнюю, самую умную GPT, но даже она деградирует, когда тянет за собой длинный «хвост» переписки. Мы видим, что гораздо надежнее обнулять контекст и заново подгружать систему промптов, чем копить историю. Чистый лист и четкая инструкция работают лучше, чем попытки ИИ вспомнить, что вы обсуждали три экрана назад. Мой опыт говорит, что лучше отгружать на ИИшку только маленькую, узкую задачу без излишнего накопительства истории. Интересно, замечали ты вы что-то такое или не согласны с моими тезисами?