Как мы пришли к Sensei

Команда из четырёх человек и около 200 статей

Я работаю в Upline — компании, где есть отдел технической поддержки из четырёх человек. Ребята сильны в коммуникациях с клиентами, но в продукте они разбираются не на уровне разработчиков, и это нормально: их работа — другая. При этом техподдержка у нас работает круглосуточно, а разработчики — нет. В смене обычно один человек, и большую часть суток он остаётся со своими вопросами наедине: спросить буквально не у кого, особенно ночью и в выходные. Единственный коллега, который всегда «на месте» — это документация. Чтобы она реально могла такого коллегу заменять, у нас постепенно собиралась база: разные кейсы, ситуации, частные настройки, обходные пути. Первые сто-полтораста статей за год написал руководитель техподдержки — это был тот изначальный фундамент, на котором всё строилось. Дальше я подключился сам: в конце 2025-го и начале 2026 года я дописал ещё не меньше полсотни и заодно перенёс всю эту базу с Google Docs на Yandex Wiki. Так и получилось около двухсот статей — это тот объём, с которого, собственно, начинается интересная часть истории.

Двести статей — это не много и не мало. Это ровно тот объём, который уже невозможно держать в голове, но ещё не превратился во что-то, что хочется называть «корпоративной базой знаний». Скорее — справочник. Главное про него: им должен пользоваться человек, у которого в этот момент в чате клиент с вопросом.

От двух Word-файлов к Yandex Wiki

Сначала вся документация жила в виде двух Word-документов на Google Drive. Это работало, но у такого решения был один очень тихий и очень неприятный дефект: документ можно случайно отредактировать и не заметить. Кто-то открывает, чтобы прочитать раздел, цепляет курсором заголовок, набирает половину предложения, закрывает вкладку — и в инструкции теперь половина абзаца про другое. История изменений в Google Docs, конечно, есть, и пару раз именно она нас и выручала: заходили, отматывали назад. Но чтобы ей воспользоваться, надо сначала понять, что текст битый. А понимаешь ты это обычно постфактум — либо сам глазами зацепился за странное, либо клиент уже сделал что-то не то по нашей же инструкции и пришёл с этим в чат. В критический момент ты опираешься на текст, которому уже нельзя доверять, — и узнаёшь об этом, когда поздно.

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

Поэтому документацию решили перенести в Yandex Wiki. На бумаге всё стало правильно: версии, история правок, права, нормальная структура. Перенос лёг на меня — я взял два исходных Word-документа, разнёс по отдельным статьям, дописал то, чего раньше не хватало, и в итоге довёл базу до тех самых двух сотен.

Параллельно мы сразу выбрали политику: одна статья — один случай. Не «большая инструкция про печать», а «принтер не печатает после смены драйвера на Windows 11». Не «настройка интеграции», а «ошибка 403 при обмене с конкретной системой». Так удобнее ссылаться, удобнее обновлять, удобнее поддерживать актуальность. И, главное, проще искать — если есть чем искать.

Структура победила, навигация — нет

Wiki компании устроена так: на одном домене живёт много проектов, и сами проекты разделены на два больших узла. Документация для техподдержки оказалась примерно на пятом уровне вложенности в одном узле. Документация по продукту — тоже примерно на пятом уровне, но в другом. Внутри каждого узла — разделы, подразделы, группы статей. Снаружи смотрится прилично. Изнутри — ад.

Поясню, что это значит для человека, у которого в чате клиент ждёт ответа. Чтобы найти решение, нужно пройти пять-шесть кликов вглубь дерева, попасть в правильную ветку, прочитать заголовки, понять, что ты в неправильной, вернуться на уровень выше, попробовать соседнюю. И всё это пока в чате висит непрочитанное «ну что там?». Заголовки старались делать понятными, но между «принтер не печатает» и «ошибка очереди печати» на глаз разницы нет. Открываешь — оказалось не то. Минута. Ещё одна. Ещё.

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

Идея: пусть ищет машина

В этот момент стало очевидно, какое решение нужно. Не «давайте перепишем wiki». Не «давайте плоскую структуру». Не «давайте обучим команду шорткатам». А — пусть ищет машина. Запрос человеческим языком, на выходе ссылки на статьи, релевантные именно этому вопросу.

