ChatGPT API: FAQ с источниками и передачей оператору

Определите границу FAQ и источников

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

Сохраняйте связь ответа с найденными материалами

Каждая попытка ответа получает локальный request ID и список идентификаторов документов, прошедших фильтр. После генерации сервер проверяет, что система вернула не только текст, но и привязку к реально найденному источнику. Если связь отсутствует, не добавляйте искусственную ссылку в конце ответа. Вместо этого сообщите, что ответ требует проверки, и предложите передать обращение оператору. Полезно хранить версию индекса, дату документа и короткий код проверки, но не нужно автоматически логировать весь вопрос или весь результат. Такая связность помогает объяснить, почему пользователь увидел конкретную формулировку, и позволяет обновить устаревший материал без обещания абсолютной точности модели.

Используйте порог уверенности как маршрут, а не факт

Число уверенности не является доказательством истинности и не должно показываться как точность «99 процентов». Используйте собственные признаки маршрутизации: найден ли разрешённый источник, согласуются ли несколько фрагментов, относится ли вопрос к запрещённой категории, не устарел ли документ и не превышен ли лимит контекста. Если один из признаков не проходит, система выбирает clarification или human_handoff. Честный ответ может сказать, что подтверждённой информации сейчас нет, и предложить оператора. Не заставляйте пользователя переформулировать вопрос бесконечно, если проблема в отсутствии источника. Отдельно проверяйте права пользователя на каждую ссылку, потому что наличие фрагмента в индексе не означает право его раскрывать.

Сделайте эскалацию понятной и минимальной

Передача оператору должна создавать локальное обращение с безопасным резюме, а не пересылать весь чат без разбора. Сохраните request ID, категорию, выбранный маршрут, ссылки на разрешённые документы и согласие пользователя на передачу, если это требуется вашей политикой. Оператор получает контекст, достаточный для ответа, но не ключи, внутренние заголовки или документы другого tenant. Пользователю покажите, что вопрос передан, какие сроки не обещаются и как проверить статус. Не заявляйте, что оператор обязательно изменит ответ или даст юридическую консультацию. Важно, чтобы повторное открытие страницы не создавало несколько обращений: используйте idempotency key и показывайте существующий номер операции.

Проверяйте инъекции и доступ до retrieval

Документы и пользовательские вопросы могут содержать инструкцию, которая пытается изменить правила системы. Не относитесь к фразе в документе как к команде: она является данными и может быть только предметом ответа. Фильтрация tenant, типа документа и разрешения происходит до retrieval, а не после генерации. Ограничивайте размер фрагментов, не добавляйте в контекст технические секреты и не разрешайте модели открывать произвольные URL. Для вопросов о доступе, возврате средств, контракте или изменении профиля задавайте маршрут к оператору вместо самостоятельного действия. Тесты должны включать чужой document ID, prompt injection, устаревшую страницу и ссылку, которую текущий пользователь не имеет права видеть.

Измеряйте качество без фиктивных обещаний

Соберите обезличенный набор типовых вопросов с ожидаемым маршрутом: ответ с источником, уточнение либо human_handoff. В тесте измеряйте долю ответов с валидной ссылкой, отказов без источника, неправильных cross-tenant попыток и дублирующих эскалаций. Отдельный reviewer оценивает фактическую полезность на разрешённых материалах; модель не должна оценивать себя единственным способом. При обновлении индекса, prompt template или адаптера запускайте регрессионный набор и фиксируйте версию. Метрики улучшают процесс, но не превращаются в обещание точности, доступности или юридической правильности. Если риск высокий, ограничьте сценарий и назначьте человека владельцем окончательного решения.

Server-side пример

Пример рассчитан на Node.js 18+ и защищённый server-side запуск. В нём нет реального ключа: это логика приложения, а не текущая спецификация внешнего API. До интеграции подтвердите маршрут, схему и ограничения в документации.

export function chooseFaqRoute({ sourceIds, allowed, sensitive, stale }) {
  if (sensitive || stale) return { route: 'human_handoff', reason: 'review_required' };
  if (!allowed || !Array.isArray(sourceIds) || sourceIds.length === 0) {
    return { route: 'human_handoff', reason: 'no_verified_source' };
  }
  return { route: 'answer_with_sources', sourceIds };
}
// Run tenant authorization before retrieval; never place API keys in the client or log.

Проверьте синтаксис через node --check, добавьте аутентификацию, лимиты и отрицательные тесты. Не помещайте тело запроса, ответ целиком или заголовки авторизации в журнал.

Граница ответственности и данных

Это инженерное руководство для вашего приложения, а не описание гарантированной функции внешнего поставщика. Не помещайте в браузер, тикет, статью или журнал API-ключи, заголовок Authorization, cookie, ключи поставщиков, полный prompt или персональные данные. Для регулируемых данных, договорных условий и прав на контент проверяйте применимые требования с ответственным специалистом.

Материалы для сверки

Внешние источники объясняют общие инженерные принципы. Они не подтверждают функции, тарифы, доступность или SLA RussiaAPI и сторонних моделей.

• OWASP: риски LLM-приложений
• OWASP: контроль доступа