Как вы делаем agent with theory of mind (понимание намерений пользователя)?

Краткий тезис

Theory of Mind (ToM) в контексте AI-агентов — это способность моделировать внутренние состояния пользователя: его цели, убеждения и знания. Реализация включает классификацию намерений (intent classification), отслеживание убеждений (belief tracking) и Probing|активное уточнение (Probing|active probing). Такой агент не просто отвечает на запрос, а понимает подтекст и контекст, что особенно важно для персонализированных RAG-систем и диалоговых ассистентов, когда одна и та же фраза может означать разные потребности в зависимости от ситуации.

1. Что такое Theory of Mind (ToM) и зачем она агенту

В психологии Theory of Mind (теория психического) — способность приписывать другим людям ментальные состояния (мысли, желания, намерения), отличные от собственных. В AI-агентах это превращается в моделирование пользователя: агент строит гипотезы о том, что пользователь знает, чего хочет и почему задаёт именно этот вопрос.

Без ToM агент отвечает буквально на поверхностный запрос. Например:

• Пользователь: «Где ключи?» → агент (без ToM): ищет документы про «ключи», выдаёт общую статью о хранении ключей.
• Агент с ToM: понимает, что пользователь потерял ключи, знает его привычки (обычно оставляет на тумбочке), задаёт уточняющие вопросы («Вы проверяли карманы куртки?») и даёт персонализированный ответ.

ToM критичен в Agentic RAG — системе, где агент сам решает, как использовать инструменты поиска, памяти и диалога, чтобы удовлетворить глубинную потребность пользователя.

2. Компоненты ToM-агента

Архитектура ToM-агента состоит из четырёх ключевых блоков:

Эти блоки работают циклически: агент получает запрос → обновляет User Model → классифицирует намерение → проверяет Belief Tracker → при необходимости задаёт уточняющий вопрос → формирует ответ и обновляет состояние.

3. User Modeling (моделирование пользователя)

User Model — структура, которая агрегирует всю известную информацию о пользователе. Она может быть статической (заполняется один раз) или динамической (обновляется после каждого взаимодействия).

Поля типичного профиля:

{
  "user_id": "u123",
  "name": "Иван",
  "context": {
    "time_of_day": "18:00",
    "location": "home",
    "recent_activity": ["looking_for_keys", "asked_about_dinner"]
  },
  "knowledge_state": {
    "known_facts": ["ключи лежат на тумбочке"],
    "unknown_topics": ["где сейчас ключи"]
  },
  "preferences": ["короткие ответы", "детали про безопасность"]
}

Как собирать данные:

• Из явного ввода (пользователь указал «я дома»)
• Из истории диалогов (ранее сказал «я ищу ключи» → сохраняем intent)
• Из внешних источников (календарь, IoT-датчики — если система интегрирована)

Проблема: User Model может быть неполным или ошибочным. Агент должен допускать, что его модель не идеальна, и использовать Probing|active probing для коррекции.

4. Intent Classification (классификация намерений)

Intent Classification — задача определить, что на самом деле хочет пользователь. Различают поверхностный intent (буквальный запрос) и глубинный (стоящая цель).

Методы:

1. LLM-based zero-shot — промпт вида: "Определи намерение пользователя. Выбери из списка: lost_item, information_query, complaint, chitchat." — гибко, но дорого.
2. Fine-tuned encoder — BERT или RoBERTa, дообученные на корпусе диалогов (быстро, дешёво, но требует размеченных данных).
3. Rule-based — если домен узкий (например, поддержка умного дома), можно использовать регулярные выражения.

Пример на LangChain (zero-shot):

from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI

prompt = ChatPromptTemplate.from_messages([
    ("system", "Ты — классификатор намерений. Пользователь говорит: {query}. Какое у него намерение? Варианты: lost_item, information, complaint, other. Ответь одним словом."),
    ("human", "{query}")
])

llm = ChatOpenAI(model="gpt-4")
chain = prompt | llm
intent = chain.invoke({"query": "Где ключи?"})
# -> lost_item

Как учесть контекст: Добавлять в промпт историю диалога и текущее состояние User Model.

5. Belief Tracking (отслеживание убеждений)

Belief Tracker отвечает на вопрос: «Что пользователь уже знает?» Это динамическая база фактов, которая обновляется после каждого ответа агента. Если агент сказал: «Ключи на тумбочке», Belief Tracker записывает, что пользователь теперь знает этот факт. При следующем запросе «Где ключи?» агент поймёт, что пользователь либо забыл, либо не поверил, либо факт устарел.

Реализация:

• Использовать векторную БД (FAISS, Chroma) для хранения фактов, которые считаются известными пользователю.
• При получении запроса сначала проверить, есть ли релевантный факт в этой БД. Если есть — ответить «Вы уже знаете, что…», иначе запустить поиск в основной RAG.

Пример схемы факта:

