1
00:00:00,300 --> 00:00:03,000
Вы говорите: «Покажи ближайшие аэропорты».

2
00:00:03,100 --> 00:00:08,400
webrtc-komaroff должен распознать реплику, выбрать сценарий и показать результат на карте.

3
00:00:09,133 --> 00:00:11,600
Этот путь проходит через несколько сервисов.

4
00:00:11,700 --> 00:00:17,900
Каждый отвечает за свою часть: соединение, распознавание, состояние разговора или выполнение

5
00:00:18,000 --> 00:00:19,067
инструментов.

6
00:00:19,800 --> 00:00:22,467
Браузер передаёт микрофон по WebRTC.

7
00:00:22,567 --> 00:00:27,433
Сервис Core завершает соединение и превращает звук в короткие пакеты для распознавания.

8
00:00:28,167 --> 00:00:31,400
В текущем формате кадр содержит двадцать миллисекунд звука.

9
00:00:31,500 --> 00:00:35,400
Пакеты идут через брокер сообщений NATS в соседний проект распознавания.

10
00:00:36,133 --> 00:00:38,733
Там детектор речи отделяет голос от тишины.

11
00:00:38,833 --> 00:00:44,300
Когда фраза закончена, сервис отправляет её внешнему распознавателю LinTO и получает текст.

12
00:00:45,033 --> 00:00:48,200
Теперь голосовой и текстовый запросы идут одним путём.

13
00:00:48,300 --> 00:00:52,167
Core передаёт Агенту текст и идентификаторы сессии и реплики.

14
00:00:52,900 --> 00:00:56,067
Агент загружает состояние диалога из базы PostgreSQL.

15
00:00:56,167 --> 00:01:00,933
Так следующий вопрос может продолжить предыдущий сценарий, а не начинать разговор заново.

16
00:01:01,667 --> 00:01:03,767
Дальше работает сценарный движок.

17
00:01:03,867 --> 00:01:09,100
Он решает, какой инструмент нужен, какие данные уже есть и что ещё спросить у пользователя.

18
00:01:09,833 --> 00:01:15,900
Для нового запроса об аэропортах текущий сценарий обращается к языковой модели дважды: сначала выбирает

19
00:01:16,000 --> 00:01:19,167
намерение, затем извлекает параметры поиска.

20
00:01:19,900 --> 00:01:23,167
Сам поиск выполняет инструмент по каталогу аэропортов.

21
00:01:23,267 --> 00:01:25,533
Модель не должна придумывать координаты.

22
00:01:25,633 --> 00:01:28,700
Маршрут строится только при явном запросе пользователя.

23
00:01:29,433 --> 00:01:32,733
Агент сохраняет результат и публикует команды интерфейсу.

24
00:01:32,833 --> 00:01:36,567
Браузер получает событие и обновляет сообщение или карту.

25
00:01:36,667 --> 00:01:39,667
Ответ по HTTP — отдельная часть обмена.

26
00:01:40,400 --> 00:01:42,267
Здесь есть важная граница.

27
00:01:42,367 --> 00:01:46,000
Позиция, погода и рейсы в проверенном коде демонстрационные.

28
00:01:46,100 --> 00:01:50,400
Нарисованный маршрут не является дорожным маршрутом или инструкцией для полёта.

29
00:01:51,133 --> 00:01:54,467
Первое небольшое улучшение — начальная загрузка карты.

30
00:01:54,567 --> 00:01:56,867
Сейчас два запроса идут последовательно.

31
00:01:56,967 --> 00:02:01,267
Переиспользование соединения и параллельное выполнение уберут лишнее ожидание.

32
00:02:02,000 --> 00:02:04,633
Более серьёзная проблема — перегрузка.

33
00:02:04,733 --> 00:02:09,200
Семафор ограничивает активные вызовы, но ожидающие задачи уже созданы.

34
00:02:09,300 --> 00:02:12,000
Нужен предел очереди до приёма новой работы.

35
00:02:12,733 --> 00:02:14,800
Ещё важнее запись результата.

36
00:02:14,900 --> 00:02:17,633
Состояние и история сохраняются раздельно.

37
00:02:17,733 --> 00:02:20,333
При сбое повтор может снова вызвать сценарий.

38
00:02:20,433 --> 00:02:24,100
Нужны общая транзакция и защита от повторного исполнения.

39
00:02:24,833 --> 00:02:27,667
В репозитории три реализации сценарного движка.

40
00:02:27,767 --> 00:02:31,900
Прежде чем удалять две, надо сравнить поведение и проверить их пользователей.

41
00:02:32,000 --> 00:02:34,733
Переименование каталогов эту работу не заменяет.

42
00:02:35,467 --> 00:02:39,233
Следующий вариант — объединить Агент и выбранный сценарный движок.

43
00:02:39,333 --> 00:02:42,800
Исчезнет один сетевой переход, но пользу нужно измерить.

44
00:02:42,900 --> 00:02:45,867
Медиасоединения и модели разумно оставить отдельно.

45
00:02:46,600 --> 00:02:49,433
Начинать стоит с очередей и корректности повторов.

46
00:02:49,533 --> 00:02:53,100
Затем считать вызовы модели, задержку ответа и ошибки.

47
00:02:53,200 --> 00:02:56,433
Полное переписывание без этих измерений пока не обосновано.

48
00:02:57,167 --> 00:03:00,633
Так короткая просьба превращается в цепочку проверяемых действий.

49
00:03:00,733 --> 00:03:02,967
Этот разбор основан на снимке кода.

50
00:03:03,067 --> 00:03:07,700
Он объясняет устройство проекта, но не подтверждает состояние работающего кластера.
