Как Legalka KB использует ИИ: RAG, голос и ноль галлюцинаций

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

Legalka KB — это бесплатный Telegram-бот, который помогает разобраться в релокации в Польшу. В отличие от обычного чат-бота, который на такие вопросы уверенно фантазирует — выдумывает номера счетов, сроки и адреса ужендов, которых не существует, — Legalka KB отвечает строго из верифицированной базы знаний и честно говорит «не знаю», когда ответа в базе нет. В этой статье мы подробно, но доступно разберём, как система устроена внутри: откуда берутся знания, как рождается ответ, что удерживает бот от выдумок и как мы поддерживаем базу в актуальном состоянии. По ходу — все схемы из нашей внутренней документации.

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

Как устроена система целиком

Прежде чем нырять в детали, полезно увидеть карту целиком. Система состоит из четырёх крупных частей: базы знаний, сборщика практики, ассистента с Telegram-ботом и панели управления для куратора.

flowchart TB
  subgraph Sources["Источники сообщества"]
    TG["Чаты и каналы<br/>в Telegram"]
  end
  subgraph Pipeline["Сборщик практики (LangGraph)"]
    direction LR
    ING["приём"] --> THR["сборка диалогов"] --> EXT["извлечение фактов (LLM)"]
    EXT --> PII["фильтр личных данных"] --> CLS["классификация темы"]
    CLS --> DED["дедупликация"] --> STG["подготовка<br/>фактов"]
  end
  subgraph KB["База знаний (сам продукт)"]
    NORM["слой «норма»<br/>(закон, со ссылками)"]
    PRAC["слой «практика»<br/>(сообщество, с датами)"]
  end
  subgraph RAG["Ассистент, отвечающий строго из базы"]
    IDX["индекс"] --> RET["поиск"] --> ANS["ответ<br/>норма/практика + ссылки + абстенция"]
  end
  subgraph Revise["Агент правок (LangGraph)"]
    REV["загрузка → план → правка →<br/>проверка → запись"]
  end
  subgraph Dash["Панель управления (для куратора)"]
    COL["Панель сбора"]
    REVIEW["Ревью и одобрение"]
  end
  TG --> ING
  STG -. "ручное продвижение" .-> PRAC
  Authoring["куратор + официальные источники"] --> NORM
  NORM --> IDX
  PRAC --> IDX
  ANS --> Users["Пользователи RU/UA/BE/PL/EN<br/>(Telegram-бот)"]
  Dash -->|данные| Pipeline
  Dash -->|данные| KB
  Dash -->|данные| RAG
  REVIEW --> REV
  REV --> KB

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

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

flowchart LR
  ROOT["Проект Legalka"]
  ROOT --> KB["База знаний —<br/>страницы со ссылками на источники"]
  ROOT --> PIPE["Сборщик практики<br/>и агент правок"]
  ROOT --> RAGD["Ассистент<br/>и Telegram-бот"]
  ROOT --> DASH["Панель управления"]
  ROOT --> EVAL["Набор проверочных<br/>вопросов"]
  ROOT --> INBOX["Входящие: вопросы<br/>и черновики фактов"]
  ROOT --> DOCS["Документация"]
  ROOT --> CLAUDE["Инструменты команды"]

База знаний: «норма» и «практика»

Сердце системы — сама база знаний, набор структурированных страниц. Знания в ней намеренно разделены на два слоя, которые никогда не смешиваются.

Слой «норма» — то, что требует закон. Каждое утверждение сопровождается ссылкой на источник (по возможности — на конкретную статью), помечается проверенным только после ревью юриста и переобследуется не реже чем раз в 60 дней.

Слой «практика» — как это работает в реальности: сроки, привычки инспекторов, нюансы конкретных ужендов. Это наблюдения заявителей, всегда с оговоркой «по сообщениям заявителей» и обязательной датой, после которой факт считается устаревшим (не позже чем +90 дней).

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

