Матрица целей обработки для LLM: как собрать без пробелов

Почему матрица ломается на старте

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

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

Обычно матрицу ломают четыре привычки:

• брать название фичи из бэклога и считать его целью обработки;
• сводить в одну запись рабочий запрос, технические логи, файлы и разметку для eval;
• оставлять поля "на всякий случай", хотя никто не может объяснить, зачем они нужны;
• ставить один срок хранения на весь массив, чтобы не спорить на старте.

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

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

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

Как выглядит рабочая матрица

Рабочая матрица живет не на уровне "модуль поддержки" или "AI-ассистент". Она живет на уровне одного сценария. Одна строка - одно действие продукта с понятным входом и понятным результатом. Например: "оператор отправляет диалог клиента в модель, чтобы получить черновик ответа". Если в строке описывать весь модуль целиком, точность по данным и срокам хранения пропадает сразу.

Базового набора колонок обычно достаточно:

• сценарий продукта;
• цель обработки;
• категории данных;
• срок хранения;
• получатель данных;
• владелец строки;
• дата пересмотра.

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

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

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

Если команда работает через RU LLM, такой разбор особенно полезен. У запроса могут быть промпт, ответ, файлы, маскирование PII и аудит-трейлы. Лучше сразу понять, за какой слой отвечает продукт, ML-команда, поддержка или ИБ.

Поле "дата пересмотра" многие пропускают зря. Сценарии меняются быстро: сегодня бот только подсказывает ответ, завтра еще классифицирует обращения и пишет summary в CRM. Без даты пересмотра строка остается старой, а риск уже меняется.

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

Как выделить сценарии продукта

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

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

Продукт удобнее раскладывать на короткие цепочки:

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

Так сразу видно, где сценарии действительно похожи, а где данные, доступы и риск уже другие.

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

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

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

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

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

Как собрать строку матрицы

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

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

1. Назовите сценарий простыми словами. Если фразу не поймет руководитель поддержки без пояснений, она слишком абстрактна.
2. Запишите цель коротким предложением с действием. Лучше "сгенерировать черновик ответа по обращению", чем "улучшать клиентский сервис".
3. Оставьте только нужные данные. Для этого сценария обычно хватает текста обращения, истории переписки, номера заказа и статуса заявки. Паспорт, адрес или старые вложения не нужны, если модель их не использует.
4. Назначьте срок хранения отдельно для промпта, ответа, логов и файлов. Один общий срок почти всегда ломает логику.
5. Укажите владельца строки и дату следующей проверки. Лучше назначать не отдел, а конкретную роль или человека.

Черновик строки может выглядеть так:

Сценарий: LLM готовит черновик ответа оператору
Цель: сгенерировать черновик ответа по текущему обращению
Данные: текст обращения, история переписки, номер заказа, статус заявки
Срок хранения: промпт - 30 дней, ответ - 30 дней, логи - 180 дней, файлы - 7 дней
Владелец: руководитель поддержки
Следующая проверка: 15.07.2026

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

Как описать категории данных без тумана

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

Лучше делить вход на отдельные группы, даже если строка станет чуть длиннее. Обычно хватает пяти:

• текст запроса или диалога;
• метаданные запроса: время, канал, язык, тип операции;
• файлы и вложения: PDF, скриншоты, аудио, изображения;
• логи и трассировка: request_id, коды ошибок, время ответа;
• идентификаторы: user_id, session_id, номер заявки, номер договора.

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

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

Хорошая формулировка звучит конкретно: "текст обращения клиента, может содержать ФИО, телефон и адрес доставки; вложения PDF, могут содержать договор и паспортные реквизиты; метаданные запроса без ПДн; логи содержат request_id и статус ответа". Плохая формулировка звучит так: "любые данные пользователя".

Если модель видит PII, это нужно писать прямо в строке матрицы, а не прятать в примечаниях. Не "возможна персональная информация", а "модель получает телефон и адрес из текста обращения" или "модель может получить паспортные данные из вложенного файла". Иначе юристы, безопасники и инженеры прочитают одну и ту же строку по-разному.

Есть и простой тест на здравый смысл. Представьте реальный запрос в поддержку: клиент пишет "Мой номер +7..., заказ не пришел" и прикладывает чек. В матрице должны отдельно появиться текст обращения, номер телефона, номер заказа, изображение чека, служебный request_id и срок жизни логов. Если хоть один элемент потерялся, описание все еще мутное.

