Опечатки и сокращения клиента база знаний разбирает по смыслу сама. Строже всего точный поиск по таблице: что настроить, чтобы артикул нашёлся.
Опечатки, сокращения и слипшиеся слова база знаний Савви разбирает сама: поиск идёт по смыслу фрагмента, и формулировка клиента может расходиться с текстом документа. Ломается другое место — точный поиск по таблице, где артикул и название сверяются буквально. Лечится это параметрами колонки, смысловым поиском по колонке и уточняющим вопросом в инструкции агента.
В переписку падает заявка из четырёх слов, и ни в одном из них нет ни единой гласной на месте: «пдскжте скок стот мнтж». Человек за стойкой прочитает это за секунду и переспросит про площадь. Агент тоже прочитает — вопрос в том, куда он после этого пойдёт за ответом.
Текстовые документы агент ищет по смыслу, поэтому корявая формулировка ему почти не мешает. Руководство платформы Савви описывает базу знаний как инструмент, который фундаментально работает на смысловом понимании контекста: агент находит релевантный фрагмент даже тогда, когда формулировка вопроса отличается от текста в документе.
На практике это значит, что пропущенные буквы, слипшиеся слова, «спс» и «скок» до ответа доходят. Вопрос «как вернуть заказ, если я повредил упаковку» и раздел регламента «Условия возврата товара надлежащего качества» связываются между собой, хотя общих слов у них почти нет. Ровно поэтому регламенты и описания услуг живут в документах: там гибкость встроена в сам механизм поиска. Насколько гибко подбирается фрагмент, задаёт порог срабатывания, и про его значения написано в разборе порогов поиска по базе знаний.
Проверьте на своих диалогах.Регистрация без карты, 500 ₽ на тест по промокоду BLOG500
Собрать агентаСпотыкается агент на таблицах. Данные оттуда достаёт динамический генератор запросов: вопрос клиента превращается в SQL-запрос, и значение колонки сверяется буквально, символ в символ.
Для такого поиска «айфон 15про», «iPhone 15 Pro» и «айфон15про» — три разные строки, и совпадёт из них та, что записана в прайсе. То же с артикулами: клиент переставил два знака местами, и запрос возвращает пусто. Заметно это не сразу, потому что выглядит поломка прилично — агент вежливо отвечает, что такой позиции нет. Про устройство самих таблиц и требования к файлу написано в материале про цены и остатки из вашего файла, здесь важна одна вещь: точность спроса определяется тем, как заполнена колонка, а не тем, насколько умная модель стоит в агенте.
Настраивается это в самой таблице, по каждой колонке отдельно, и занимает минуту.
| Параметр колонки | Что меняется в поиске |
|---|---|
| Поиск по части строки | строка находится по фрагменту текста из колонки, а не по целому значению |
| Не учитывать регистр | «АЙФОН», «айфон» и «Айфон» перестают быть разными значениями |
| Всегда строка | числовые коды и артикулы обрабатываются как текст и не теряют ведущие нули |
Первые два параметра закрывают самый частый бытовой случай: клиент написал два слова из пяти и не в том регистре. Третий нужен там, где артикул состоит из цифр: без него код вида 0074 легко превращается в число 74 и не находится.
Когда клиент называет услугу вообще своими словами, буквальное сравнение выручает уже плохо. На этот случай есть смысловой поиск по колонке — функция VECTOR_SEARCH с порогом точности от 0 до 1. Руководство рекомендует держаться в диапазоне 0.5–0.8: на поиске по модели автомобиля ставят 0.8, чтобы не перепутать соседние модификации, на поиске по названию услуги — 0.6, чтобы подтянулись близкие варианты.
Руководство платформы предупреждает прямо: такой поиск не является быстрым, и если его можно заменить типовым поиском SQL, это надо всегда делать. Отсюда рабочий порядок: смысловой поиск вешают на одну колонку, где формулировки свободные, — название услуги, тема вопроса. Модель, артикул и код остаются на обычном поиске по маске, а недостающую точность добирают уточняющим вопросом к клиенту.
Самый надёжный приём против кривых формулировок живёт в инструкции агента: перед обращением к таблице агент обязан уточнить недостающие признаки. В руководстве этот порядок показан прямым текстом — сначала «уточни у клиента наименование материала и цвет», и только потом вызов функции таблицы.
Уточнение превращает обрывок в запрос, и настройки поиска после этого нужны куда реже. «Скок стот мнтж» само по себе не ищется нигде; «монтаж натяжного потолка, 18 квадратов» находится с первого раза. Формулировать уточнение стоит вариантами: агент называет две-три позиции из каталога и просит выбрать, тогда клиент отвечает вашим словом из прайса, а не своим.
Третий шаг важнее, чем кажется: без него пустая выдача из таблицы выглядит для модели как отсутствие данных, а дальше она склонна заполнить пробел сама. Как это выглядит в диалоге и чем ещё лечится, описано в разборе выдумок ИИ-агента.
Кнопка «Найти кириллицу» в разделе «Служебное» к опечаткам клиента отношения не имеет, хотя название наводит на эту мысль.
Она решает другую задачу. Агент работает на иностранном языке, инструкция и база знаний переведены целиком, и при этом он случайным образом переходит на русский. Одна из причин — кириллические буквы, оставшиеся в тексте инструкции после перевода: пара русских слов в служебном комментарии, и модель периодически сбивается на русский. Кнопка находит эти буквы, чтобы их удалить. Для русскоязычного агента она бесполезна.
Напишите своему агенту в тестовом чате три сообщения подряд так, как их пишет живой клиент: с проглоченными гласными, строчными буквами и перепутанными знаками в артикуле. Одно сообщение про условия и регламент, второе про цену конкретной позиции, третье с опечаткой в названии модели.
Дальше смотрите, где именно случился промах. Вопрос про регламент ушёл в документы и вернулся ответом — значит, эта часть работает без вашего участия. Вопрос про цену вернулся пустым — открывайте параметры колонки и инструкцию перед вызовом функции. Полный перечень настроек колонок и формат запроса со смысловым поиском лежат в руководстве платформы, а правила, по которым пишется уточняющий шаг, собраны в семи правилах инструкции для агента.
Да, если ответ лежит в базе знаний. Поиск по документам работает на смысловом понимании контекста: агент находит нужный фрагмент, даже если формулировка вопроса отличается от текста в документе. Пропущенные буквы, слипшиеся слова и бытовые сокращения такой поиск обычно переживает без настройки.
Потому что товары и цены чаще всего лежат в таблице, а поиск по таблице идёт через SQL-запрос и сверяет значение колонки буквально. «Айфон 15 про» и «iPhone 15 Pro» для такого поиска — разные строки. Помогают параметры колонки «Поиск по части строки» и «Не учитывать регистр», а для совсем свободных формулировок — смысловой поиск.
Это функция смыслового поиска по колонке таблицы формата VECTOR_SEARCH(ИмяКолонки, ПоисковыйЗапрос) с порогом точности от 0 до 1. Руководство платформы Савви рекомендует значения от 0.5 до 0.8: 0.8 для строгого поиска по модели, 0.6 для поиска по названию услуги. Включать стоит там, где клиент называет услугу своими словами.
Руководство предупреждает прямо: такой поиск не является быстрым, и если его можно заменить типовым поиском SQL, это надо всегда делать. Практический вывод простой: там, где у агента есть возможность спросить у клиента точное название или артикул, выгоднее спросить и искать по маске.
Правило пишется в инструкции перед вызовом функции таблицы: сначала уточнить у клиента наименование и второй признак вроде цвета или модели, и только затем вызвать функцию. В настройках вызова таблицы есть флаг возврата ошибки, если ничего не найдено — тогда агент видит пустой результат и может задать вопрос, а не придумать ответ.
Она нужна агенту, который работает на иностранном языке, имеет полностью переведённую инструкцию и базу знаний, но случайным образом переходит на русский. Одна из причин этого — оставшиеся в инструкции кириллические буквы, кнопка в разделе «Служебное» их находит для удаления. К опечаткам в сообщениях клиента эта кнопка отношения не имеет.