Справочная информация о применении. Это иллюстративная архитектура и контрольный список объёма работ, а не проверенный проект клиента или внедрение с измеренными результатами. Технологии, объём интеграции и результаты поставки согласуются для конкретного задания.
Сценарий и ограничения
Компания хочет использовать ИИ для ответов на основе собственной продуктовой документации, политик или истории обращений в поддержку. Архитектуру фактически определяют следующие требования: ответы должны содержать ссылки на источники, система должна говорить, что не знает ответа, вместо того чтобы его выдумывать, стоимость одной беседы должна быть ограничена, а качество должно быть измеримым до и после любых изменений промпта или модели.
Архитектура
Уровни и зоны ответственности
| Уровень | Технология | Зона ответственности |
|---|---|---|
| Загрузка данных | Воркеры Python | Разбор документов, разбиение на фрагменты, создание эмбеддингов и извлечение метаданных. Работает как конвейер, поэтому переиндексация является штатной операцией, а не повторной сборкой системы. |
| Векторное хранилище | PostgreSQL + pgvector | Эмбеддинги фрагментов хранятся вместе с реляционными метаданными. Одна база данных вместо отдельного векторного сервиса упрощает управление разрешениями и резервное копирование при таком масштабе. |
| Поиск | Сервис на Go | Гибридный поиск: векторное сходство и сопоставление по ключевым словам с последующим переранжированием. Полнотекстовый поиск находит точные номера деталей и коды, которые эмбеддинги регулярно пропускают. |
| Формирование ответов | Сервис на Go, вызывающий API модели | Сборка промпта с найденным контекстом, обязательные цитаты, потоковая выдача ответа, бюджет токенов на запрос. |
| Защитные механизмы | Слой приложения | Проверка области применения, отказ при низкой уверенности поиска, фильтрация персональных данных, передача специалисту в очередь. |
| Администрирование | Панель администратора на Vue | Управление документами, запуск переиндексации, проверка бесед, набор для оценки и панель расходов. |
Модель данных
В таблицах ниже зафиксированы правила, от которых зависит всё остальное. Ошибки на этом уровне превращают работающую демонстрацию в систему, которую невозможно расширять.
Основные сущности
| Сущность | Ключевые поля, связи и правила |
|---|---|
| документ / версия | Исходный документ с историей версий и датами вступления в силу, чтобы ответ можно было связать с редакцией документа, на основе которой он был сформирован. |
| фрагмент | Текстовый сегмент с вектором эмбеддинга, иерархией заголовков, количеством токенов и указателем на документ и позицию — именно позиция позволяет направить ссылку в цитате к нужному месту, а не ко всему файлу. |
| access_scope | Роли или арендаторы, которым разрешено получать фрагмент. Фильтрация выполняется внутри поискового запроса, а не после генерации, иначе ограниченное содержимое может попасть в ответ до выполнения проверки. |
| беседа / сообщение | История обмена сообщениями с идентификаторами найденных фрагментов, использованной моделью, количеством токенов и задержкой для каждого сообщения; это позволяет связать стоимость и качество с каждой беседой. |
| обратная связь | Отметки «нравится» и «не нравится», исправления и флаги передачи специалисту для каждого ответа; эти данные пополняют набор для оценки, а не исчезают в файле журнала. |
| eval_case | Вопрос, ожидаемый источник и примечание о критерии приемки. Запускается при каждом изменении промпта или модели, чтобы регрессии выявлялись до выпуска, а не клиентами. |
Ключевые интерфейсы
Конечные точки, реализующие бизнес-правила
| Конечная точка | Назначение и замечания по конкурентности |
|---|---|
| POST /api/v1/ingest | Ставит документ в очередь на разбор, разбиение на фрагменты и создание эмбеддингов; идемпотентна для пары (document, version), поэтому повторная отправка заменяет запись, а не создаёт дубликат. |
| POST /api/v1/chat | Передаёт ответ потоково. Применяет область доступа при поиске, ограничивает количество токенов контекста, требует цитаты и возвращает отказ, если уверенность поиска ниже настроенного порога. |
| POST /api/v1/chat/{id}/escalate | Передаёт беседу с полным контекстом специалисту в очередь — это механизм, который сохраняет честность системы с ограниченным охватом и не заставляет её отвечать на всё. |
| POST /api/v1/eval/run | Запускает набор для оценки с текущей конфигурацией и сообщает долю успешных случаев и точность цитирования для каждого случая. |
| GET /api/v1/usage | Учитывает токены и расходы по каждому арендатору и периоду; эти данные служат основой для ограничений частоты запросов и предупреждений о бюджете. |
Технические решения
- Гибридный поиск, а не только векторный. Поиск только по векторам может пропустить точные идентификаторы, например номера деталей, коды ошибок или ссылки на статьи. Сравните подходы к поиску на реальных вопросах из набора для оценки. Сопоставление по ключевым словам закрывает этот пробел, а переранжирование объединяет оба подхода.
- Цитаты обязательны, а не рекомендованы. Вежливая просьба к модели цитировать источники ненадёжна. Ответы проверяются по идентификаторам найденных фрагментов и отклоняются, если в них нет цитат; именно это отличает систему, которой можно доверять, от системы, выдающей правдоподобные ответы.
- Порог отказа на основе уверенности поиска. Уверенный неправильный ответ обходится дороже, чем отсутствие ответа. Ниже порога система сообщает, что не знает ответа, и предлагает передать вопрос специалисту.
- pgvector вместо специализированной векторной базы данных. При объёмах документов, типичных для одной компании, один экземпляр PostgreSQL обрабатывает и векторы, и метаданные, объединяя эксплуатацию, разрешения и резервное копирование в одной системе. Выделенное хранилище оправдывает свою сложность только при значительно большем масштабе.
- Набор для оценки с первой недели. Без него каждое изменение промпта превращается в догадку, а регрессии обнаруживают пользователи. Это самый дешёвый способ контроля качества в проекте с ИИ и то, что чаще всего пропускают.
- Доступ к модели через наш сервер. Ключи API никогда не передаются клиенту, а ограничение частоты запросов, бюджетные лимиты и переключение моделей остаются серверной конфигурацией, а не частью выпуска приложения.
Гипотетические целевые показатели проектирования
Приведённые ниже показатели являются гипотетическими примерами для планирования ёмкости, а не измеренными результатами клиента, подтверждённой рекомендацией по подбору ресурсов или SLA. Установите целевые показатели приёмки для конкретного проекта после определения рабочей нагрузки, устройств, данных, оборудования и зависимостей от сторонних сервисов; проверьте их в ходе пилота и нагрузочного тестирования до принятия целевого показателя для промышленной эксплуатации.
Целевые показатели ёмкости и производительности
| Показатель | Значение и допущение |
|---|---|
| Задержка до первого токена | Определите гипотетический бюджет времени до первого токена, затем измерьте его с выбранным провайдером, конвейером поиска и набором для оценки. Задержка провайдера находится вне контроля приложения; потоковая выдача может показывать ход выполнения, не обещая определённое время ответа. |
| Поиск | Менее 200 мс для гибридного поиска и переранжирования по корпусу объёмом в нижнем диапазоне сотен тысяч фрагментов при использовании подходящего индекса pgvector. |
| Стоимость одной беседы | Ограничивается лимитом токенов контекста и бюджетом для каждого арендатора с оповещениями; фактический показатель зависит от выбора модели и длины беседы и измеряется во время пилота. |
| Качество ответа | Отслеживается как доля успешных случаев и точность цитирования на наборе для оценки. Базовый уровень устанавливается во время пилота, а не обещается заранее. |
Что входит в поставку
- Исходный код конвейера загрузки данных, сервисов поиска и формирования ответов, а также панели администратора в вашем репозитории
- Схема базы данных, включая таблицы фрагментов, областей доступа и оценки, а также конфигурацию индексов
- Шаблоны промптов и набор для оценки, оба версионируются вместе с кодом
- Панель расходов и использования, конфигурация ограничений частоты запросов и бюджетных предупреждений
- Примечания по развёртыванию, процедура управления ключами и документированный путь переключения моделей
Планирование решения для вашей компании
Описанные выше модули являются отправной точкой, а не фиксированным пакетом. Обычно мы ограничиваем первый выпуск одним основным рабочим процессом и одним административным процессом, а затем расширяем решение, когда реальное использование показывает, где фактически находятся нагрузка и нестандартные случаи. Отправьте описание задачи, и мы сопоставим его с этой архитектурой и сообщим, какие компоненты пока не нужны.