Даже если шлюз маскирует PII в логах, как это делает RU LLM, в матрице все равно фиксируют исходную категорию данных, которую модель получает на вход. Маскирование логов и состав входных данных - разные вещи.

Как назначить срок хранения

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

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

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

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

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

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

Практичное правило простое: сначала ставьте короткий срок, потом увеличивайте его, если для этого есть причина. Для технических логов часто хватает 7-30 дней, а для истории обращения срок обычно привязывают к жизненному циклу тикета или договора. Если вы работаете через RU LLM, хранение логов и бэкапов в РФ помогает закрыть часть инфраструктурных требований, но не отвечает за сам срок. Его все равно задают ваш сценарий, состав данных и основание обработки.

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

Пример для помощника службы поддержки

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

Как может выглядеть строка матрицы

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

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

Срок хранения удобнее делить по типам записи, а не ставить одно число на все сразу:

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

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

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

Если запросы идут через RU LLM, команде проще развести аудит-трейлы, маскирование PII и хранение логов внутри РФ. Но и в этом случае матрица должна прямо отвечать на четыре вопроса: зачем вы отправляете обращение в модель, какие поля уходят, где они сохраняются и когда вы их удаляете.

Где команды чаще ошибаются

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

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

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

Еще одна проблема - в матрицу тянут поля "на всякий случай". Например, сценарий использует текст вопроса и номер заявки, а в таблицу попадают e-mail, телефон, адрес и дата рождения только потому, что они есть в профиле клиента. Так матрица разрастается, а лишние поля потом начинают жить своей жизнью в логах, экспортах и бэкапах.

Отдельно команды часто путают собственные логи и логи провайдера. Это не одно и то же. Если приложение пишет ID пользователя, время запроса и результат маршрутизации, а поставщик модели видит только промпт и метаданные вызова, в матрице нужны разные строки или хотя бы разные поля учета. При работе через шлюз вроде RU LLM слоев может быть еще больше: логи приложения, журналы шлюза, аудит-трейлы и данные у поставщика модели. Смешивать их в одну графу нельзя.

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

Тревожные признаки обычно такие:

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

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

Быстрая проверка перед релизом

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

Хороший тест занимает 10-15 минут. Смотрите не на красивый текст, а на то, выдержит ли матрица реальную работу продукта.

• У каждой строки есть конкретный владелец. Не "команда платформы", а роль или человек, который отвечает за эту обработку и обновляет запись. Рядом стоит дата пересмотра.
• Для каждого типа данных есть простое объяснение, зачем он нужен именно в этом сценарии. Если e-mail, номер договора или текст обращения нельзя связать с целью, этот тип данных стоит убрать.
• Логи, вложения и история чата живут по разным правилам. Логи нужны для разбора сбоев, файлы часто тянут лишние персональные данные, а история диалога влияет на качество ответа. Один общий срок хранения для всего почти всегда ошибочен.
• Команда знает, где данные лежат физически. Не только "в облаке", а в какой стране, у какого провайдера и в каких контурах хранятся логи и бэкапы.
• Выгрузка или удаление данных не ломают сам сценарий. Если пользователь просит удалить историю, помощник не должен перестать работать целиком.

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

Небольшой пример. Служба поддержки загружает переписку клиента и файл с чеком. Для чата можно оставить короткую историю на время решения обращения. Для технических логов обычно нужен отдельный, более короткий срок. Для файла срок может быть другим, потому что в нем больше чувствительных полей. Если команда работает через RU LLM, полезно отдельно зафиксировать, что логи и бэкапы хранятся в РФ. Это важно не только для юристов, но и для инженеров, которые настраивают реальный путь данных.

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

Что сделать после первой версии

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

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

После встречи откройте живые примеры запросов и логов. Сверять нужно не описание фичи, а фактический трафик. У команды поддержки, например, в матрице может стоять только "текст обращения", а в реальном запросе уже есть номер заказа, e-mail, внутренний id клиента и кусок истории диалога.

Для первой ревизии обычно достаточно четырех проверок:

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

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

Если вы ведете трафик через RU LLM, стоит сделать еще одну сверку: матрица должна совпадать с тем, как платформа хранит логи и бэкапы в РФ, где ставит AI-Law метки и как формирует аудит-трейлы по каждому запросу. Для команд, которым нужен единый OpenAI-совместимый эндпоинт и российский контур хранения, такая проверка особенно полезна.

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