> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/expert-center/ru/vehicle-telematics-technology/video-telematics/video-telematics-101/inside-the-dashcam-what-really-powers-video-telematics.md). # Внутри видеорегистратора: что на самом деле лежит в основе Видео телематика
Представьте, что вы сравниваете два видеорегистратора для автопарка. Оба заявляют схожее разрешение видео (скажем, 1080p) и объем памяти, но один стоит 100 $, а другой 200 $. На первый взгляд они похожи — одинаковый размер и те же базовые функции, так почему же такая большая разница в цене? Ответ кроется в *интеллекте* внутри устройства, а именно в **системе на кристалле (SoC)** который работает как мозг камеры. Более дорогая камера — это не просто более качественный корпус: это более умный корпус, оснащенный встроенной обработкой и возможностями ИИ. В современных камерах для автопарков именно SoC и его программное обеспечение определяют всю разницу в производительности, а не только объектив или карта памяти. Менеджеры автопарков и специалисты по телематике часто фокусируются на таких характеристиках, как разрешение или объем памяти, но то, что действительно отличает базовый видеорегистратор от умной камеры видео телематики, — это SoC. Этот крошечный процессор (и поддерживающие его компоненты) обрабатывает все — от получения четких изображений до анализа событий, связанных с вождением, в реальном времени. На самом деле около 65 % электроники типичной телематической камеры приходится на захват изображения, обработку и ИИ — все эти задачи выполняет SoC. Для сравнения, только около 25 % аппаратной части приходится на коммуникационные модули (например, LTE-модемы и GPS). Именно поэтому выбор SoC так сильно влияет и на производительность *и* стоимость устройства. Процессор высокого класса открывает такие функции, как оповещения систем помощи водителю, но также повышает цену из-за большей сложности и лицензионных отчислений (например, за видеосжатие H.265/HEVC). Проще говоря: не все камеры для автопарков одинаковы, даже если снаружи выглядят похоже. Различия во внутренней архитектуре, такие как SoC, датчик изображения, модем, память и т. д., напрямую влияют на качество изображения, быстродействие, возможности ИИ, производительность сети и общую надежность камеры. Более дешевая камера может выполнять базовые задачи (записывать видео и загружать его), но более дорогая модель с более мощным SoC способна на гораздо большее: например, на мониторинг водителя в реальном времени, предупреждения о выезде из полосы, оповещения о фронтальном столкновении и другие функции ADAS. Платформа, не зависящая от устройства, такая как Navixy, позволяет смешивать оборудование разных производителей и семейств SoC в одной среде, нормализуя видео и метаданные, чтобы операционные команды выбирали подходящее оборудование для каждого маршрута или роли, не привязываясь к одной дорожной карте. #### Внутри умного видеорегистратора: как видео проходит путь от объектива до облака Чтобы оценить роль SoC ("мозга" камеры), полезно понять, как камера для автопарка обрабатывает видео шаг за шагом. С момента, когда свет попадает на датчик камеры, и до момента, когда оповещение появляется на вашей панели, происходит многое за кулисами. Ниже приведен упрощенный обзор конвейера обработки видео внутри типичной телематической камеры, и большинство этих шагов координируется SoC:
Article content

От захвата CMOS до облачных панелей: каждый этап определяет, как видео превращается в полезную информацию для автопарка

