Уменьшите галлюцинации ИИ‑ассистента с помощью более коротких маршрутов

Почему ассистенты начинают угадывать

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

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

Обычно это происходит из-за лишних переходов. Файл хранится в одной системе, доступ — в другой, а согласование зависит от ответа человека позже. К тому времени, когда ассистент получает достаточно контекста, он уже потратил много усилий на поиск, ожидание или работу с частичной информацией. Вот когда ответы становятся расплывчатыми, а действия уходят в сторону.

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

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

Многие команды начинают с переписывания подсказок. Это может немного помочь. Но не решит длинный маршрут к правде. Если модели нужно прочесать папки, запросить доступ и ждать согласования, угадывание — ожидаемый результат.

Паттерн простой: короткий путь — лучше результат. Длинный путь — больше выдуманных деталей.

Где прячется длинный маршрут

Модель редко угадывает из ниоткуда. Она угадывает после того, как не успевает быстро добраться до реального источника.

Проблема часто начинается, когда ответ хранится в одном месте, а ассистенту доступна лишь копия копии. Кто-то спрашивает про цены, политику, шаг развёртывания или решение прошлой недели. Ассистент проверяет слой поиска. Тот обращается к индексу. Индекс зависит от синхронизации. Синхронизация взяла данные из папки, которую никто не обновлял месяцами.

Скрытые переходы, которые создают проблемы

Путь от вопроса до правды часто выглядит так:

• чат —> сервис поиска
• сервис поиска —> индекс поиска или векторный индекс
• индекс —> синхронизированные документы или экспортированные страницы
• копии документов —> оригинальные файлы, тикеты или код
• ассистент —> человек за доступом или согласованием

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

Устаревшие копии создают один тип путаницы. Отсутствие прав — другой. Если ассистент видит вики проекта, но не репозиторий, он может отвечать на вопрос по коду по старым заметкам вместо по актуальному коду. Если он открывает дизайн-заметки, но не биллинговую систему, он может придумать статус, потому что реальное число спрятано за блокировкой.

Каждый лишний шаг добавляет два издержки: задержку и сомнение. Задержка очевидна: больше инструментов — больше вызовов, ожидания и точек отказа. Сомнение тише, но наносит больше вреда. Модель должна решить, достаточно ли найденного фрагмента. При длинном маршруте она видит фрагменты вместо фактов.

Вот почему некоторые команды винят модель, когда настоящая проблема — в дизайне доступа. Если самый короткий путь к правде проходит через шесть переходов и два согласования, ассистент тратит больше времени на латание дыр, чем на ответ.

Как сократить поиск

Большинство настроек поиска слишком широки. Команды сваливают в один индекс все справочники, выгрузки тикетов и старые вики, а затем ждут, что ассистент вытянет один чистый ответ. Обычно он не может. Модель видит слишком много, получает противоречивые сигналы и заполняет остальное.

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

Меньшие наборы источников часто работают лучше, чем большие. Сохраняйте те источники, которые прямо отвечают на распространённые задачи. Остальное убирайте из потока по умолчанию. Старые материалы доступны для ручного поиска.

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

Размер фрагментов тоже важен. Большие куски кажутся эффективными, но часто скрывают одну строку, которая отвечает на вопрос. Меньшие фрагменты с понятными метками работают лучше. Метки не должны быть навороченными: имя источника, ответственный, дата последнего обновления, тип документа и версия обычно достаточно.

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

Измеряйте путь, а не только итоговый ответ. Посчитайте переходы от вопроса к источнику. Один-два шага обычно приемлемы. Дальше — вкрадывается угадывание. Вы увидите это быстро в софтверных командах: если ассистенту по программированию нужен текущий регламент развёртывания, он должен читать живую документацию в репозитории или runbook напрямую, а не сводку от старого рабочего пространства.

Короткие маршруты поиска — не про фишки. Они про строгость. Эта дисциплина экономит время и хранит ответы в пределах фактов.

Как исправить доступ к файлам

Плохой доступ к файлам заставляет ассистента угадывать. Хороший доступ позволяет прочитать реальный источник в нужном месте и в нужный момент.

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

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

Имена файлов тоже имеют значение. Когда в команде есть «final», «final v2» и «new final», и люди, и ассистенты выбирают неправильную версию. Используйте простые имена. Добавляйте даты при необходимости. Держите одну текущую версию, которую все считают источником правды.

Правила записи должны соответствовать работе. Некоторые команды дают широкий доступ на чтение, но блокируют все правки — ассистент видит проблему, но не может исправить файл. Другие позволяют правки в захламлённых общих папках. Лучше сделать узко и ясно:

• разрешать ассистенту читать исходные файлы, связанные с его задачей
• разрешать запись только в утверждённые папки или ветки
• держать чувствительные папки отдельно от повседневной работы
• архивировать старые версии, чтобы текущая было легко найти

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

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

Как сократить согласования

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

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

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

Важны мелкие запросы. Не просите человека одобрить «обновить конфиг» расплывчато. Попросите один конкретный шаг с достаточной детализацией для быстрого решения:

• точный файл или систему, к которой ассистент хочет прикоснуться
• diff или команду, которую он планирует выполнить
• причина в одном предложении
• простой выбор «да» или «нет»

Такой формат сокращает задержку, потому что рецензенту не нужно сначала расследовать. Он может решить за секунды.

Помогают и временные лимиты. Согласование, висящее два часа, почти так же плохо, как отклонение — ассистент теряет контекст и может пойти по другому пути. Установите срок истечения, а потом определите, что происходит дальше: повторный запрос, обращение к другому человеку или аккуратная остановка.