stateDiagram-v2
  state "черновик" as draft
  state "проверено — практика" as vp
  state "проверено — норма" as vn
  [*] --> draft: создаёт куратор
  draft --> draft: правки
  draft --> vp: ревью куратора
  draft --> vn: ревью юриста
  vp --> [*]
  vn --> [*]
  note right of draft
    Правки вносит ИИ или куратор вручную.
    Черновики бот тоже показывает,
    но честно помечает их
    как ещё не проверенные
  end note

Пока страница в статусе черновика, бот всё равно может её показывать, но честно помечает такой ответ как непроверенный — чтобы не терять свежие данные, но и не выдавать их за окончательно проверенные.

Как рождается ответ

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

flowchart TB
  Q["Вопрос пользователя<br/>(текст или голос)"] --> CQ["Переформулирование:<br/>уточняющий вопрос → самостоятельный запрос"]
  CQ --> R["Поиск: ближайшие по смыслу<br/>разделы базы + приоритет воеводства"]
  R --> G{"Оценка релевантности"}
  G -->|"слишком низкое совпадение<br/>или ничего не найдено"| AB["Абстенция:<br/>«не знаю»"]
  G -->|"совпадение уверенно высокое"| A
  G -->|"иначе"| V{"Проверка моделью<br/>по исходному вопросу"}
  V -->|нерелевантно| AB
  V -->|релевантно| A["Ответ<br/>метки норма/практика + ссылки"]
  A --> DIS["+ дисклеймер"]
  AB --> DIS
  DIS --> REC["Запись ответа<br/>(без личных данных)"]
  REC --> FB["👍/👎 привязаны<br/>к этому ответу"]

Разберём по шагам.

Переформулирование. Диалог редко состоит из полных вопросов. «А какие документы?», «для этого», «а там?» — такие реплики бессмысленны для поиска в отрыве от контекста. Поэтому короткие и ссылочные вопросы компактная модель gpt-4o-mini переформулирует в самостоятельный запрос с учётом истории диалога и выбранного воеводства: «а какие документы?» после вопроса про ВНЖ по бизнесу превращается в «документы для zezwolenie na pobyt czasowy i pracę, mazowieckie». Так поиск не теряет нить.

Поиск. Каждая секция каждой страницы базы заранее превращена в вектор моделью text-embedding-3-small и хранится в поисковом индексе. Запрос тоже превращается в вектор, и система ищет ближайшие по смыслу секции по косинусному сходству. Если пользователь выбрал воеводство, его страницы получают приоритет над общими — чтобы конкретика вроде номера счёта или адреса уженда выигрывала у общих страниц.

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

Проверка моделью. Она сверяет ИСХОДНЫЙ вопрос пользователя (а не переформулированный запрос) с найденными фрагментами — потому что переформулирование иногда «уезжает» на прошлую тему и высоко оценивает не ту страницу. Если проверку не удаётся однозначно интерпретировать, система склоняется к тому, чтобы ответить. Бот воздерживается, только если контекст признан нерелевантным.

Генерация. Ответ формирует та же модель gpt-4o-mini — но только из найденных секций, без «знаний из головы». Каждый факт помечается как «норма» (то, что требует закон) или «практика» (наблюдение заявителей, обязательно с датой). Если в контексте есть конкретика — номер счёта, сумма, адрес — бот выдаёт её прямо, а не отсылает «уточните в уженде», и добавляет официальные ссылки для самостоятельной проверки. Отвечает на языке вопроса, переводя факты из русскоязычной базы. В конце — дисклеймер.

Запись и обратная связь. Каждый выданный ответ записывается (с обязательным удалением персональных данных), чтобы позднее 👍 или 👎 привязались именно к тому, что легло в его основу, и пережили перезапуск бота. Голос 👎 автоматически раскладывается на тип — плохой поиск, плохая генерация или пробел в базе — и попадает на панель как сигнал, что чинить в первую очередь.

Что умеет бот для пользователя

Ответ строго из базы — это ядро, но вокруг него выстроен целый набор удобств, чтобы пользоваться ботом было комфортно.