1. **Захват изображения и обработка сигнала (ISP).** Все начинается с датчика изображения камеры (обычно CMOS-датчика), который захватывает свет и преобразует его в необработанные данные пикселей. Этот сырой поток сразу передается в процессор обработки изображения SoC (Image Signal Processor, ISP) — специализированный компонент на кристалле, который очищает и оптимизирует изображение. ISP выполняет критически важные задачи обработки, такие как дебайеризация (преобразование необработанной мозаики цветовых данных датчика в полноценные RGB-кадры видео), настройка баланса белого и экспозиции, корректировка цветов и снижение шума. Он также может выполнять, например, объединение кадров с высоким динамическим диапазоном (HDR), чтобы справляться со сложным освещением. Результатом этого этапа становится поток высококачественных несжатых видеокадров и основа для всего, что происходит дальше. 2. **Предварительная обработка и анализ ИИ.** В умной камере, еще до сжатия или сохранения видео, SoC может пропустить его через этап анализа ИИ. За это отвечает специализированный аппаратный блок в SoC, например *DSP* или *NPU (нейропроцессор)* предназначенный для задач ИИ. Здесь камера может начать быть *умной*: она ищет события или интересующие объекты в видео в реальном времени. Например, ИИ может обнаружить предупреждение о лобовом столкновении, заметить, что водитель сонный или отвлечен, или распознать знак STOP либо пешехода. Система также может выполнять извлечение области интереса (ROI), то есть фокусироваться на важных частях сцены (например, на дороге впереди или лице водителя), чтобы оптимизировать то, что нужно передать или сохранить. Она может помечать кадры метаданными (например, «обнаружено транспортное средство» или «водитель зевает»), чтобы позже было легко найти конкретные события. Такая предварительная обработка ИИ особенно важна, потому что необработанные видеоданные огромны; анализ на источнике помогает определить приоритеты и сократить объем данных до следующих шагов. (В базовой камере со слабым SoC этот этап может быть очень ограничен или полностью пропущен, поскольку устройство будет просто захватывать и отправлять видео, не «понимая» его.) 3. **Сжатие видео (кодирование).** Далее подготовленные видеокадры поступают в *видеокодер*, еще один блок внутри SoC. Здесь камера сжимает видео с помощью стандартных кодеков, чаще всего H.264 (AVC) или более нового H.265 (HEVC). Сырые видеоданные очень объемны (несжатое HD-видео может занимать десятки мегабайт *в секунду*), поэтому сжатие критически важно. Кодер уменьшает видео до управляемого потока данных (часто до нескольких сотен килобайт в секунду, в зависимости от качества и разрешения). Многие камеры для автопарков на самом деле формируют два видеопотока: один высококачественный хранится локально (например, на SD-карте), а второй, с меньшим битрейтом, загружается по сотовым сетям. Аппаратный кодер SoC обрабатывает оба одновременно. Например, видеоблок SoC Novatek может сохранять поток полного разрешения на карту памяти и одновременно отправлять в облако сжатый поток в реальном времени. Все это происходит на лету благодаря SoC. (Стоит отметить, что лицензирование продвинутых кодеков, таких как H.265, может повышать стоимость высококлассных SoC, и именно поэтому премиальные камеры поддерживают HEVC, тогда как более дешевые могут ограничиваться более старыми кодеками.) 4. **Хранение и передача.** После кодирования видеоданные либо сохраняются, либо передаются, либо и то и другое. В типичной камере для автопарка SoC управляет сохранением видео в локальное хранилище (например, на SD-карту или в флеш-память eMMC) в кольцевом буфере. Он непрерывно перезаписывает самый старый материал, так что, скажем, последние 30–60 минут всегда сохранены, и недавние события доступны сразу. Когда обнаруживается значимое событие (резкое торможение, авария, оповещение, вызванное ИИ, и т. д.), система может пометить и сохранить этот фрагмент. Многие системы также буферизуют несколько секунд видео до и после срабатывания события, чтобы дать контекст, предшествовавший инциденту. Одновременно SoC передает закодированный видеопоток в коммуникационный модуль камеры (например, LTE-модем) для загрузки. Вместе с видео устройство отправит метаданные, такие как координаты GPS, скорость, данные G-сенсора и любые теги событий, созданные ИИ. Эти метаданные могут быть встроены в видеопоток или передаваться параллельно, обеспечивая богатый контекст (например, точное место события резкого торможения, скорость в этот момент или факт обнаружения того, что «водитель зевает»). Затем сотовый модем (4G/3G и т. д.) передает данные в облако. Хотя модем и антенна — это отдельные компоненты, SoC координирует их работу, чтобы эффективно передавать данные по воздуху (часто с использованием протоколов, рассчитанных на прерывистую связь, ограниченную полосу пропускания и т. д.). 5. **Облачная и серверная обработка.** Когда видео и данные попадают в облако, основная нагрузка переходит на серверную сторону. В Navixy видео перекодируется для надежного воспроизведения, индексируется по тегам событий и отображается на единой временной шкале вместе с GPS/IMU. Когда камеры передают вспомогательные данные, такие как CAN-кадры, пакеты BLE-датчиков или байты RS-485, IoT Logic декодирует их при поступлении, так что оповещения ADAS/DMS, поведение водителя и сигналы двигателя или груза остаются доступными для совместного запроса. В результате меньше времени уходит на склейку систем и больше — на действия по важному. Во всем этом конвейере SoC является главным действующим лицом на этапах 1–4. Он координирует работу датчика, запускает ISP, выполняет алгоритмы ИИ, кодирует видео и управляет потоком данных к хранилищу и модему. Неудивительно, что большая часть конструкции видеорегистратора (и его стоимости) сосредоточена именно на этих задачах обработки. Между тем другие компоненты, такие как LTE/GPS-модуль, хотя и важны, выполняют вспомогательную роль. Если представить телематическую камеру как мини-компьютер: SoC — это CPU/GPU/NPU, который выполняет основную вычислительную работу, датчик изображения — это глаза, модем — канал связи, а хранилище — память. Сбалансированная система важна, но без способного «мозга» SoC даже лучший датчик или модем не сделают камеру умной. #### Базовые и продвинутые камеры: как выбор SoC формирует функции Теперь, когда мы увидели, что происходит внутри камеры, давайте поговорим о различиях между базовой камерой для автопарка и продвинутой. Во многих случаях, *самая* большая разница заключается в том, насколько мощным является SoC, особенно с точки зрения возможностей ИИ. Более простая (и более дешевая) видеокамера может выполнять все те же базовые этапы конвейера, такие как захват, кодирование, хранение и передача, но у нее может не хватать встроенного интеллекта для осмысленного выполнения шага 2 (анализа ИИ). По сути, она работает как электронный глаз, записывая то, что видит, и отправляя это дальше, но оставляя «думать» либо облаку, либо не делая этого вовсе. В отличие от нее, высококлассная камера с мощным SoC будет многое «обдумывать» на устройстве: она может обнаруживать события, фильтровать кадры и даже принимать решения в реальном времени (например, оповещать водителя), не дожидаясь облака. Рассмотрим **функции ADAS и DMS**. Функции ADAS (системы помощи водителю) включают, например, предупреждения о выезде из полосы, оповещения о фронтальном столкновении или обнаружение пешеходов. Функции DMS (системы мониторинга водителя) включают обнаружение отвлеченности или сонливости водителя. Бюджетная камера может заявлять о поддержке ADAS, но на деле быть очень ограниченной и уметь обрабатывать лишь один простой алгоритм с умеренной точностью (например, предупреждение о выезде из полосы, которое работает только на трассе и при ясном дневном свете). Часто это связано с тем, что внутри установлен очень скромный AI-процессор, если он вообще есть. Как отмечалось выше, более дешевые SoC с базовыми NPU могут в реальном времени запускать только легкие модели нейронных сетей **легкие модели нейронных сетей** (порядка нескольких миллионов параметров) в реальном времени. Этого может хватить для простого распознавания шаблонов (например, обнаружения разметки полосы или автомобиля прямо впереди). Но *этого не* хватит для более сложных задач, таких как одновременное отслеживание нескольких объектов, определение ориентиров лица водителя (закрытые глаза, повернутая голова) и распознавание дорожных знаков, для которых требуются более крупные и сложные модели ИИ.
Single SoC ingests main + aux feeds, runs per-channel AI, encodes in parallel

