Привет! 
Я AI-ассистент Артёма.
Чем могу помочь?
Спросите меня
Думаю...
Задумывался «чат с ботом про поступление в Австрию». Оказался продуктом с памятью о пользователе, голосовым режимом, автоматическим парсером знаний и гибридным поиском — и всё это спроектировал и написал один человек. Этот кейс — о решениях на каждом слое: от характера компаньона до архитектуры поиска.
Дальше — как это устроено, включая самый неудобный вопрос, который мне задала собственная команда.
В 14 лет я разбирался, как поступить в европейский университет. Информация существовала — но была рассыпана по тысяче источников: форумы, официальные сайты на немецком, чаты, устаревшие статьи. Визы, экзамены, жильё, банки, документы — каждый вопрос означал десять открытых вкладок и ни одной уверенности, что ответ актуален. Инструмента, который объяснил бы всё по-человечески и на русском, не существовало. Его нет до сих пор.
Relorise — этот инструмент. AI-компаньон для русскоязычных студентов, которые поступают в австрийские университеты: проверенная база знаний по ВНЖ, экзаменам, жилью и документам, персонализация под профиль и цель, живой характер вместо канцелярита. Именно «компаньон», а не «ассистент» — это слово с лендинга, и оно выбрано осознанно: ассистент выполняет поручения, компаньон проходит путь рядом. Я — customer zero этого продукта: каждое решение в нём проверяется вопросом «помогло бы это мне тогда?».
Почему только Австрия и только студенты — это решение, а не ограничение. В марте я разобрал для команды, как устроены большие travel-продукты: один Google Travel раскладывается на пять продуктовых вертикалей с разными источниками данных, командами и метриками. Вывод для нас был жёсткий: продукт, который пытается закрыть «переезд куда угодно кому угодно», не закрывает ничего. Мы выбрали одну проблему и решаем её до дна: студент → Австрия → конкретный ответ под конкретную ситуацию.
Команда — три человека: я в Москве и двое партнёров в Вене — Артём (бизнес и тестирование) и Катерина (контент базы знаний и экспертиза «на месте»). Дизайн, код и AI-архитектуру здесь не с кем было разделить — я один прошёл каждый слой, и строилось всё это в свободное время, параллельно с полной загрузкой на клиентском B2B-проекте. Это не потому что «умею всё лучше всех» — просто не с кем было разделить ответственность, а значит, любое решение в этом кейсе можно спросить с меня, от кривой анимации онбординга до стратегии ранжирования в поиске.
Главный риск таких продуктов — «сервис одного вопроса»: человек спросил про визу, получил ответ и ушёл. Поэтому ядро я определил не как чат, а как хаб из четырёх столпов: AI-чат, чеклисты с прогрессом, контент, комьюнити. И проверял каждую фичу вопросом: даёт ли она причину вернуться?
Как это выглядит вживую. Даша, 19 лет, Алматы, хочет в TU Wien. Первый визит: спрашивает про студенческий ВНЖ — получает конкретный ответ с источником: подача в MA35, нужна страховка и письмо о зачислении. Компаньон замечает, что за вопросом стоит многоэтапный процесс, и предлагает план — Даша соглашается, у неё появляется чеклист с дедлайнами. Через неделю она возвращается: два пункта отмечены, в базе обновилась карточка про общежития OeAD, компаньон помнит про TU Wien и сентябрь — не нужно объяснять заново, — а в событиях на выходных Sprachcafe. Пять причин вернуться в одном заходе: прогресс, обновление контента, память, быстрый ответ, событие. Даша пришла с одним вопросом — осталась с процессом.
Стандартное решение — библиотека готовых чеклистов «как поступить». Я отказался от него: путь школьника из Казахстана и выпускника бакалавриата из Москвы не совпадает ни в одном пункте. Вместо этого — три уровня: системный роадмап генерируется из профиля при онбординге; goal-driven чеклисты пользователь ставит сам; и Chat-to-Plan — компаньон прямо в диалоге замечает, что вопрос пользователя («как сделать Anmeldung?») на самом деле многоэтапный процесс, и предлагает создать план здесь же, не отправляя в отдельный раздел. Технически это скрытый маркер в ответе модели, который приложение превращает в виджет.
Профиль из онбординга — это снимок. Живой контекст накапливается в разговоре: пользователь упомянул, что подаётся в TU Wien в сентябре, — компаньон запоминает это через скрытые маркеры в ответах и учитывает в следующих сессиях. Принципиальное решение — прозрачность: отдельная страница памяти, где пользователь видит и редактирует всё, что о нём известно. Память без контроля пользователя — это слежка; память с контролем — это сервис.
Тот же скрытый протокол маркеров, что стоит за чеклистами и памятью, работает и для третьей вещи: пользователь спросил про перелёт в Вену — рядом с ответом появляется виджет реальных билетов с календарём цен, под него написан отдельный поисковый роут. Не три разных решения, а один паттерн: компаньон замечает повод в диалоге и превращает его в действие, а не только в текст. Интерфейс вырастает из разговора, а не разговор упирается в интерфейс.
У продукта про переезд студента есть скрытый второй пользователь — тревожный родитель, который может заблокировать всё решение. Я разобрал страхи по одному: «это опасно» — закрывается фактами о безопасности, «не справится один» — системой поддержки, «слишком дорого» — калькулятором с точными цифрами и стипендиями. И спроектировал механику: студент делится с родителем кабинетом и сам контролирует, что родитель видит. Это переворачивает роль — из тревожного наблюдателя в участника процесса. Сюда же работает шаринг диалогов по ссылке: сценарий «отправить маме, что мне ответили про ВНЖ» — буквально из жизни аудитории.
Самое важное дизайн-решение в AI-продукте не видно в Figma. Это системный промпт. Я писал его как спецификацию персонажа: «Ты общаешься как друг, который сам через всё это прошёл. Не как робот, не как чиновник, не как учитель. Можешь шутить, иронизировать. Но когда речь о серьёзных вещах — ты точный и чёткий». Мотивация без вранья: не «всё будет отлично», а «это сложно, но вот конкретный план». Этот персонаж — не выдумка и не маркетинговая маска: «друг, который сам через всё прошёл» — это я, разбирающийся в теме с 14 лет. Промпт получился честным, потому что мне не пришлось его придумывать.
Дальше — правила, каждое из которых закрывает конкретную проблему. Три тональности под три аудитории: школьник, студент, родитель читают один факт по-разному. Запрет придумывать URL — ссылки только из источников базы знаний. Дисклеймер «перепроверь на официальном сайте» — только для меняющейся информации, а не после каждого ответа, иначе он перестаёт работать. И пять эталонных сценариев с примерами ответов прямо в промпте — как стайлгайд, только для речи.
Два режима — два разных продукта в одном. Информационный: с базой знаний, источниками и строгими правилами точности. И режим свободного общения — без базы, где компаньон просто разговаривает: сомнения, страхи переезда, немецкий язык, австрийский менталитет. Переезд — это не только документы, и продукт это признаёт.
Голосовой режим — отдельная спецификация речи. В голосе компаньон говорит с живыми интонациями — смех, вздох, задумчивость — через разговорные теги в тексте ответа. В голосе меняется всё: никакого markdown и списков, числа расшифровываются устно — «двести евро», а не «€200», «вид на жительство», а не «ВНЖ». Текстовый и голосовой интерфейс — это разные языки, и писать для них одинаково — ошибка.
Цена ошибки в этом продукте — не «пользователь увидел не тот баннер». Это человек, который принёс не те документы в миграционную службу. Поэтому вся архитектура построена вокруг точности.
Чистый векторный поиск — стандарт для RAG — плохо работает с точными терминами: аббревиатуры вроде ЕПМ или MA35, названия программ, номера параграфов семантически «размыты». Поэтому поиск гибридный: 70% веса — векторное сходство через pgvector, 30% — keyword-ранжирование через полнотекстовый поиск PostgreSQL на русском. Для базы знаний по австрийской бюрократии на русском языке это не оптимизация, а необходимое условие корректности.
Поверх — трёхуровневый каскад: основной поиск по чанкам карточек, при нуле результатов — гибридный поиск по целым карточкам, при ошибке — простой keyword-фолбэк. Пользователь не должен получать «ничего не найдено» из-за сбоя одного уровня.
А дальше — три уточнения, которые превращают рабочий каскад в точный. Из длинных карточек в контекст модели попадает не вся карточка, а релевантный фрагмент плюс соседние — точность без раздувания контекста. Профиль пользователя (аудитория, цель) фильтрует выборку ещё до векторного сравнения. Финальный слой — реранкинг результатов через Cohere Rerank.
На тестах Артём поймал компаньона на вранье и написал в чат: «Он выдал аренду 1050+, хотя в карточке правильно ~700+, и посчитал, что 4К хватит на 3–4 месяца». Уверенный неверный расчёт бюджета — худший тип ошибки для этого продукта: пользователь примет по нему решение. Этот класс ошибок я закрываю архитектурно: над сложными ответами работают две модели — одна генерирует, вторая валидирует ответ против правил и источников. При этом модели подключены как заменяемый слой: «это операционная система, которую можно заменить на более новую или дешёвую без переписывания продукта» — я перебрал несколько (DeepSeek, Qwen, Gemini, Grok), прежде чем зафиксировать связку.
База знаний пополняется автоматически: ночной парсер собирает контент из Telegram-каналов релокантов и официальных источников, AI извлекает структурированные карточки, а Smart Router решает — дополнить существующую карточку, создать новую или выбросить дубль. Но ключевое решение — в том, чего автоматика делать не может: карточки попадают в статус draft, и в поиск они выходят только после ручной проверки командой в админке. Автоматика экономит время; ответственность за юридическую информацию остаётся на людях.
Вся эта инфраструктура — embeddings, генерация, валидация, реранкинг, ночной парсинг — обходится в 2–3 € в месяц. Архитектурная дисциплина в AI-продукте измеряется не только качеством, но и счётом за API.
В марте Катерина — наш контент-эксперт — спросила в рабочем чате прямо:
«Просто в чём наша бо́льшая ценность, чем ChatGPT, если уже так откровенно говорить?»
Это лучший вопрос за весь проект — и худший момент, чтобы от него отмахнуться. То, что его задаёт человек изнутри команды, а не инвестор на питче, — признак здоровой культуры: мы не продавали идею друг другу.
Мой ответ складывается из того, что универсальная модель не может дать по построению. Проверенная база: каждый факт в Relorise прошёл модерацию, у каждого ответа — источники из карточек, а не «где-то в интернете читал». Актуальность: база из 50+ официальных источников обновляется каждую ночь — ChatGPT не знает, что закон изменился в прошлом месяце. Персонализация: профиль, цель и накопленная память меняют и содержание, и тон ответа. И точные термины: гибридный поиск находит ЕПМ, MA35 и Meldezettel там, где чистая семантика промахивается.
Но честный ответ включает и вторую часть: окончательно этот вопрос закрывается не аргументами, а ретеншеном. Если после запуска пользователи будут возвращаться в Relorise, а не в ChatGPT, — ценность доказана. Если нет — никакая архитектура этого не компенсирует. Я строю продукт так, чтобы выиграть это сравнение, но результат покажут метрики, которых у беты пока нет.
Тот же принцип честности — в работе с багами. Артём и Катерина тестировали и находили: компаньон отвечает слишком широко, галлюцинирует ссылки, недоговаривает — «90% говорит, а остальное как будто не договаривает», думает по 15 секунд после включения реранкинга. Каждая находка превращалась в правило промпта, изменение пайплайна или задачу на оптимизацию — их баг-репорты были фактически моим бэклогом качества.
Когда дизайнер сам пишет реализацию, исчезает граница «макет → хендофф → компромиссы». Всё, что ниже, — спроектировано и написано мной, поэтому детали дошли до продакшена без потерь.
Маскот Relo нарисован мной раньше самого проекта — для другой тревл-идеи. Когда собирали Relorise, я вернул его как основу айдентики с прямым аргументом: наш пользователь не отличается принципиально от пользователя Duolingo, а их маскот работает даже на аудиторию 40+. Персонаж снижает порог доверия к «бюрократической» теме — с ним разговор про ВНЖ ощущается как разговор, а не как приём в ведомстве.
Онбординг собирает ровно то, что нужно для персонализации: кто ты → какая цель → какой таймлайн. Обязателен только таймлайн — минимум трения при максимуме пользы для первого же ответа компаньона. Микродетали сделаны как для большого продукта: список из 180 стран с флагами, где страны СНГ стоят первыми — мелочь, которая раньше любого текста говорит пользователю «это для тебя»; переходы между шагами на spring-кривой, а не линейно; прогресс — SVG-круг «1 из 3»; третий шаг подписан «Обещаю — это правда последнее» — маленькая честность, которая снимает раздражение формой.
Главная — не лента, а рабочее пространство: виджеты чата, событий, целей, роадмапа и авиабилетов в bento-сетке с drag-and-drop и ресайзом за края. Инженерные решения под плавность: перетаскивание тротлится через requestAnimationFrame, квадратность ячеек при любом экране считается через ResizeObserver, раскладка сохраняется локально. Кастомный фон — фото пользователя с настраиваемым блюром, угловым виньетированием через градиентную маску и затемнением, чтобы контент читался на любой картинке. На мобильном — не «ужатый десктоп», а другой лейаут: крупная карточка, решётка навигационных тайлов и закреплённый внизу чат-пилл «Спроси что угодно».
Отдельная часть, которую не видно в интерфейсе: юридический каркас — Impressum, Privacy и Terms на русском и немецком — сделан до запуска, а не «потом добавим». Для продукта на европейскую аудиторию это часть дизайна доверия.
План был — MVP к концу февраля. Потом — релиз в мае. Бета случилась в июне. Три сдвига подряд — это не невезение, это системная ошибка планирования: я оценивал сроки как дизайнер, который представляет интерфейс, — а строил как единственный разработчик, работающий вечерами параллельно с основным проектом. Каждая фича в AI-продукте тянет за собой невидимый хвост: Chat-to-Plan — это не виджет, а протокол маркеров в ответах модели; «память» — это не поле в базе, а страница управления ею. При вечернем ресурсе этот хвост растягивает сроки не линейно, а кратно.
Вывод, который я применяю с тех пор: скоуп для соло-разработки режется до одной проверяемой петли ценности, всё остальное — после первых пользователей. Если бы я начинал Relorise сегодня, бета вышла бы в марте с чатом и базой знаний — а hub, голос и память догоняли бы её по данным реального использования.
К июню 2026 Relorise готов к бета-релизу: чат с двумя режимами и памятью, hub с виджетами, три уровня чеклистов, голосовой режим, шаринг диалогов, ночной парсер с модерацией, юридический пакет на двух языках. Продукт живёт на relorise.com.
Чего здесь нет — метрик. Продукт на пороге беты: ни ретеншена, ни конверсий, ни подтверждения гипотезы против ChatGPT — этих цифр не существует, и я не буду их изображать. Этот кейс — про то, как принимаются решения на всех слоях AI-продукта, когда между идеей и продакшеном нет никого, кроме тебя. Ответ рынка — следующая глава, и я знаю, какими метриками буду её измерять.
В этом проекте не было хендоффа. Каждый раз, когда я принимал дизайн-решение, я же его и реализовывал — и это изменило сами решения. Спорить с разработчиком о том, что «так нельзя», невозможно, когда разработчик — ты: остаётся только честно выяснить, можно или нет, и почём. Гибридный поиск, разговорные теги в голосе, draft-статус у парсера — всё это решения, которые рождаются только на стыке дизайна и реализации, и не рождаются по разные стороны хендоффа.
В ночь перед запуском беты, около часа, я записал голосовое в командный чат. Не про фичи и не про баги — про то, что понял в тот момент: «Ты скоро запускаешь тот самый продукт, который придумал в 14 лет». Шесть лет назад я по крупицам собирал ответы, которых не существовало в одном месте. Теперь это место существует — и следующее, что оно должно доказать, уже не мне.
Привет! Я AI-ассистент Артёма.
Чем могу помочь?