И ещё одну вещь я тогда для себя проговорил, важную для тона всего, что было дальше. Это решение в первую очередь нужно не тому, кто может крикнуть через стол: «коллеги, кто помнит, как мы это закрывали?». Оно нужно тому, у кого через стол сидеть некому, — ночная смена, выходные, один человек на линии. Документация для одиночки — это не справочник, это коллега, которого нет рядом. И функцию коллеги она должна выполнять не только тем, что ответ в ней лежит, но и тем, что до ответа можно дойти на скорости разговора, а не на скорости пролистывания дерева кликов. Машинный поиск, который умеет читать живой человеческий вопрос, — это и есть способ собрать такого коллегу из текста.

К этому моменту я уже неплохо понимал, что современный поиск по тексту — это не только индекс по словам. Семантический поиск по эмбеддингам, ранжирование, перезапись запроса — всё это даёт результаты, которые на двести статей просто работают. И, что важно, такой поиск не требует от пользователя угадывать правильные ключевые слова. «Не печатает после обновления винды» и «ошибка драйвера принтера в Windows 11» — для машины один запрос.

Я начал собирать систему 26 января 2026 года. Через две недели, 6 февраля, бот заработал у команды. Парсер Yandex Wiki, индексация в локальную векторную базу, поиск по эмбеддингам, ответ — список релевантных статей с ссылками, без всякой генерации. Канал доступа — Telegram-бот, потому что он у каждого в команде уже открыт. Бота назвали @sensei_data_bot. Бренд приклеился сам собой и потом дал имя всему сервису.

Что накопилось за три месяца

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

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

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

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

Май 2026: всё, что нужно было дотянуть

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

Поиск стал гибридным — семантика плюс лексика, чтобы точные совпадения по словам тоже играли роль. Добавилась перезапись запроса с расшифровкой внутренних сокращений: модели не должны угадывать, что ваше «ТП» означает «техподдержка». Добавился HyDE — приём, когда модель сначала генерирует гипотетический ответ, и поиск идёт уже по нему, а не по короткому исходному вопросу. RRF для слияния выдач из разных режимов. Cross-encoder для финального переранжирования. Резюме — отдельной моделью, обязательно с цитатами в формате «[1] [2]», по которым можно сразу открыть исходник. История обращений — отдельным источником, чтобы рядом с ответом по wiki был ответ по реально решённым кейсам.

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

Параллельный сюжет: wiki выходит на плоскость

Тут стоит сделать оговорку — у этой истории есть параллельная ветка, без которой картина получится однобокой. Где-то в апреле-мае 2026 года я решил структурную проблему руками. Всю документацию для техподдержки я вынес из глубины узла прямо на первый уровень wiki, в обход прежней иерархии. Подразделы, группы, аккуратные деревья — всё это перестало быть преградой между человеком и нужной статьёй. Удобнее стало в тысячу раз: открыл wiki, увидел список, кликнул.

Это любопытный момент. Если бы у меня к тому времени не было бота, я бы, наверное, сказал, что задача в принципе закрыта — выровняли wiki, и хватит. Но бот к тому времени уже был, им пользовались, и было видно, что плоский список — это удобно, а резюме с цитатами по двум источникам (wiki плюс история обращений) — это другой класс удобства. Один из них убирает навигацию, второй убирает чтение. Они работают на разных уровнях и не отменяют друг друга.

Что действительно изменилось — это моё внутреннее ощущение задачи. Пока вся история про «команде неудобно искать в wiki», я делал внутренний инструмент. Когда оказалось, что у команды теперь есть и плоская wiki, и бот с резюме, я понял, что построил что-то более универсальное — и подходит оно не только нам. Примерно тогда же я начал серьёзно думать о вебе. Не как о замене Telegram-бота, а как о форме, в которой Sensei может работать где угодно, не только в одной конкретной команде.

Июнь: блокировки Telegram и переезд в веб

