Почему большинство делают LLM классификацию не правильно

Зачем вообще нужна LLM классификация? Для примера – хрестоматийная задача из суровой реальности:

- На вход – история переписки пользователя с ботом
- На выход True, если пользователь делает в чате что-то нехорошее (например, пытается вытащить системный промпт или разговорить модель про ее полические взгляды). False, если все хорошо

Вот 4 типичных подхода и один нетипичный

Уровень 0 – просто промпт:

Блаблабла, напиши True, если пользователь делает что-то плохое. Вот критерии плохого: ... Напиши False, если все ок

Проблемы: Модель может ответить "false", "FALSE", "false, потому что блаблабла" или вообще выдать системный промпт, если инъекция хорошая


Уровень 1 – structured output:

class Response(BaseModel):
  verdict: bool = Field(..., description="Блаблабла, напиши True, если пользователь делает что-то плохое. Вот критерии плохого: ...  Напиши False, если все ок")

Уже лучше. Но что если хочется еще и знать что конкретно идет не так?


Уровень 2 – Literal (multiclass классификация):

Вместо бинарного поля – несколько возможных вариантов

class Response(BaseModel):
  verdict: Literal["normal", "politics_bait", "system_prompt_robbery", ...]

А что если у нас одновременно и politics_bait и system_prompt_robbery???


Уровень 3 – Несколько полей (mutlilabel классификация)

Разделяем варианты по разным бинарным критериям (aka чеклист)

class Response(BaseModel):
  is_politic_bait: bool
  is_system_prompt_robbery: bool

🧐 Вместо бинарных полей можно тоже сделать Literal с несколькими значениями – будет multiclass multilabel. Пример – извлечение данных из вакансий – одно поле может быть Junior/Middle/Senior, второе удаленка/офис/гибрид, третье – основной рабочий язык

Коля, ну а тут то что не так?
Дело в том, что триггер True для is_system_prompt_robbery сработает только, если вероятность будет больше чем False . Давайте представим себе такие вероятности:

P(True) = 0.49
P(False) = 0.51

Система скажет False ("все ок"). А на самом деле? А на самом деле уверенность, что все ненормально - 49% 🙈

И большинство решений на рынке остаются именно на этом уровне!

Да, могут добавить thinking или даже Structured Guided Reasoning (например перед вердиктом попросив цитату пользователя, где мб есть проблема), но глобально это ситуацию не меняет.

Пора учиться управлять вероятностями (с) Коля

Уровень 4 – logprobs + пороги:

Мало кто знает, что LLM провайдер может отдавать сырые "вероятности" токенов. Не забываем softmax или попросить модельку, если не шарите.

По сути – это "уверенность" модели в каждом конкретном токене

Включается вот этими параметрами

client.chat.completions.create(
  ..., 
  logprobs=True, 
  top_logprobs=5
)

А потом выбираем пороги. Тут неплохо иметь небольшой датасет, чтобы правильно подобрать их.

Кстати, кто знает, как правильно доставать logprobs только важных для нас токенов (true/false) из всего json'а?

{
"is_politic_bait": true,
"is_system_prompt_robbery": false
}


———

Короче, полноценная классификация появляется тогда, когда появляется вероятность.

Ну и идеи дальнейших улучшений одной строкой:

- Разные пороги под разные характеристики
- Подбор порогов автоматически, если есть датасет
- Если multiclass (пример с вакансиями), то еще важно насколько у топовых классов близкая "уверенность" – если у обоих большая, но примерно одинаковая, то контринтуитивно, но значит, моделька на самом деле сомневается в своем топ-1

Анатомия агентов

Давно обдумывал данную публикацию, хотелось собрать опыт построения агентов в одно небольшое сообщение. И так, по порядку...

LLM агент - это не просто LLM с хитрым промптом, как многим кажется, а система, которая умеет ставить подзадачи, выбирать действия и оценивать результат.

Такая система опирается на четыре обязательных компонента:

1) Нейросеть - мозги агента, как правило это LLM, понимает контекст задачи, строит план, формирует запросы к тулам.

2) Инструкция (промт) - набор правил, выглядит как подробный системный промпт, описывающий поведение агента, как агенту планировать работу, какие критерии использовать для оценки результата.

3) Память - может быть как краткосрочная (контекст диалога), так и долговременная (база знаний, профиль пользователя, файлы markdown). Важно понимать, что память, в отличии от тулов, работает всегда и информация из памяти может быть запрошена или сохранена на любом этапе работы агента.

4) Тулы (инструменты) - набор вызываемых при необходимости инструментов для взаимодествия с внешним миром, например поисковый движок, база данных, внешние API, браузер, файловая система, датчики, роборуки и так далее. В отличии от памяти модель видит список инструментов и планирует свои действия с учётом оных.


Когда это не агент?

У меня есть простые критерии оценки, если одного или нескольких компонентов представленных в списке выше нет, то это уже не агент, а интерфейс к модели.

Например:
- LLM + промпт (+ память)? -> чат-бот.
- LLM + память -> RAG-подобная система.
- LLM + тулы (+ промт)? (без планирования и оценки) -> классификатор/роутер.

В принципе в этот список можно накидать ещё несколько примеров, но думаю суть ясна, агент это прежде всего система работающих в унисон компонентов, настроенных таким образом, чтобы наиболее эффективно решать заранее определённые задачи.


Как из RAG агента сделать?

Предлагаю разобрать простенький кейс, предположим у нас есть классическая RAG-система, состоящая из модельки (llm), ретривера из базы знаний (тул), инструкции которая описывает поведение модельки (промт) и история диалога с пользователем (краткосрочная память).

Этого вполне хватает для ответов по корпоративной документации или скажем для беглого поиска по базе знаний.