Один SoC принимает основной и вспомогательный потоки, запускает ИИ по каждому каналу и кодирует их параллельно

Высококлассные SoC, напротив, оснащены куда более мощными движками ИИ. Например, Ambarella (ведущий поставщик SoC в этой сфере) включает в свои чипы нейросетевой ускоритель CVflow®, который может запускать более крупные CNN (десятки миллионов параметров) и даже несколько моделей ИИ одновременно. На практике это означает, что один премиальный видеорегистратор может выполнять многозадачный ИИ: анализировать дорогу для ADAS *и* и одновременно следить за водителем для DMS с высокой точностью и на высоких частотах кадров. Камера может выдавать оповещения в реальном времени (звуковые сигналы или голосовые предупреждения для водителя) по самым разным вопросам безопасности. Это также означает меньше ложных срабатываний и пропущенных событий, поскольку модели могут быть более сложными. Конечно, все это требует большей вычислительной мощности, поэтому высококлассные SoC часто используют более продвинутые технологии изготовления чипов (например, 10-нм техпроцесс, в отличие от более старых 28-нм или 14-нм процессов), чтобы обеспечивать высокую производительность без перегрева и без быстрой разрядки аккумулятора автомобиля. Еще один аспект, который стоит учитывать, — сколько видеоканалов может обработать SoC. В решениях для автопарков иногда используют камеры с двумя направлениями обзора (дорога и водитель) или даже многокамерные системы (виды сбоку, сзади и т. д.). SoC начального уровня может справляться только с одним или двумя видеопотоками в полном разрешении. Попробуйте добавить больше камер или повысить разрешение, и он может не справиться (низкая частота кадров или просто отсутствие поддержки дополнительных входов). Более способный SoC может принимать и обрабатывать несколько потоков. Например, некоторые SoC, ориентированные на MDVR, могут принимать четыре входа камер 1080p (что обычно используется для обзора автомобиля на 360°), тогда как SoC, ориентированный на системы помощи водителю (ADAS), может поддерживать, скажем, комбинацию фронтальной камеры 4K плюс камеры водителя 1080p или даже несколько камер высокого разрешения для кругового обзора. И снова эти различия сводятся к внутренней архитектуре: высококлассный чип будет иметь более продвинутый ISP, который способен работать с более высокими скоростями передачи данных и, возможно, даже второй ISP для входа с двух камер, больше экземпляров кодера и так далее. Именно поэтому многие автопарки стандартизируются на единой облачной панели: Navixy поддерживает согласованность тегов ИИ, видео и телематики независимо от того, какой SoC установлен в автомобиле. Подводя итог, выбор SoC напрямую определяет, какие функции может предложить камера: * Базовый SoC = базовая камера. Она надежно записывает видео, сжимает его и отправляет, но любые «умные» функции минимальны. Можно получить простую маркировку событий по данным G-сенсора (например, обнаружение аварии по акселерометру) или очень примитивные оповещения для водителя, но не стоит ожидать многого в плане по-настоящему продвинутых предупреждений или анализа. * Продвинутый SoC = умная камера. Она может служить бортовым помощником, наблюдая и за дорогой, и за водителем. Она отфильтровывает важные кадры (чтобы ваш тариф на связь не был забит незначительными клипами) и предоставляет более богатые данные платформе управления автопарком (например, выявляя конкретные действия или риски). По сути, в этой камере встроена система компьютерного зрения. Компромисс, конечно, в стоимости. Высококлассная камера с мощным ИИ-чипом будет стоить дороже — не только потому, что сам кремний дороже, но и из-за разработки ИИ-программного обеспечения, которое на нем работает. Между тем более простая камера может быть очень доступной, но в итоге *обходиться* дороже косвенно — например, она может пропустить критические события или не предоставить превентивные предупреждения, которые помогли бы избежать аварии. Главное — найти правильное соответствие между вашими операционными потребностями и возможностями камеры. Независимо от выбранного уровня, результаты остаются стабильными, когда серверная часть не зависит от устройства. Navixy выводит базовые MDVR и премиальные камеры ADAS/DMS рядом друг с другом в одних и тех же панелях, отчетах и API, так что обновления не требуют изменения рабочих процессов. #### Под капотом: сравнение двух примеров SoC (бюджетного и премиального) Чтобы сделать это более наглядным, давайте сравним две реальные платформы SoC, которые часто встречаются в видеорегистраторах и камерах для автопарков. В бюджетном сегменте у нас есть **Novatek NT98321**, чип, который часто используется в недорогих MDVR и видеорегистраторах. В премиальном сегменте есть **Ambarella CV2**, часть серии CVflow от Ambarella, используемая в премиальных автомобильных камерах. Это хорошие представители своих классов: Novatek известен доступными массовыми процессорами (многие готовые видеорегистраторы используют SoC Novatek), тогда как Ambarella славится более дорогими чипами с фокусом на ИИ, которые используются в камерах с расширенной помощью водителю и даже в системах автономного транспорта. * **Novatek NT98321** оптимизирован для многоканальной записи Full HD при низкой стоимости. Он может обрабатывать несколько видеопотоков 1080p (например, конфигурацию с четырьмя камерами по 1080p каждая) и выполнять базовые задачи ИИ с помощью встроенного NPU. Это идеально подходит для стандартного бортового видеорегистратора, который, возможно, записывает вид спереди, сбоку и интерьер салона, а также выполняет базовое обнаружение событий, например предупреждения о фронтальном столкновении или оповещения о сонливости водителя на одном или двух каналах. Он спроектирован так, чтобы быть энергоэффективным для мобильного использования и чтобы поддерживать низкую стоимость комплектации устройства. * **Ambarella CV2**, с другой стороны, это куда более мощный зверь. Выполненный по 10-нм техпроцессу, он интегрирует специализированный ИИ-движок CVflow от Ambarella, что дает ему значительно больший запас вычислений ИИ (порядка 20-кратной производительности нейросетей по сравнению с предыдущим поколением Ambarella). Он поддерживает входные данные более высокого разрешения (до 4K при 60 кадр/с), несколько датчиков изображения (может принимать потоки от нескольких камер, включая стереоскопические конфигурации) и может одновременно запускать продвинутые многомодельные нейросети для таких функций, как обнаружение полосы, распознавание объектов и мониторинг водителя. Это делает его идеальным для **камер, ориентированных на ADAS**, например интеллектуальной фронтальной камеры, которая не только записывает в сверхчетком 4K, но и определяет выезды из полосы, измеряет дистанцию до впереди идущего автомобиля, считывает знаки ограничения скорости и следит за тем, смотрят ли глаза водителя на дорогу. Компромисс — более высокая цена: CV2 находится в премиальном ценовом сегменте (аналитики отмечают, что такие высококлассные ИИ-чипы стоят значительно дороже массовых SoC). Но вместе с этой ценой приходит и значительный скачок в возможностях. Для сравнения бок о бок см. таблицу ниже, где выделены ключевые различия между решением на базе Novatek NT98321 и решением на базе Ambarella CV2:
Article content

