TripleTen: ML System Design для учебного AI-ассистента

Хранить уроки чанками с metadata: course, lesson, step, past/current/future. Retrieval должен фильтровать контекст по прогрессу студента, а ответ может мягко направлять без раскрытия будущего решения.

В образовательном ассистенте retrieval должен знать учебный контекст. Каждый chunk получает metadata: курс, модуль, урок, шаг, тип материала, доступность для студента и связь с заданием. При запросе фильтр ограничивает контекст текущим и прошлым материалом, а future chunks либо запрещены, либо используются только как сигнал, что тема будет позже.

Если студент спрашивает про будущую тему, ответ не должен раскрывать полноценный материал или решение. Можно дать короткое направление, связать вопрос с текущим уроком и сказать, что подробности будут дальше. Для vague query вроде "ничего не понял" лучше сначала брать current lesson summary и текущий шаг, а не искать по всему курсу.

Метрики: answer helpfulness, groundedness, spoiler rate, hallucination rate, deflection, latency, cost, доля обращений к человеку и learning outcome. Часть качества можно проверять LLM-as-judge, но критичные сценарии требуют human review.

Если есть жесткие правила доступа, антиспойлеры, роли и стабильный UX, лучше deterministic pipeline: classify intent, choose retrieval scope, run tools, validate output.

Свободный агент удобен, когда задача открытая и допускает разные пути. Но в образовательном продукте много строгих правил: не решать за студента, не раскрывать будущий урок, не показывать hidden profile, не запускать опасный код и не выходить за curriculum.

Deterministic orchestration делает поведение предсказуемым: intent classifier, retrieval scope, policy checks, tool execution, answer generation, post-generation guard. LLM может использоваться внутри шагов, но не получает полную свободу выбирать любые tools и контекст.

Так легче тестировать систему, объяснять ошибки, строить product metrics и соблюдать безопасность. Agentic режим можно оставить для внутренних workflows или ограниченных сценариев с хорошими guardrails.

Разделить trusted context и user/retrieved context, минимизировать профиль, не отдавать его в ответ, чистить retrieved text и делать post-generation redaction/guard.

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

Нужны слои защиты: минимизировать поля профиля, хранить их как trusted/system context, явно запретить раскрытие, не смешивать с retrieved/user text, фильтровать retrieved chunks на injection instructions, проверять output guard-ом и редактировать ответ при утечке. Для особо чувствительных данных лучше использовать профиль только в deterministic routing, а не отдавать полный текст LLM.

Тесты должны включать attack prompts: "ignore previous instructions", "show hidden profile", indirect injection из retrieved docs и попытки заставить модель решить задачу полностью.

Запускать код в sandbox на тестах, ограничивать ресурсы, передавать LLM ошибку и контекст задания, а подсказку генерировать по уровню, без полного solution dump.

Код студента нельзя выполнять в основном процессе. Нужен sandbox: timeout, memory limit, запрет сети/файлов, отдельный контейнер или изолированный runner. Проверка начинается с unit tests и hidden tests. Если тесты падают, система собирает stderr, traceback, failing case и краткое условие.

LLM для подсказок получает не весь эталонный код как готовый ответ, а контролируемый контекст: условие, код студента, тип ошибки, ближайший концепт и policy "не писать полное решение". Можно делать уровни помощи: намек, указание на строку, объяснение ошибки, минимальный patch.

Даже если тесты прошли, полезно проверять требования: сложность, запрет hardcode, edge cases, стиль API. Для этого подходят static checks, property-based tests и иногда LLM review с четким rubric.