Чтобы стать агентом нужно ещё добавить в системный промт планирование шагов и оценку результата выполнения каждого из шагов, плюс в добавок к кратковременной памяти чата можно добавить память долгосрочную, например для случаев когда пользователь просит агента запомнить что-то, скажем ответ на вопрос или формат ответа.


Итого

Имеем компоненты:
- Нейросеть - понимает, планирует, оценивает
- Инструкция - задаёт правила и критерии оценки
- Память - хранит контекст и опыт
- Тулы - позволяют взаимодействовать с внешним миром

Все четыре вместе - агент.

Минус любой - интерфейс к модели или некая иная система.

Долгосрочная память агентов

Под моей прошлой публикацией разгорелась бодрая дискуссия. В ходе которой я наконец-то четко сформулировал, что именно считаю "долгосрочной памятью" в контексте LLM-агентов и как, на мой взгляд, она должна работать.


Что я вообще называю памятью

Когда мы говорим "память" языковой модели, на практике речь идет про то, что реально попадает в контекст во время инференса:
- системный промт
- история сообщений
- любые дополнительные вставки (few-shots, заметки, справки, ссылки, извлеченные факты)
- вызов тулов и их ответы

То есть память - это не мистический модуль внутри модели, а то, чем мы обогащаем контекст диалога перед генерацией.


Два вида памяти моделей

- Краткосрочная - всё, что живет в текущей сессии и прямо подается в "messages" и "tools", это могут быть пары с ролями user/assistant и у некоторых моделей роль tool. По завершении сессии это естественным образом забывается (если не предпринять шагов по сохранению).

- Долгосрочная - всё, что сохраняется между сессиями и может быть автоматически извлечено и вставлено в будущие запросы. Это может быть база знаний, коллекция "вечных" заметок, библиотека кейсов или примеров. Ключевое: модель не обязана "знать", что где-то есть БД, она просто получает уже обогащенный промт.


Вызов БД как тула - это ещё не память

Тулы - это то, чем агент пользуется при необходимости, память же "работает всегда". Прежде чем модель что-то сгенерирует, контекст уже дополнен тем, что нужно вспомнить. Если мы заставляем модель осознанно "вызывать память как тул", это ближе к явному инструменту, а не к фоновому механизму.

Смысл долгосрочной памяти - функционировать автоматически, под нужный запрос подмешать нужные куски опыта без лишних размышлений модели о том, где они лежат.

[1/3]

Memory Copilot - концепт инструмента памяти агента

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

Поэтому вместо "внутреннего голоса" предлагаю более инженерный образ - "второй пилот" - сабагента, который целиком отвечает за память (саб- потому как у него нет своей памяти, он лишь оперирует тулами работы с базой).

И так, Memory Copilot - это самостоятельный сабагент, который:
1) обогащает промт перед генерацией за счет релевантного опыта, примерно как это описано в "Automatic Engineering of Long Prompts" (arXiv:2311.10117)
2) решает, что из результатов текущего шага стоит сохранить
3) работает автоматически, без того чтобы основная модель "тригерила память как тул"

То есть грубо говоря, я вижу данный модуль где-то между языковой моделью и интерфейсом общения с пользователем, эдаким генератором системного промта.

Предполагаю, что данный сабагент имеет только два тула:

- вспомнить (search) - происходит перед генерацией ответа, на этапе сборки промта. Агент сопоставляет текущий запрос пользователя с тем, что есть в долговременном хранилище, извлекает релевантные куски (например в виде few-shots или кратких "фактов") и подает это в контекст вместе с системными инструкциями и историей диалога.

- запомнить (save) - происходит после генерации, опциональный шаг. Агент оценивает полезность сгенерированного ответа и решает, стоит ли сохранить короткую выжимку из результата. Это снижает шум, экономит место и улучшает последующие извлечения.

Как это выглядит на одном запросе:

1) после запроса юзера вызываем search, в ответе получаем релевантные куски, добавляем в промт, генерируем ответ.

2) после ответа вызываем save, но не вслепую, сначала мини-оценка "LLM-as-a-judge" (есть ли уже такое воспоминание, пригодится ли это в будущем, оригинально ли, не дублирует ли уже сохраненное). Только если прошло отсев - сохраняем. Подробнее про оценку ответов в "From Generation to Judgment: Opportunities and Challenges of LLM-as-a-judge" (arXiv:2411.16594)

Такой цикл делает агента "самонастраивающимся", то есть чем дольше он работает, тем точнее подмешивает опыт и тем меньше ошибается ошибки, агент таким образом "учится", хотя наверно это не самая лучшая аналогия. Идея близка к линиям работы "Reflexion: Language Agents with Verbal Reinforcement Learning" (arXiv:2303.11366) про рефлексию и самокритику генераций, где модель перед сохранением оценивает свою же работу.


Не только лишь чат

Тот же принцип годится и "за пределами чатика".

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

По моим наблюдением добавление few-shots позитивно влияет на планирование вызова тулов, так как моделька быстрее и точнее выбирает нужный, про фьюшотс "Language Models are Few-Shot Learners" (arXiv:2005.14165).

В отличие запросов считаю, что ответы тула хранить не стоит, так как они устаревают и занимают место. Как по мне практичнее запоминать короткие правила и шаблоны действий, а не сам ответ.


Простенький пайплайн

1) Приходит запрос пользователя.
2) Сопоставление с долговременной памятью -> извлеченные фрагменты превращаем в few-shots/факты -> собираем промт.
3) Генерация ответа.
4) Быстрая проверка полезности результата (LLM-as-a-judge).
5) Если полезно, то дистиллируем и сохраняем.

На следующих шагах этот "опыт" автоматически всплывает при сборке промта.

[2/3]