TL;DR
LLM с доступом к инструментам (калькулятор, поиск, Code Interpreter) могут решать задачи двумя путями: вспомнить из внутренней памяти или вызвать инструмент. Tool-Memory Conflict (TMC) — это когда эти два способа дают разные ответы на один и тот же вопрос. Исследование показало: конфликты встречаются в половине случаев (49.8%), и даже когда у модели есть калькулятор, она может его проигнорировать.
Проблема особенно остра в математике и STEM (70-80% конфликтов). Модель может "вспомнить" приблизительный ответ вместо того чтобы точно посчитать — выдаст 2999 вместо 3000, потому что такой паттерн чаще встречался в обучающих данных. Даже GPT-4o в 40% случаев выбирает память вместо инструмента, хотя её специально обучали использовать внешние инструменты. Мелкие модели (<70B параметров) игнорируют инструменты в 80% случаев, даже если явно попросить их использовать.
Исследователи проверили 7 моделей на тысячах задач, решая каждую дважды: с явным указанием "только память" и "только инструменты". Обнаружили, что крупные модели (>70B) чаще доверяют инструментам, но всё равно делают неправильный выбор в 40% случаев. Ещё хуже: в трети конфликтов оба источника неправильны — они просто ошибаются по-разному. Существующие методы разрешения конфликтов (prompting, RAG) не работают для TMC.
Пример применения
Задача: Проверяешь финансовую модель своего маркетплейса перед питчем Тинькофф Ventures
Промпт:
Проверь расчёт unit-экономики для питча инвестору:
CAC через таргет ВК: 3500₽
Средний чек: 890₽
Частота покупок: 4.7 раза в год
Средний lifecycle: 18 месяцев
Маржинальность: 35%
Какой реальный LTV и LTV/CAC?
Используй Code Interpreter для точных вычислений — это критично,
инвестор будет проверять цифры.
Результат:
Модель активирует Code Interpreter и выдаст точный расчёт: LTV = 2092₽, LTV/CAC = 0.60. Без явного указания "используй Code Interpreter" модель могла бы сгенерировать приблизительный ответ "из головы" (например, "около 2200₽") — выглядит правдоподобно, но ошибка в 5-10% может быть катастрофой на встрече с инвестором, который пересчитает и увидит несостыковку.
Почему это работает
LLM генерирует текст токен за токеном, опираясь на статистические паттерны из обучающих данных. Когда модель видит математическую задачу, она может пойти двумя путями: вспомнить похожий паттерн (быстро, но неточно) или вызвать инструмент (точно, но требует явной активации).
Проблема: во время обучения модели чаще видели приблизительные рассуждения, чем точные вычисления. Поэтому по умолчанию она склонна генерировать ответ "из головы" — даже если у неё есть калькулятор. Это как человек, который на вопрос "сколько будет 127 × 83" отвечает "примерно 10 000" вместо того чтобы взять калькулятор — не потому что не умеет, а потому что привычка думать приблизительно сильнее.
Крупные модели (>70B параметров) лучше "понимают" когда нужна точность и чаще обращаются к инструментам. Но даже GPT-4o в 40% случаев выбирает память вместо инструмента. Мелкие модели (<8B) почти всегда игнорируют инструменты и полагаются на свою память — даже когда она откровенно врёт.
Рычаги управления:
Явное указание на использование инструментов — "используй Code Interpreter", "проверь через калькулятор", "вызови поиск по актуальным данным". Это повышает вероятность правильного выбора, но не гарантирует его.
Двойная проверка для критичных задач — попроси решить задачу дважды: один раз обычным способом, второй раз явно через инструменты. Если ответы различаются — это сигнал проверить вручную.
Учитывай размер модели — если работаешь с мелкой моделью (<70B), она проигнорирует инструменты в 80% случаев, даже если ты явно попросишь. В таких случаях лучше сразу делать вычисления самостоятельно, не надеясь на модель.
Применение
Для точных вычислений (финансы, метрики, сложные расчёты):
{твоя задача с числами}
Используй Code Interpreter для точных вычислений.
Это критично, нужна точность до копейки/процента/единицы.
Покажи код и результат вычислений.
Указание показать код даёт дополнительный сигнал модели, что нужна прозрачность и точность, не приблизительная оценка.
Для проверки конфликтов (когда сомневаешься в ответе):
Ты дал мне ответ: {предыдущий ответ модели}
Теперь реши ту же задачу используя инструменты (калькулятор/поиск/код).
Если ответы различаются — объясни почему и какой правильный.
Этот приём помогает поймать Tool-Memory Conflict — если модель сначала генерировала "из головы", а потом через инструмент выдала другое, ты увидишь расхождение и сможешь выбрать точный вариант.
Для задач с актуальными данными (курсы, погода, свежие новости):
{твоя задача}
Используй поиск для получения актуальных данных на {сегодняшняя дата}.
Не полагайся на внутреннюю память — информация может быть устаревшей.
Явное указание на дату и на использование поиска снижает риск, что модель выдаст устаревшие данные из своей памяти (которая обрезана на дату обучения).
Ограничения
⚠️ Не всегда очевидно когда нужны инструменты: Если задача выглядит как "знание факта", но требует актуальных данных (курсы валют, погода, свежие новости) — модель может не распознать необходимость поиска и выдать устаревшую информацию из памяти.
⚠️ Явное указание не гарантирует использование: Даже с фразой "используй калькулятор" мелкие модели (<70B) игнорируют инструкции в 80% случаев. Если работаешь с маленькой моделью на точной задаче — лучше считать самостоятельно.
⚠️ Оба источника могут быть неправильны: В 36% конфликтов ни память, ни инструмент не дают правильного ответа — они просто ошибаются по-разному. Это происходит когда и внутренние знания модели неточны, и инструмент получил некорректные данные (или модель неправильно его вызвала). Конфликт не гарантирует, что хотя бы один вариант правильный.
⚠️ Гуманитарные задачи почти без конфликтов: В задачах на интерпретацию, рассуждения, креатив конфликты встречаются редко (10-15%). Там требование инструментов обычно не нужно и может даже навредить, делая ответ механистичным.
Как исследовали
Команда взяла 7 моделей разного размера (от GPT-4o и DeepSeek-V3 до маленьких 8B вроде Groq-LLAMA-3) и прогнала их через тысячи задач из популярных бенчмарков — математика (GSM8K, MATH-500), STEM (GPQA Diamond), гуманитарные науки (MMLU), олимпиадная математика (AIME 2024).
Хитрость была в дизайне: каждую задачу модель решала дважды. Первый раз — с явной инструкцией "используй только внутреннюю память, без инструментов", второй раз — "используй только внешние инструменты (калькулятор/поиск/код)". Исследователи сравнивали ответы и считали когда они различаются — это и есть Tool-Memory Conflict.
Результаты удивили: почти в половине случаев (49.8%) ответы не совпадали. Для математики конфликты взлетели до 70-80% — модель "помнит" один ответ, калькулятор даёт другой. Но интереснее другое: когда моделям давали оба ответа и просили выбрать правильный, крупные модели в 40-44% случаев выбирали инструмент (tool bias), мелкие — почти всегда свою память (memory bias), даже если она врала. QwQ (32B) и Groq-LLAMA-3 (8B) показали memory bias до 80% — они упрямо доверяют своей памяти, игнорируя инструменты.
Самое неожиданное: в трети случаев конфликта оба источника были неправильны, но ошибались по-разному. Это показывает, что проблема глубже чем просто "память устарела" — это фундаментальная сложность интеграции двух разных механизмов получения знаний. Модель не просто выбирает между правильным и неправильным, она выбирает между двумя ошибками.
Практический инсайт для читателя: Это объясняет почему GPT-4 иногда делает глупые арифметические ошибки, хотя у неё есть калькулятор — она просто решила сгенерировать ответ из памяти вместо того чтобы вызвать инструмент. И это не баг, это особенность архитектуры: генерация из памяти — естественный режим работы transformer, а вызов инструмента — дополнительное действие, которое нужно явно активировать.
Исследователи также проверили существующие методы разрешения конфликтов (opinion-based prompting, vigilant prompting, RAG) — ни один не сработал для Tool-Memory Conflict. Это значит, что простых готовых решений нет, и пока единственный надёжный способ — явно контролировать использование инструментов в промптах.
Ресурсы
Investigating Tool-Memory Conflicts in Tool-Augmented LLMs — работа показывает что интеграция внешних инструментов в LLM сложнее чем кажется, и даже обученные модели не всегда используют инструменты когда нужно. Jiali Cheng, Rui Pan, Hadi Amiri (University of Massachusetts Lowell, University of Illinois Urbana-Champaign). Представлена на The 2nd Workshop on Reliable and Responsible Foundation Models @ ICML 2025.