А дальше всё ускорилось внешними событиями. Летом 2026 года Telegram в России начал стабильно блокироваться, и без VPN он переставал работать. Это уже само по себе плохо, но в нашем конкретном случае оказалось особенно неудобно. К клиентам мы подключаемся через целый зоопарк инструментов: Контур.Доступ, AnyDesk, RustDesk, RuDesktop, VNC, Windows RDP и ещё несколько узкоспециализированных каналов. Часть из них поднимается прямо так, часть — только поверх корпоративного VPN клиента. В сумме это означает, что собственный VPN-обход блокировок Telegram постоянно конфликтует то с одним инструментом, то с другим: где-то его нужно выключить, чтобы вообще подключиться, где-то — переключить на профиль клиента, где-то — оставить включённым, но молиться, чтобы маршруты не схлестнулись. Каждый день по нескольку раз: «включи VPN — выключи — переключи на клиентский — включи обратно». А клиент всё это время ждёт в чате.

Бороться с этим точечно я не стал — было видно, что проблема системная и долго не закончится. Стало ясно, что канал доступа должен быть веб. Веб не зависит от приложения, которое могут заблокировать или ограничить. Веб не требует ставить и держать что-то на устройстве. У веба понятная адресная строка, и его не путают с мессенджером.

8 июня 2026 года я переключил сервис на веб. К концу июня сервис получил собственное имя — Sensei — и собственный домен. У команды появилась нормальная страница чата в браузере, история запросов, отзывы на ответы, статистика.

Telegram-бот после переезда формально продолжил работать, и какое-то время его ещё открывали по привычке. Новый бэк я делал уже для веба, а бот остался на старом стенде — и тут отдельным сюжетом подтянулась всё та же VPN-история. Бот синхронизирует wiki через куки браузерной сессии Yandex. Первые пару месяцев это была забытая ручка: куки выставил один раз, и они просто жили, ничего не требовали. Когда блокировки Telegram заставили постоянно дёргать VPN туда-сюда, куки начали протухать — сначала редко, потом почти ежедневно. Какое-то время я переутверждал их вручную примерно раз в неделю, но это очевидно дорога в одну сторону: пока я обновляю куки руками, бот продолжает отвечать на полусвежей базе; перестал обновлять — база замораживается. Последний раз я обновлял куки в начале июня. На момент, когда я пишу этот текст, я уже не дёргаю их вообще и готовлю в боте прощальное сообщение — что бот закрывается и нужно переходить на веб. История с Telegram как каналом доступа на этом закрывается.

Почему домашний ПК

И отдельная страница этой истории — про железо. Когда я начинал, у меня не было ни бюджета на серверы с GPU, ни желания тратить деньги на то, что ещё неизвестно, окупится ли. Зато у меня дома стоял компьютер с RTX 3080 Ti и 80 ГБ оперативной памяти — изначально собранный совершенно для других задач. Этого оказалось достаточно, чтобы развернуть локально семёрку Qwen для генерации ответов, BGE-M3 для эмбеддингов и BGE-Reranker для финального переранжирования. Всё под управлением LM Studio, которая закрывает OpenAI-совместимый API и не требует никакой ML-инженерии для запуска.

Этот компьютер до сих пор обслуживает Sensei. Веб-часть живёт на нормальном сервере, а вся «тяжёлая» AI-часть — на домашней машине, к которой веб подключается по защищённому каналу. Когда нагрузка вырастет — это вопрос покупки железа, не переписывания архитектуры.

Я считаю это важной деталью. Истории про AI-сервисы обычно начинаются со слов «мы подняли кластер на сотне H100». В нашей это начиналось со слов «у меня дома есть подходящая видеокарта». Между этими двумя крайностями — большое пространство для команды, которой нужно решить свою конкретную задачу, а не закрыть бюджет на инфраструктуру.

Что дальше

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

История могла закончиться на этапе «у нас неудобная wiki» — и команда годами теряла бы по полчаса в день на навигацию. На «у нас есть Telegram-бот» — пока его не заблокировали. На «у нас есть веб-сервис для своей команды» — что тоже было бы рабочим финалом. Но мне кажется, что у задачи «быстро найти ответ в большой документации» есть универсальная форма, и я надеюсь, что Sensei станет одной из её рабочих реализаций.