Проверить, работает ли агент по вашей базе знаний или ему просто вложили текст регламентов внутрь инструкции, можно за час и без программиста. Достаточно пяти действий: спросить про то, чего в документах нет; потребовать ссылку на источник; поменять один пункт регламента и посмотреть на срок; открыть журнал обращения; задать вопрос по документу, который вы добавили сами полчаса назад. Ни одна из проверок не оценивает качество ответов — все пять выясняют, откуда ответ взялся.
Разница между двумя архитектурами выглядит одинаково на демонстрации и совершенно по-разному в эксплуатации. Настоящий поиск по базе — это отдельное хранилище документов, которое ведёт ваш сотрудник: правка одного пункта стоит 367 ₽ и попадает в ответы в тот же день. Текст внутри инструкции — это код подрядчика: та же правка стоит 7 500 ₽, ждёт очереди 3–10 рабочих дней и через год превращает систему в архив прошлогодних цен.
Ниже — чем именно отличаются две архитектуры на уровне наблюдаемого поведения, пять проверок с нормой по каждой и с указанием, что подрядчик обязан показать, разбор журнала обращения, расчёт цены неправильной архитектуры и список документов, которые фиксируются в договоре. Про сам механизм поиска по базе есть отдельный материал — здесь речь только о приёмке.
Чем отличается настоящий поиск от текста в инструкции
В архитектуре с поиском документы лежат в отдельном хранилище, нарезанные на фрагменты. На каждый вопрос система сначала ищет подходящие фрагменты, потом отдаёт их модели вместе с вопросом и просит ответить строго по ним. База при этом живёт отдельно от кода: её правит предметный специалист, изменения вступают в силу после переиндексации, разработчик в цикле не участвует.
В архитектуре с вшитым текстом никакого хранилища нет. Регламенты, прайс и условия доставки лежат в системной инструкции — том куске текста, который отправляется модели на каждом запросе. Пока документов мало, это даже работает: ответы связные, демонстрация проходит гладко. Ломается всё в двух местах. Первое — объём: инструкция упирается в размер запроса, и вместо базы из 80 статей туда влезает десяток. Второе — обновление: любое изменение — это правка кода, то есть заявка подрядчику. Отдельно стоит различать эту подмену и дообучение модели: это третья, ещё более дорогая история, разобранная в материале про дообучение против поиска.
Таблица-сравнение в две колонки «Поиск по базе знаний» и «Текст внутри инструкции», шесть строк. Строки: «Где лежат документы» — «в отдельном хранилище, нарезаны на фрагменты» против «в системной инструкции, внутри кода»; «Кто вносит правку» — «предметный специалист компании» против «разработчик подрядчика»; «Срок правки» — «тот же день» против «3–10 рабочих дней»; «Цена одной правки» — «367 ₽» против «7 500 ₽»; «Вопрос вне базы» — «отказ: этого в документах нет» против «правдоподобный вымысел»; «Потолок объёма» — «тысячи документов» против «примерно десяток статей». Чертёжный стиль, тонкие линии, подписи по-русски.
Пять проверок за один час
Проверки идут по возрастанию убедительности: первые две можно объяснить настройкой, третья и пятая не объясняются ничем. Проводите их подряд и на живой системе, а не на подготовленном стенде.
- 1Проверка 1. Спросите то, чего нет ни в одном документе
Придумайте десять вопросов про заведомо несуществующее: тариф, которого у вас нет, филиал в городе, где вы не работаете, услугу из соседней отрасли. Норма — не меньше девяти отказов из десяти, причём отказ должен звучать как «в базе такого нет», а не как рассуждение общими словами. Система с вшитым текстом почти всегда сочиняет: у неё нет самого механизма, которым можно ничего не найти, поэтому она достраивает ответ по смыслу. Что подрядчик показывает: правило честного отказа и порог отсечения в конфигурации.
- 2Проверка 2. Потребуйте ссылку на источник и откройте его
Задайте двадцать обычных рабочих вопросов и в каждом ответе найдите ссылку на конкретный документ и раздел. Дальше главное: откройте указанный документ и убедитесь, что утверждение действительно там есть. Норма — совпадение в 19 случаях из 20. Ссылка, которая ведёт на общий раздел сайта или на «внутренний регламент» без номера, ссылкой не считается. Что подрядчик показывает: как идентификатор фрагмента попадает в ответ и почему его нельзя подделать инструкцией.
- 3Проверка 3. Поменяйте один пункт регламента
Это решающая проверка. Возьмите любой проверяемый факт — срок возврата, стоимость выезда, режим работы склада в субботу — и поменяйте его в исходном документе. Затем задайте вопрос, ответ на который зависит от этого пункта. Норма — новый ответ в тот же день и без единой строки, написанной разработчиком. Если вам говорят «поставим в очередь» или «выкатим со следующим релизом», базы знаний нет: есть текст в коде. Что подрядчик показывает: кто из ваших сотрудников имеет право на правку и сколько занимает переиндексация.
- 4Проверка 4. Откройте журнал обращения
В записи по любому обращению должны быть видны не только вопрос и ответ, но и то, что система нашла: список фрагментов с идентификаторами и оценками близости, отметка о том, какие из них ушли в модель. Если в журнале ровно две колонки — вопрос и ответ, — вам нечем разбирать ни одну жалобу клиента: причина ошибки останется неизвестной навсегда. Что подрядчик показывает: экспорт журнала за произвольный день в файле, а не скриншот.
- 5Проверка 5. Добавьте свой документ и спросите по нему
Напишите короткий документ — половина страницы, одно новое правило с придуманным, но правдоподобным числом. Положите его в базу сами, своими руками и своим доступом. Через оговорённое время задайте вопрос, ответ на который есть только в этом документе. Проверка закрывает две вещи сразу: что база пополняется вами, а не подрядчиком, и что поиск действительно ходит в хранилище, а не в память модели.
Если приёмку проводит подрядчик и показывает вам результат, проверена не система, а презентация. Просите доступ и проводите проверки сами: на это уходит около часа, а стоимость ошибки измеряется годами эксплуатации не той архитектуры. Подрядчик в этот час нужен только для того, чтобы дать доступы и ответить на вопросы.
Как читать журнал обращения
Журнал — единственное место, где видно устройство системы, а не её поведение. Разбираться в нём заказчику придётся регулярно: любая жалоба вида «бот сказал неправильно» начинается именно здесь. Просите не доступ к красивому интерфейсу, а выгрузку за произвольный день в виде файла — по ней сразу видно, что система записывает, а что нет. По этим же записям потом считается качество поиска: методика замера расписана в материале про оценку качества поиска по базе знаний.
Нарисованный абстрактный экран одной записи журнала, разделённый на шесть горизонтальных зон сверху вниз с подписями слева: «Дата, канал, идентификатор обращения», «Вопрос клиента дословно», «Найдено фрагментов: 8, с идентификаторами и оценками близости», «Отобрано и отправлено модели: 4», «Ответ модели», «Ссылка на источник: документ и раздел». Три средние зоны обведены сплошной рамкой с выноской «без этих трёх строк разобрать ошибку нельзя». Справа от экрана узкий второй экран-призрак всего из двух зон, подписанный «журнал, который показывают чаще всего». Чертёжный стиль, текст обозначен линиями, все подписи по-русски.
| Поле записи | Зачем оно нужно | Что означает его отсутствие |
|---|---|---|
| Найденные фрагменты с оценкой близости | видно, ошибся поиск или инструкция | причина ошибки не устанавливается никогда |
| Разделение «найдено» и «отправлено модели» | поднято 8–10 фрагментов, отдано модели 4–5 лучших | отсечение не настроено или его вообще нет |
| Версия документа на момент ответа | старая жалоба разбирается по действовавшей редакции | спор о прошлом ответе без доказательств |
| Экспорт журнала за произвольный период | история разбора ошибок остаётся у вас | при смене подрядчика журнал остаётся в чужой системе |
Цена архитектуры, которую нельзя обновить
Разница между двумя архитектурами превращается в деньги не в момент сдачи, а на втором-третьем месяце эксплуатации. Модельная компания дальше — служба поддержки на 6 000 обращений в месяц с базой из 80 статей; ставки: старший специалист 1 100 ₽ за час полной стоимости, инженер подрядчика 3 000 ₽ в час.
Двухосевой график за 12 месяцев. Ось X — месяцы, ось Y — рубли в месяц от 0 до 60 000. Первая линия, почти горизонтальная у отметки 2 202 ₽, подписана «база знаний: 6 правок по 367 ₽». Вторая линия начинается у нуля, держится там первые три месяца и затем выходит на полку 47 828 ₽, подписана «промпт: правки не заказывают, ответы устаревают». Вертикальная штриховая отметка на третьем месяце с подписью «квартал без обновления — 207 неверных автоответов». Внизу справа пометка: «цена одного неверного автоответа — примерно 231 ₽». Чертёжный стиль, подписи по-русски.
Важно, что 47 828 ₽ — это не штраф за плохую модель, а стоимость данных, которые перестали соответствовать действительности. Никакая замена модели или донастройка поиска этого не лечит. Величина посчитана подробно в соседнем материале про ведение базы знаний: 207 неверных автоответов в месяц, примерно 231 ₽ каждый с учётом повторных обращений и разборов. Собственно корпоративная база знаний и есть тот актив, который вы принимаете, — а не бот вокруг неё.
Что запросить документами
Пять проверок показывают состояние системы на сегодня. Документы фиксируют, что будет через год и при смене подрядчика. Четыре пункта ниже вписываются в договор до начала работ; после сдачи договориться о них заметно труднее.
- 1Описание базы знаний. Перечень источников, число фрагментов, правило нарезки, список полей метаданных и владелец каждого раздела с вашей стороны. Документ на две-три страницы, который позволяет понять, что именно система знает.
- 2Схема поиска. Где физически лежит хранилище, чем считаются векторы, сколько фрагментов поднимается и сколько уходит модели, есть ли переранжирование и порог отсечения. Здесь же — на каком контуре работает модель, потому что от этого зависит вопрос с персональными данными.
- 3Тестовый набор с метриками и датой замера. Сто рабочих вопросов и тридцать заведомо не покрытых базой, с зафиксированными результатами. Рабочая норма — нужный документ находится в 85–95 % вопросов. Набор нужен не для сдачи, а для того, чтобы через полгода отличить деградацию от ощущения.
- 4Права после окончания договора. Письменно: база знаний, тестовый набор, конфигурация поиска и журналы принадлежат вам, выгружаются в открытом формате и передаются по первому требованию. Порядок передачи и приёмки этапов мы описываем отдельно — в разделе о том, как устроена работа.
Когда эта проверка не нужна
Есть три ситуации, в которых текст внутри инструкции — нормальное инженерное решение, и требовать поиска по базе не надо.
- Документов действительно мало и они не меняются. Пять-семь коротких правил, которые правятся раз в год, спокойно живут в инструкции. Хранилище, индексация и переиндексация здесь добавят 80 000–150 000 ₽ к проекту и не дадут ничего.
- Задача не про факты, а про форму. Классификация обращений, определение тональности, переформулирование текста — здесь базы знаний нет по смыслу задачи, и спрашивать про ссылки на источник бессмысленно.
- Пилот на две-три недели, чтобы понять, взлетит ли. На этапе проверки гипотезы вшитый текст — законный способ сэкономить. Важно, чтобы это было названо вслух и записано, а пилотная сборка не переехала в эксплуатацию под видом готовой системы.
Во всех остальных случаях час на пять проверок — самая дешёвая работа во всём проекте. Она не требует технических знаний, проводится на живой системе и даёт ответ на единственный вопрос, который потом определит стоимость владения: сможет ли ваш сотрудник поменять правило сам или для этого всегда будет нужен чужой разработчик.