На практике работает поэтажная модель. Позвольте ассистенту читать логи, просматривать CI-вывод, искать в репозитории и писать черновой код без прерываний. Заставляйте спрашивать разрешение перед изменением инфраструктуры, использованием учётных данных, слиянием в защищённые ветки или доступом к данным клиентов.

Цель не в отмене контролей любой ценой. Цель — более чёткие контроли. Когда согласования редки, конкретны и быстры, модель тратит больше времени на работу с фактами и меньше — на импровизации вокруг заблокированных путей.

Простой пример из продуктовой команды

У продуктовой команды был ассистент поддержки, который отвечал на вопросы о возвратах. Клиенты спрашивали простое: «Могу ли я вернуть деньги?» или «Почему мне отказали в возврате?» Ассистент должен был решать большинство таких случаев, но постоянно угадывал, потому что путь к фактам был слишком длинным.

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

Такая настройка тратила время и давала противоречия. Один документ говорил, что возвраты разрешены в течение 14 дней. Другой — 30 дней для годовых планов. Скопированная заметка упоминала праздничное исключение, которое истекло месяцы назад. Агентам приходилось вмешиваться, потому что ассистент цитировал неверное правило или просил согласование, когда оно не требовалось.

Команда сократила путь до двух источников. Ассистент мог читать один живой файл политики, которым вместе владели финансы и поддержка, и одну запись клиента с датой заказа, планом, статусом оплаты и историей возвратов. Ничто другое не считалось истиной.

Они также добавили одно простое правило согласования. Если возврат меньше $50 и покупка в пределах политики, ассистент мог одобрить его. Если $50 или больше, вне окна политики или на аккаунте были флаги злоупотреблений, дело шло к менеджеру.

Результат проявился быстро. Раньше медианный ответ занимал около 8 минут, потому что ассистент искал, сравнивал и застревал в очередях. После изменений большинство ответов выходили менее чем за 90 секунд.

Ошибок тоже стало меньше. Раньше около 15% ответов по возвратам требовали правки от человека. После перехода на один живой файл политики и одну запись клиента это упало до примерно 2%.

Вывод прост. Модели не нужно более хитрое формулирование. Ей нужен короткий путь к истине.

Ошибки, которые удлиняют маршрут

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

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

Ещё одна проблема — исходный материал исчезает за суммами от сумм. Бриф продукта превращается в проектную сводку, затем в обновление команды, затем в заметку чат-бота. К моменту, когда модель читает её, исходная детализация исчезла. Даты пропали. Граничные случаи пропали. Маленькие изменения в формулировке тоже исчезают, а именно эти мелочи часто решают, верен ли ответ.

Потоки согласования вызывают ту же задержку, когда никто их не ставит под вопрос. Если ассистенту нужен доступ, чтобы прочитать безобидную спецификацию, changelog или результат теста, инструмент останавливается так часто, что люди начинают обходить его или задавать расплывчатые вопросы. Шлюзы должны защищать секреты, траты и изменения в продакшене. Они не должны блокировать рутинное чтение.

Гигиена папок наносит тихий ущерб. Старые и текущие файлы лежат рядом с именами вроде «final», «final-v2» и «current-new». Ассистент видит их все как возможную истину. Если команда не может сказать, какой файл актуален за десять секунд, модель тоже не сможет.

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

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

Исправления обычно небольшие. Держите живой источник лёгкодоступным. Ясно архивируйте старое. Уберите ворота, которые ничего не защищают. Короткие пути оставляют ассистенту меньше пространства для выдумок.

Быстрая проверка вашей настройки

Если ассистенту нужно три поиска, два согласования и сообщение коллеге, прежде чем он сможет прочитать реальный источник, он сам заполнит пробелы. Лучшие подсказки это не решат.

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

Начните с пары простых вопросов. Может ли он добраться до исходника в один-два шага? Если нужно прыгать через вики, тикет и скопированную заметку, маршрут слишком длинный.

Проверьте ясность файлов. Ассистент должен понять, какой файл актуален, не догадываясь по именам вроде «final_v2» или «latest-new». Одна явная текущая версия лучше папки, полной похожих совпадений.

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

Хорошая настройка обычно проста для объяснения и людьми. Если коллега не может описать правила доступа за минуту, система слишком запутана. Модели путаются так же, как и люди.

Логи покажут, где всё ломается. Они должны указывать, что ассистент пытался открыть, какой инструмент или разрешение остановило его и когда он переключился с фактов на догадки. Без этого следа команды спорят об ответе, вместо того чтобы чинить маршрут.

Короткий обзор должен подтвердить пять вещей:

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

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

Что изменить в первую очередь на следующей неделе

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

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

Сделайте три небольших сокращения вместо полного передела:

• уберите один шаг поиска, если два инструмента указывают на одни и те же документы
• удалите один устаревший источник, который поддерживает старые правила
• снимите одно согласование, если действие низкорисковое и легко отменяемо

Вы не просите модель думать усерднее. Вы даёте ей меньше пространства для догадок.

Протестируйте новый поток на десяти реальных запросах из повседневной работы. Возьмите их из тикетов, чатов, писем или запросов документов. Смешайте простые запросы с теми, что обычно создают переделку. Для каждого запроса проверьте три вещи: дошёл ли ассистент до правильного источника, ответил ли он верно и сколько занял весь путь.

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

Если команда всё время натыкается на ту же проблему, полезен внешний обзор. Oleg Sotnikov пишет про такую системную работу на oleg.is и консультирует стартапы и маленькие команды в роли Fractional CTO. Полезная часть — не только шлифовка подсказок, а исправление дизайна поиска, доступа и согласований, чтобы ассистенты работали с реальным источником, а не с догадками.