Данные: у каждого ответа должен быть адрес

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

Работа с данными начинается с назначения источника истины. Это место, где хранится принятая версия конкретного факта: цена, статус заявки, условие договора или решение встречи. Для разных типов информации источники могут отличаться. Главное, чтобы их приоритет и владелец были определены.

Отделить документ от действующего правила

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

Если материал содержит личные сведения, коммерческую тайну или клиентские ограничения, определите допустимый режим обработки до загрузки. Решение зависит от содержания, договоров и используемой системы. Универсальное утверждение «облако безопасно» или «всё должно быть только локально» не заменяет разбор требований.

Понимать поиск по документам

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

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

Модель 04 · архитектура данных

Развернуть ↗Поделиться ↗

EVOLVIN MEDIA / ПРАКТИКА

Ответ проверяем, когда у факта есть источник

1. 01

   Договорённость

   Действующая запись: Утверждённый документ

   Условие использования: Версия и дата

2. 02

   Клиент / запрос

   Действующая запись: Карточка в CRM

   Условие использования: Владелец и доступ

3. 03

   Решение встречи

   Действующая запись: Согласованный протокол

   Условие использования: Автор утверждения

4. 04

   Справочное правило

   Действующая запись: Управляемый справочник

   Условие использования: Срок актуальности

База знаний начинается с права знать.

Переслать мысль с карточкой ↗

Как читать схему

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

Вертикальная версия для телефона. Полную композицию можно открыть кнопкой «Развернуть».

Сделать пробел видимым

Попросите систему отдельно отмечать отсутствующие данные. В брифе это может быть неизвестный объём работ; в сводке — отсутствующая выгрузка; в документе — неподтверждённый реквизит. Пробел должен становиться заданием на уточнение.

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

Не создавать вторую клиентскую базу

У «Контур-Сервиса» принятый бриф должен сохраняться в действующей карточке обращения. Личное окно помощника может быть интерфейсом, но не единственным местом хранения. Иначе следующий сотрудник не увидит оснований, а история распадётся.

Для результата сохраняйте идентификатор записи, версию входа, дату и статус приёмки. При изменении исходного документа прежнее утверждение может устареть. Система должна показать это явно, а не продолжать использовать старую версию как принятую.

Проверить обновление и удаление

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

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

Проверочный пакет владельца данных

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

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

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