Сравнение SoC, ориентированного на стоимость, и высокопроизводительного SoC

*Таблица: сравнение SoC, ориентированного на стоимость (Novatek NT98321), и высокопроизводительного SoC (Ambarella CV2) в камерах видео телематики. Ambarella превосходит в ИИ и возможностях 4K, тогда как Novatek делает акцент на нескольких каналах 1080p при низкой стоимости. Функции и данные обобщены по информации производителей и результатам разборки устройств.* Как показывает таблица, Ambarella CV2 предоставляет куда больший запас, чем Novatek NT98321, но не каждому грузовику нужен один и тот же класс. Многие автопарки сочетают доступный MDVR на базе NT98321 для охвата с фронтальным блоком на базе CV2 для обучения и предотвращения. С Navixy как не зависящей от устройства серверной частью вам не нужно принимать одно SoC-решение для всего автопарка; вы стандартизируете платформу, а сценарий использования определяет камеру. Когда приоритетом является проактивная безопасность, например при обнаружении усталости, предупреждениях о выезде из полосы/фронтальном столкновении или детализации до уровня номерных знаков, устройство класса CV2 раскрывается в полной мере, а Navixy переносит его более богатые события в те же рабочие процессы, которые вы используете для остального автопарка. #### Как сделать правильный выбор для вашего автопарка При выборе камеры для видео телематики соблазнительно сравнивать очевидные характеристики вроде мегапикселей, угла обзора, объема памяти и т. п. Они, безусловно, важны, но, как мы уже обсудили, менее очевидные характеристики, такие как **SoC и его возможности** и определяют, чем на самом деле отличается «умная» камера от базовой. Вот несколько ключевых соображений и выводов для менеджеров автопарков и поставщиков телематических решений: * **Сопоставьте интеллект камеры со своими потребностями.** Если вам нужно только надежное видеозаписывание (как доказательство после инцидентов) и, возможно, автоматическая загрузка событий торможения, камеры среднего класса или базовой может быть достаточно. Но если вам нужны превентивные функции безопасности (предупреждения о выезде из полосы, мониторинг состояния водителя, оповещения о предотвращении столкновений), ищите камеры с SoC, способным на ИИ, который явно поддерживает функции ADAS и DMS. Дополнительные первоначальные затраты могут окупиться за счет предотвращенных аварий и улучшения поведения водителей. Помните: этот дополнительный интеллект исходит не из корпуса камеры или датчика, а из процессора и программного обеспечения внутри. * **Не полагайтесь только на разрешение.** Маркировка 1080p или 4K не раскрывает всей картины. Камера более низкого класса может иметь такое же разрешение датчика, как и более дорогая, но качество обработки изображения может отличаться. Высококлассные SoC имеют более продвинутые ISP, а значит, более четкое изображение, лучшую работу при слабом освещении и более точную цветопередачу и экспозицию. Это может быть критически важно для получения пригодного материала (например, чтобы распознать номерные знаки ночью). Поэтому учитывайте процессор изображения — а не только датчик изображения — особенно если качество видеодоказательств для вас важно. * **Учитывайте многоканальность, расширение и запас платформы.** Выберите не привязанную к устройствам серверную часть (например, Navixy), которая поддерживает как камеры класса MDVR, так и камеры класса ADAS/DMS, чтобы добавление камер, смотрящих на водителя, или переход на более высокие разрешения не вынуждали менять платформу. * **Проверьте заявленные функции ИИ и обновления.** Производители часто перечисляют функции ADAS (выезд из полосы, предупреждение о фронтальном столкновении и т. д.), если камера их поддерживает. Однако имейте в виду: между базовыми реализациями и продвинутыми есть разница. Попробуйте выяснить *как* камера достигает этих функций. Есть ли у нее выделенный чип ИИ (NPU)? Насколько «умной» она заявлена? Также проверьте, поддерживает ли устройство обновления прошивки для своих моделей ИИ — хорошая платформа может улучшаться со временем за счет программного обеспечения, тогда как действительно бюджетная может никогда не получить обновлений или новых функций. * **Планируйте вспомогательные данные (за пределами видео).** Если камеры передают данные датчиков CAN, BLE или RS-485, используйте платформу с облачным декодированием, например Navixy IoT Logic. Она сохраняет согласованность тегов ИИ и состояния датчиков, позволяя задавать правила на основе комбинаций (например, сонливость + превышение скорости или перегрев + резкие повороты). * **Сбалансируйте бюджет и пользу.** В конечном счете все сводится к ROI. Камера с передовым SoC будет стоить дороже, но если она предотвратит крупную аварию или предоставит четкие доказательства, которые позволят выиграть страховой случай, она легко окупит себя. С другой стороны, если операционные риски вашего автопарка относительно невысоки и камеры вам нужны главным образом для документирования, вы можете выбрать более простое решение и сэкономить бюджет. Главное — понимать, за что вы платите: вы *«покупаете интеллект, а не коробку».* Сама по себе коробка мало что делает. Именно интеллект (SoC и встроенное программное обеспечение) приносит ценность. Мир видео телематики доказывает правило: вы получаете то, за что платите. Внешние характеристики редко показывают, насколько сильно SoC (кремниевый мозг) действительно расширяет возможности устройства. Посмотрите дальше пикселей и объема памяти — и вы поймете, почему выбор правильного чипа имеет значение. От базовых устройств-очевидцев до продвинутых камер ADAS, настоящее испытание — как они работают вместе. Пилотный проект с смешанными камерами на не привязанной к устройствам серверной части, такой как Navixy, мгновенно показывает разницу: обучение, страховые случаи и пропускная способность управляются в одном месте без привязки к поставщику. Сегодня на рынке именно интеллект внутри камеры определяет безопасность и ROI. Самые умные автопарки покупают мозги, а не просто коробку. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://navixy.com/docs/expert-center/ru/vehicle-telematics-technology/video-telematics/video-telematics-101/inside-the-dashcam-what-really-powers-video-telematics.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.