flowchart TB
  subgraph In["Ввод пользователя"]
    T["текстовый вопрос"]
    Vc["голосовое сообщение"]
    Cmd["команды"]
  end
  subgraph Core["Ответ строго из базы"]
    ANSW["ответ + метки норма/практика<br/>+ ссылки + дисклеймер"]
  end
  Vc -->|распознавание речи| T
  T --> ANSW
  ANSW --> Buttons["инлайн-кнопки под ответом"]
  Buttons --> B1["👍 / 👎 обратная связь"]
  Buttons --> B2["🔊 озвучить"]
  Buttons --> B3["✍️ предложить правку"]
  Buttons --> B4["📍 показать на карте<br/>(если польский адрес)"]
  Buttons --> B5["🔔 лист ожидания по региону"]
  Buttons --> B6["📋 создать чек-лист"]
  Cmd --> C1["/topics — обзор разделов базы"]
  Cmd --> C2["/checklist — личные списки"]
  Cmd --> C3["/region — воеводство"]
  Cmd --> C4["/lang — язык интерфейса и ответов"]
  Cmd --> C5["/new, /chats, /reset —<br/>память по чатам"]

Голос в обе стороны. Вопрос можно не печатать, а надиктовать: голосовое сообщение распознаёт модель whisper-1 с языковым хинтом, бот эхом показывает распознанный текст и обрабатывает его как обычный вопрос. Работает и обратное направление: под каждым ответом есть кнопка «Прочитать вслух» — текст очищается от лишнего и озвучивается моделью tts-1.

Кнопки под ответом. 👍/👎 — обратная связь; 🔊 — озвучить; ✍️ — предложить правку (уходит в очередь предложений); 📍 — показать на карте, если в ответе есть польский адрес; 🔔 — встать в лист ожидания, если по вашему воеводству ещё нет локальной практики; 📋 — создать чек-лист, если ответ перечисляет пункты.

Команды. /topics — обзор разделов базы с примерами вопросов; /checklist и /checklists — личные редактируемые списки (например, «Я» и «Жена»); /region — выбор воеводства; /lang — язык интерфейса и ответов; /new, /chats, /reset и другие — память по нескольким параллельным чатам.

Отдельно про языки: интерфейс и ответы доступны на пяти — русском, украинском, белорусском, польском и английском. Выбор языка «липкий»: один раз указав его, вы не собьёте настройку случайным сообщением на другом языке. Сама база остаётся русскоязычной, а модель переводит каждый ответ на выбранный язык уже на этапе ответа.

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

Откуда берётся практика

Нормативный слой пишет куратор по официальным источникам. А вот практический слой наполняется полуавтоматически — отдельным сборщиком на LangGraph, который превращает чаты диаспоры в обезличенные, дедуплицированные факты.

flowchart LR
  A["Приём сообщений"] --> B["Сборка диалогов"]
  B --> C["Извлечение фактов (LLM)"]
  C --> D{"Фильтр личных данных"}
  D -->|чисто| E["Классификация темы"]
  D -->|есть личные данные| X["Отбросить"]
  E --> F["Дедупликация"]
  F --> G["Подготовка фактов<br/>к проверке"]

Цифры на сегодня: через сборщик прошло около 2,4 млн сообщений, из которых 28 091 признано релевантными, а из них извлечено 17 284 практических факта. Извлечением занимается модель gpt-4o-mini — только обезличенные факты, без имён, ников и цитат.

Ключевой момент — фильтр персональных данных работает по принципу «сначала безопасность»: сначала автоматический поиск контактов, номеров документов и длинных цитат, при необходимости — дополнительная проверка моделью; любой «грязный» факт отбрасывается без сохранения. Перенос факта в базу — всегда ручной шаг куратора, а не автоматика.

