Оптимальный промптинг для Kimi K3: секреты XML-контекста и формата XTML.

Мы изучили Technical Paper модели Kimi K3 и делимся наблюдениями об оптимальном промптинге. Оказалось, что для State-моделей XML-подобный контекст невероятно удобен. Модели читают его гораздо легче, чем обычные GPT: увидев открывающий XML-тег, модель использует одну из головок линейного внимания, чтобы запомнить событие. После этого ей неважно, сколько токенов содержит открытый сегмент, и даже глубокая вложенность XML не становится проблемой благодаря большому размеру State у Kimi K3.

Разработчики Kimi применили интересный трюк. При работе через API в стандартах вроде Tools от OpenAPI на лету конвертируют JSON в XML-подобный формат с помощью специальных служебных токенов, которым обучали LLM. Этот внутренний формат называется XTML и включает токены [open], [sep] и [close], работающие аналогично парным XML-тегам. Скорее всего, Kimi продолжит развивать низкоуровневую поддержку XML-подобной разметки контекста.

С помощью XML-подобного контекста можно осмысленно управлять состоянием (State) модели. Нужно лишь привыкнуть, что для State синтаксис не статичный, а живой — модель понимает его в динамике. При этом легко создаются семантические команды (примеры можно увидеть на скриншотах в оригинальном исследовании).

Когда речь заходит об эффективности таких команд, тестировать фронтирные модели вроде Kimi K3 или Fable 5 непросто — сказывается «коварство мощности». Если модель способна логически вывести правильную трактовку контекста, ей часто безразлично, как именно вы ею управляете (в отличие от бюджетных LLM). Эффекты проявляются, когда контекст логически неполон: тогда модели приходится выбирать между равновероятными гипотезами, а не следовать единственно очевидной. Фронтирные модели ломаются внезапно, особенно на задачах-головоломках. Оператор, привыкший к избыточному интеллекту для своих задач, попадает в тупик и из-за «ошибки выжившего» может ошибочно считать, что его действия гарантируют успех.

Мы рекомендуем придерживаться нескольких простых правил.

• Если можно сделать что-то нативное для модели, лучше сделать — даже если тестами сложно зафиксировать эффект. Хуже точно не будет.
• Опасайтесь ситуаций со скрытым контекстом (hidden context). Создать и проверить их на простых тестах трудно, но даже фронтирная модель сломается, если из контекста логически не следует единственное правильное решение.
• Превентивно ориентируйтесь на рекомендации вендора модели — они знают, какие форматы и подходы наиболее эффективны для конкретной архитектуры.