{
  "fact": "ключи лежат на тумбочке",
  "timestamp": "2024-01-15T18:00:00Z",
  "confidence": 0.95,
  "source": "assistant_response"
}

Ограничение: Belief Tracker может ошибочно считать, что пользователь запомнил информацию, хотя на самом деле он её проигнорировал. Можно добавить механизм подтверждения: «Вы поняли, где ключи?».

6. Active Probing (активное уточнение)

Active Probing — агент задаёт уточняющие вопросы, чтобы снизить неопределённость в своих гипотезах о намерении пользователя или его знаниях. Стратегии:

1. Uncertainty-driven: если у Intent Classifier низкая уверенность (<0.7), агент спрашивает: «Вы имеете в виду поиск ключей или информацию о том, как их хранить?»
2. Information Gain: агент выбирает вопрос, ответ на который даст максимум новой информации (например, «Вы уже смотрели на тумбочке?» — если ответ «нет», то это важная информация).
3. Conversational: естественный диалог, как человек: «Потеряли? Когда в последний раз видели?»

Пример промпта для генерации вопроса:

Ты — агент, который помогает пользователю. На основе его запроса и контекста придумай один вопрос, который поможет уточнить его реальную потребность. Учти, что пользователь может быть в стрессе (потерял вещь).
Запрос: {query}
История: {history}
Вопрос: 

Правила хорошего probing:

• Не задавать больше 1–2 вопросов за раз (иначе раздражает)
• Предлагать варианты ответа (да/нет/выбор из нескольких)
• Использовать вежливый тон

7. Полный пример работы ToM-агента (псевдокод)

class ToMAgent:
    def __init__(self):
        self.user_model = load_user_model("u123")
        self.belief_tracker = BeliefTracker(dimension=768)  # векторная БД
        self.rag = RAGSystem(documents="my_docs")
        self.intent_classifier = IntentClassifier()

    def handle_query(self, query):
        intent = self.intent_classifier.classify(query, user_model=self.user_model)
        
        if intent == "lost_item" and self.user_model.context.location == "home":
            # уточняем, проверял ли пользователь типичные места
            known_fact = self.belief_tracker.lookup("key_location")
            if known_fact:
                return f"Ранее я говорил, что ключи были на тумбочке. Проверьте ещё раз."
            else:
                probe = self.generate_probe(intent, query)
                return probe + " (после ответа обновлю belief)"
        else:
            return self.rag.retrieve_and_answer(query)

Обновление Belief Tracker после ответа пользователя на уточнение добавляет новый факт в БД.

8. Проблемы и ограничения

• Неполнота модели: агент может ошибочно предположить намерение, что приведёт к нерелевантному ответу.
• Затраты на LLM: каждый probing — дополнительный вызов LLM, что увеличивает latency и стоимость.
• Приватность: хранение детальной User Model может нарушать GDPR или другие законы. Нужно анонимизировать и давать пользователю контроль над данными.
• Сложность отладки: ToM агенты — чёрные ящики. Трудно понять, почему агент решил задать именно такой вопрос.

Как смягчить:

• Использовать fine-tuned модели для intent classification (дешевле)
• Логировать все решения агента для анализа
• Давать пользователю возможность отключить ToM (режим "буквальный ответ")

9. Сравнение с другими подходами к агентам

ToM-агент выигрывает в сценариях, где важна персонализация (персональный ассистент, поддержка клиентов), но проигрывает в простых задачах из-за накладных расходов.

10. Пет-проект для закрепления

Задача: Реализовать ToM-агента для помощи в поиске потерянных вещей в доме.

Инструменты: Python, LangChain, OpenAI API (gpt-4 или gpt-4o-mini), FAISS (для Belief Tracker), SQLite (для User Model).

Шаги:

1. Создайте User Model с полями: имя, тип жилья (квартира/дом), список привычных мест для ключей/телефона.
2. Реализуйте Intent Classifier на базе LLM с двумя классами: lost_item (потеря вещи), general (информация).
3. Реализуйте Belief Tracker на FAISS: храните факты вида «{предмет} находится в {месте}» и метаданные (время, уверенность).
4. Напишите цикл обработки запроса:
   • Определите intent.
   • Если lost_item — проверьте Belief Tracker. Если факт найден — спросите: «Ранее я говорил, что ключи на тумбочке. Вы проверили?» (активное уточнение). Иначе — задайте probing-вопрос: «Когда вы в последний раз видели ключи?»
   • Получите ответ пользователя, обновите User Model и Belief Tracker.
5. Протестируйте на диалогах (например, пользователь говорит «я потерял ключи», затем «да, я смотрел на тумбочке, их там нет» — агент должен предложить проверить карманы).

Ожидаемый результат: Агент, который не просто выдаёт общий ответ, а адаптируется к пользователю, задаёт уточняющие вопросы и использует историю, чтобы не повторять одно и то же.

11. Связь с другими вопросами

Навигация

• Предыдущий: 579
• Следующий: 581
• Индекс: 00. Индекс разборов