Ещё одна деталь, за которую пришлось побороться, — классификатор тем. Раньше он отправлял весь набор фактов в один запрос к модели, та упиралась в таймаут и молча сваливалась на грубую эвристику по ключевым словам, сбрасывая полезные факты в «мусорную» категорию «прочее». Мы разбили обработку на небольшие порции — и доля «прочего» упала с 51% до 23%, а полезных, но неправильно уложенных фактов стало около 3%.

Историческая загрузка устроена так, чтобы её можно было прерывать и возобновлять: у каждого канала есть контрольная точка, и повторный запуск не начинает всё заново, а продолжает с места остановки.

Как мы держим базу актуальной

Собрать факты — половина дела. Дальше их нужно проверить, отредактировать и одобрить. Для этого у куратора есть локальная панель управления — она работает только на его компьютере и никуда не выставлена наружу.

flowchart LR
  subgraph UI["Панель управления (3 вкладки)"]
    COL["Вкладка «Сбор»"]
    REV["Вкладка «Ревью»"]
    SIG["Вкладка «Предложения»"]
  end
  subgraph API["Что делает панель"]
    S1["Статус сбора и факты"]
    S2["Управление каналами и запуском"]
    S3["Список и содержимое страниц"]
    S4["Спросить бота"]
    S5["Одобрить / вернуть страницу"]
    S6["Диалог-правка с ИИ (+ отмена)"]
    S7["Сигналы: предложения,<br/>отзывы, ожидание регионов"]
  end
  COL --> S1 & S2
  REV --> S3 & S4 & S5 & S6
  SIG --> S7
  S4 -->|запустить поиск| RAGcli["Бот"]
  S6 -->|запустить правку| REVcli["Агент правок"]
  S5 -->|записать одобрение| KBfiles["Файлы базы"]
  S6 -->|показать изменения| KBfiles
  S7 -->|"только чтение, без личных данных"| Signals["Входящие сигналы"]

У панели три вкладки: «Сбор» — контроль сбора фактов, «Ревью» — просмотр, правка и одобрение страниц, и «Предложения» — только-читаемые сигналы от пользователей (предложения правок, сводка 👍/👎, лист ожидания по регионам).

Вкладка «Сбор» показывает статус исторической загрузки и состояние каждого Telegram-канала простыми значками — что уже готово, что идёт, что прервалось и возобновится на следующем запуске.

flowchart LR
  ST["Статус загрузки<br/>состояние · дата · текущий канал ·<br/>пауза Telegram · прогресс · лог"]
  CH["Каналы<br/>✓ готов / ⏳ идёт / ◑ частично /<br/>○ ожидает / — н/д"]
  CTL["Управление<br/>дата · ▶ запустить · ■ остановить"]
  FACT["Хранилища и факты<br/>месяц · тема ·<br/>сколько сообщений подтверждают факт"]

Вкладка «Ревью» — рабочее место ревьюера: список страниц с фильтрами, детальный просмотр с источниками и проверочными вопросами, и действия по одобрению.

flowchart LR
  L["Список страниц<br/>фильтры: статус / слой / тема + поиск<br/>счётчики: черновики / проверенные"]
  D["Детали страницы<br/>текст · источники · проверочные вопросы"]
  A["Действия<br/>роль: куратор / юрист<br/>Спросить бота · ✓ Одобрить ·<br/>↩ Вернуть · Исправить с ИИ"]
  L --> D --> A

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

sequenceDiagram
  actor Reviewer as Ревьюер
  participant UI as Панель ревью
  participant API as Сервер
  participant RAGcli as Бот
  participant Agent as Агент правок
  participant FS as Файлы базы (git)
  Reviewer->>UI: выбрать страницу
  UI->>API: запросить страницу
  API-->>UI: текст + источники + вопросы
  opt Посмотреть ответ бота
    UI->>API: спросить бота
    API->>RAGcli: запустить поиск
    RAGcli-->>UI: ответ + ссылки
  end
  opt Правка ИИ
    Reviewer->>UI: комментарий + «Исправить с ИИ»
    UI->>API: запустить правку
    API->>Agent: передать задачу
    Agent->>FS: записать переписанный текст
    API-->>UI: показать изменения
    alt принять
      Reviewer->>UI: «Принять»
    else откатить
      UI->>API: откатить
      API->>FS: вернуть прежнюю версию
    end
  end
  Reviewer->>UI: роль (куратор/юрист) + «Одобрить»
  UI->>API: записать одобрение
  API->>FS: пометка «проверено» + запись в истории

