Менеджер спрашивает корпоративного помощника, сколько стоит обслуживание оборудования. Тот находит свежий прайс, приводит ссылку и уверенно называет сумму. Через час выясняется: прайс вступает в силу только со следующего месяца. Сегодня клиенту нужно предложить прежние условия.
Это учебный пример, но ошибка вполне конкретная: система перепутала момент получения документа с периодом действия правила. Поиск сработал, цитата существовала, модель ничего не выдумала. Ответ всё равно оказался неверным.
У корпоративных знаний несколько часов. Один показывает, когда правило действует для бизнеса. Другой – когда компания узнала о нём и внесла его в систему. Третий – когда поисковый индекс успел обновиться. Если свести их к одному полю «дата», даже аккуратно настроенный ИИ будет иногда отвечать из неподходящего прошлого или ещё не наступившего будущего.
Разберём, как учитывать время в поиске по корпоративным документам и проверять не только наличие источника, но и его применимость к вопросу.
Почему нельзя выбирать только самый новый документ
Представим сервисную компанию с тремя файлами: действующий прайс, утверждённый прайс следующего месяца и архивный прайс, который бухгалтерия вчера повторно загрузила после исправления скана. Если сортировать по времени загрузки, победит архив. Если по дате утверждения – могут победить будущие условия.
Названия тоже не спасают. «Прайс окончательный» бывает рабочим черновиком, а действующее приложение может называться коротким номером. Дата изменения файла отражает работу редактора, сканера или системы обмена, а не обязательно решение бизнеса.
Дополнительная сложность: старый документ может оставаться правильным для конкретного договора. Новые условия применяются к новым заказам, прежние продолжают действовать для ранее заключённых соглашений. Поэтому вопрос состоит не в том, какой файл новее, а в том, какое правило относится к нужному объекту и моменту.
Разведите время действия и время знания
Для каждой версии существенного правила полезно фиксировать два независимых интервала. Первый – когда правило считается действующим. Второй – когда эта версия сведений присутствовала в системе как известная ей информация. Такое разделение позволяет разбирать исправления, внесённые задним числом.
Допустим, пятого мая компания получила уточнение: для одного клиента специальная ставка действует с первого мая. На вопрос «какая ставка применима ко второму мая?» после уточнения нужен один ответ. На вопрос «на основании чего помощник ответил второго мая?» требуется состояние знаний, доступное тогда.
Системная история базы сама по себе не описывает бизнес-период. Например, документация SQL Server объясняет, что системные временные таблицы сохраняют версии строк, а начало периода связано со временем начала транзакции. Это история изменений данных в системе; дату вступления коммерческого правила в силу необходимо моделировать отдельно.
Время индексации храните как технический показатель доставки знаний. Оно помогает обнаружить задержку обновления, но не должно назначать документу бизнес-значимость.
Начните с паспорта правила
Необязательно переделывать весь архив. Выберите одну группу сведений, на которых ошибка дорого обходится: тарифы, условия доставки, регламенты обслуживания. Для неё заведите небольшой реестр версий. В нём должны быть понятны предмет правила, источник, область применения, период действия и статус утверждения.
Один документ может содержать несколько правил с разными сроками. Например, основной порядок запускается первого числа, а исключение для регионального склада – пятнадцатого. Хранить единственную дату у всего файла удобно, но этого недостаточно. В таком случае версионируется отдельное положение, связанное с исходным документом и его страницей.
Отделяйте статусы «черновик», «утверждён», «отозван» от календарных дат. Утверждённый документ может пока не действовать. Отозванный – оставаться нужным для исторического разбора. Пустая дата окончания также требует объяснения: правило бессрочное, дата неизвестна или данные ещё не проверены? Это разные состояния.
Назначьте владельца реестра со стороны бизнеса. Инженер может извлечь дату из текста, но определить, к каким заказам она относится, должен ответственный за процесс.
Договоритесь о границах периода
Фразы «до первого июня» и «по первое июня включительно» нельзя считать одинаковыми. Ошибка на границе способна на сутки отключить скидку или одновременно применить два тарифа. Правило должно однозначно отвечать, включён ли последний день и в каком часовом поясе наступает следующий.
Практичный вариант внутреннего представления – включать начало периода и исключать конец. Тогда условие, действующее весь май, заканчивается в момент начала июня. Это рекомендация для модели данных; формулировку исходного документа всё равно нужно правильно интерпретировать и сохранить.
В PostgreSQL есть типы диапазонов дат и времени, проверка принадлежности диапазону и явные включённые или исключённые границы. Для календарных диапазонов предусмотрена каноническая форма с включённым началом и исключённым концом. Эти механизмы помогают выразить правила точно, но не выбирают бизнес-смысл за разработчика.
Для события с точным временем сохраняйте часовой пояс или смещение. RFC 3339 описывает формат временных отметок с указанием отношения к UTC. Календарную дату без времени не превращайте автоматически в полночь сервера: сначала выясните, какого региона касается правило.
Уточните дату для выбора правила
Пользователь пишет: «Какой у нас срок возврата?» Для обычной справки можно принять текущую дату, если такой режим заранее определён. Но при разборе старого заказа требуется дата покупки или иное событие, с которым бизнес связывает условия. Угадывать её по времени сообщения нельзя.
Полезно различать три режима: действующие условия, условия на выбранную дату и восстановление прежнего состояния знаний. Последний нужен для аудита: он объясняет тогдашнее поведение, не выдавая прошлую ошибку за правильное правило сегодня.
Если существенный момент отсутствует, задайте конкретный вопрос: «Речь о новом заказе или о заказе, оформленном ранее?» Сведения из карточки заказа можно подставить автоматически, но покажите выбранную дату в ответе. Пользователь должен заметить ошибочную привязку до отправки предложения клиенту.
Исторический вопрос не отменяет текущие права доступа. Сотрудник не получает доступ к закрытому договору только потому, что спрашивает о прошлом году.
Фильтруйте применимость до подготовки ответа
В поиске с дополнением ответа найденными документами, или RAG, легко отдать модели несколько похожих фрагментов и попросить выбрать актуальный. Проблема возникает, когда необходимые сведения о сроках вообще не попали в найденный отрывок. Соседняя страница могла содержать дату начала действия или исключение.
Поэтому временные признаки должны сопровождать каждый фрагмент как структурированные данные. При изменении паспорта правила обновляется привязка всех его частей. Индекс не должен содержать фрагмент новой версии с метаданными старой.
Сначала ограничьте поиск доступными и применимыми версиями для выбранного объекта и момента. Затем оценивайте смысловую близость вопроса. Если используемый поисковый движок требует другого порядка обработки, обеспечьте эквивалентную проверку до передачи материала модели и контролируйте, что нужные кандидаты не потерялись при отсечении выдачи.
Модель формулирует объяснение на основе выбранных оснований. Она не должна тайно расширять период действия или превращать высокую похожесть текста в разрешение использовать неподходящее правило.
Не заставляйте модель мирить конфликтующие версии
Допустим, два утверждённых положения одновременно назначают разные сроки одной операции. У обоих подходящие даты, и оба относятся к нужному подразделению. Выбор наиболее свежего файла выглядит естественно, но может быть неверным: один документ описывает специальный случай, другой – общую процедуру.
Приоритеты задаются явно. Например, индивидуальные условия проверяются раньше типового предложения, если бизнес утвердил именно такой порядок. Сам по себе ярлык «индивидуальный» не делает документ главным во всех ситуациях. В реестре нужна связь: какое положение изменено, для какой области и на каком основании.
Если заданного порядка недостаточно, результат поиска должен содержать конфликт. Ответ человеку: «Для этого заказа найдены два применимых срока; требуется уточнение ответственного». Добавьте ссылки и различие условий, чтобы сотруднику не пришлось начинать расследование заново.
Проверку пересекающихся периодов полезно запускать при загрузке. Но запрет всех пересечений слишком груб: общие и специальные правила иногда законно сосуществуют. Проверять нужно сочетание предмета, области применения и утверждённого приоритета.
Обновляйте знания как согласованный набор
У нового регламента могут быть основной текст, приложения и таблица исключений. Если загрузить их по очереди в действующий индекс, пользователи временно получат смесь редакций. Поэтому сначала подготовьте весь набор, проверьте связи, а затем переключите опубликованную версию.
У набора должен быть идентификатор, который сохраняется в журнале ответа. Тогда можно понять, какие именно знания использовала система. Одной ссылки на изменяемую страницу недостаточно: завтра по тому же адресу окажется другой текст.
Отдельно обработайте отзыв документа. Удалить исходный файл мало: его фрагменты могли остаться в индексе, а готовые ответы – в кэше. Событие отзыва должно обновлять доступность оснований во всех этих местах. До завершения обновления для затронутой темы разумно ограничить автоматическую выдачу подтверждённых условий.
Кэш ответа связывайте с применимыми версиями и временем вопроса. Если старое объяснение разрешено показывать как архивное, явно обозначайте этот режим. Не продлевайте актуальность ответа только потому, что его недавно читали.
Проверяйте состояние непосредственно перед действием
Поиск отвечает на вопрос о правилах, но не всегда отражает текущее состояние операции. В документе сказано, что заказ можно отменить до отгрузки. Это не доказывает, что конкретный заказ ещё не отгружен: его статус может меняться каждую минуту.
Поэтому отделяйте устойчивые правила от оперативных данных. Порядок отмены берётся из применимой редакции регламента, статус – из системы учёта. В ответе полезно указать время проверки статуса, особенно если человек продолжает разговор после длительной паузы.
Перед фактическим действием повторно проверяйте значимые условия. Если между объяснением и подтверждением началась отгрузка, прежнее предложение отмены больше не подходит. Финальную возможность операции должен определять ответственный сервис с актуальным состоянием, а не память диалога.
При недоступности системы учёта помощник может объяснить порядок, но не подтверждать, что конкретная операция сейчас разрешена. Это понятная граница между справкой и исполнением.
Проверьте систему на смене условий
Для первого испытания достаточно небольшого набора учебных документов. Создайте действующее правило, будущую редакцию, архивную копию и специальное условие для одного договора. Все названия и суммы сделайте вымышленными, чтобы тестовые сведения случайно не приняли за рабочие.
Проверьте вопрос за минуту до смены условий и сразу после неё. Затем загрузите старый документ позже нового: результат не должен измениться только из-за свежего времени загрузки. Добавьте задним числом уточнение и сравните ответ о действующих тогда условиях с восстановлением прежнего состояния знаний.
Следующие испытания – документ без проверенной даты, конфликт двух правил, отозванное приложение, задержка индекса и длительная пауза перед действием. Для каждого заранее запишите ожидаемый источник, период и поведение при недостатке сведений.
Измеряйте долю ответов с правильной применимостью, а не только с корректной цитатой. Отдельно учитывайте случаи, когда система должна была запросить дату или показать конфликт. Общая оценка «ответ похож на эталон» может пропустить именно временную ошибку.
Покажите пользователю дату применимости ответа
Ссылка на источник полезна, но рядом с ней нужны понятные временные признаки. Например: «Для заказов, оформленных с первого июня, срок составляет три рабочих дня. Проверена редакция регламента, действующая на дату вашего заказа». Такая формулировка помогает сотруднику обнаружить неверно выбранный заказ, даже если он не открывает документ.
Не перегружайте обычный ответ всей технической историей. Время загрузки, номер опубликованного набора и состояние индекса нужны в подробностях или журнале. На первом плане оставьте условия применимости и событие, по которому они выбраны. В исторической справке прямо пишите, что речь идёт о прошлом периоде.
Если дата неизвестна, не прячьте это за уверенным тоном. Фраза «В найденном положении дата начала действия не подтверждена» объясняет ограничение лучше, чем универсальное предупреждение о возможной неточности ИИ. Следом укажите конкретный способ проверки: кто отвечает за положение и какой недостающий реквизит нужен.
Полезно согласовать несколько шаблонов ответа с сотрудниками, которые ежедневно работают с клиентами. Один шаблон – для действующего правила, другой – для будущего изменения, третий – для конфликта. Проверьте их на простой задаче: может ли человек после чтения понять, какие условия допустимо назвать клиенту сейчас? Если для этого приходится разбирать технический журнал, интерфейс ещё требует доработки.
Как начать без перестройки всего архива
Выберите один вопрос, который регулярно меняет ответ: стоимость услуги, срок обработки, условие отмены. Соберите несколько последовательных редакций и попросите владельца процесса объяснить, когда и для каких объектов действовала каждая. Уже на этом этапе часто обнаруживаются неясные границы.
Затем согласуйте паспорт правила, режимы вопроса и небольшой набор проверок. Подключите временные признаки к поиску и выводите в ответе дату применимости вместе с основанием. Только после этого переносите подход на соседние процессы.
У хорошего корпоративного помощника источник отвечает не только на вопрос «откуда взялась эта фраза». Он позволяет установить, почему именно это правило подходило этому заказу в этот момент. Начните с проверки одного знакомого прайса: действует ли самый свежий файл уже сегодня? Этот простой вопрос показывает, насколько ваша база знаний понимает время.
Комментарии