Самое интересное здесь — правка через диалог с ИИ. Вместо ручного редактирования текста куратор просто пишет агенту, что нужно. Агент сам понимает, вопрос это или инструкция на правку.

flowchart LR
  S((сообщение куратора)) --> L["Загрузка страницы"]
  L --> C{"Что это:<br/>вопрос или правка?"}
  C -->|вопрос| AN["Ответ по странице<br/>(без изменений в файле)"]
  C -->|правка| P["Минимальный план<br/>изменений"]
  P --> RV["Переписать только<br/>текст страницы"]
  RV --> V{"Проверка: разделы целы?<br/>текст не обрезан?"}
  V -->|"нужна доработка<br/>(до 2 попыток)"| RV
  V -->|ок| W["Сохранить<br/>+ отметка в истории"]
  AN --> E((конец))
  W --> E

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

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

sequenceDiagram
  actor You as Вы
  participant Chat as Диалог с ИИ
  participant Agent as Агент
  participant FS as Файлы базы (git)
  You->>Chat: «что тут написано про X?»
  Chat->>Agent: это вопрос
  Agent-->>Chat: ответ (файл не меняется)
  You->>Chat: «добавь пункт про Y»
  Chat->>Agent: это правка
  Agent->>FS: переписать текст (служебные поля не тронуты)
  Agent-->>Chat: итог + изменения, страница обновляется
  opt отмена
    You->>Chat: «Отменить» правку
    Chat->>FS: вернуть версию до правки
  end

Как мы измеряем качество

Качество ответов у нас измеряется, а не предполагается. Есть набор из 109 «золотых» вопросов, и каждая новая страница добавляет минимум один. Отдельная модель-судья прогоняет этот набор и проверяет две вещи: передал ли ответ суть ожидаемых фактов (по смыслу, не дословно) и не утверждает ли он как факт что-то запрещённое. Проверка специально настроена строго, чтобы «запрещённое» срабатывало только на явное утверждение, а не на простое упоминание темы.

Текущие метрики: цитируемость около 99%, покрытие фактов около 97%, воздержание на вопросах вне базы — 100%.

Свой сервер, свои модели

Ничего из перечисленного не привязано к одному поставщику. Все модели — распознавание смысла, генерация, распознавание и синтез речи — заменяемы на локальные (например, Ollama или LM Studio) одной настройкой, а сам код остаётся прежним. Для чувствительных данных о релокации это значит, что весь стек можно поднять на собственном сервере и не отдавать вопросы пользователей наружу.

Весь цикл целиком

Если собрать всё вместе, жизненный путь одного факта выглядит так: его собирают из чатов, куратор продвигает практику или пишет норму (черновик), ревьюер проверяет и одобряет, изменения фиксируются, а затем поиск пересобирается и прогоняются проверочные вопросы перед релизом.

flowchart LR
  C["Сбор фактов<br/>(из чатов)"] --> P["Продвинуть практику /<br/>написать норму (черновик)"]
  P --> R["Ревью<br/>читать · спросить бота · править с ИИ"]
  R -->|одобрить| V["Проверено"]
  R -->|вернуть| P
  V --> COMMIT["Зафиксировать изменения"]
  COMMIT --> REINDEX["Переиндексация<br/>и прогон тестов"]

Заключение

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

Попробовать бот можно прямо в Telegram и бесплатно — @legalka_pl_bot. А если вам нужен похожий ассистент, который отвечает строго из ваших данных и не фантазирует, — напишите нам: development@mi-code.pl.

Какая модель за что отвечает

Напоследок — сводка: какая модель решает какую задачу.