A video evidence on-demand pullback and content generation method, system, device and medium based on natural language intent and AI log

Abstract

This invention discloses a method, system, device, and medium for on-demand video evidence retrieval and content generation based on natural language intent and AI logs. The method receives natural language requests according to user permissions and performs natural language enhancement rewriting, intent parsing, AI log retrieval, event chain construction, and story editing task generation through a platform-side intelligent task orchestration process. Different types of AI logs are uploaded through different MQTT topics and uniformly parsed into event units. Each event unit includes basic fields and source data fields. The system defaults to retrieving and constructing event chains based on the basic fields, parsing the source fields only as needed during further calculations, tag extraction, content generation, or topic verification. Device network, storage, and fill light status logs are used to assist in determining the retrieval capability of evidence and the reasons for failure. When an event chain matches a user topic and story editing needs to be generated, the system locates the evidence by u_id or camera number and event time, retrieves images, keyframes, or video clips as needed, and synthesizes them on the backend. The system calls a large model to generate JSON results, populates the JSON results into an HTML template, uploads the complete HTML file to an object storage service, and pushes an HTML access link to the application. This invention can reduce the amount of raw video uploads and irrelevant source data parsing, thereby improving content traceability and processing efficiency.

Description

Technical Field

[0001] This invention relates to the fields of intelligent video analysis, camera data processing, MQTT message access, AI log analysis, intelligent task orchestration, video evidence retrieval, web page content generation, object storage, and mobile push technology. In particular, it relates to a method, system, device, and medium for filtering event data from camera AI logs based on the user's natural language intent, retrieving original images, keyframes, or video clips as needed, and generating an HTML result file accessible by the application. Background Technology

[0002] Existing video surveillance and video analytics systems typically employ continuous uploading or centralized storage of raw video footage for later retrieval and playback by users. While this method can preserve complete video evidence, it incurs high costs in terms of bandwidth, storage, retrieval computation, and privacy management when there are a large number of cameras, long video retention periods, or frequent access from mobile devices.

[0003] Another type of system involves cameras or edge devices performing AI analysis first, uploading only AI logs to the platform. These logs include information such as faces, human figures, vehicles, motion detection, gimbal events, device network status, memory card status, and fill light status. This approach reduces the amount of data uploaded, but AI logs are typically reported through different MQTT topics, resulting in inconsistent field structures and event semantics. The platform needs to classify, parse, and uniformly model logs from different topics; otherwise, it will be difficult to form readable event chains, storylines, and evidence organization methods.

[0004] In practical engineering, AI logs for faces, human figures, and vehicles, in addition to basic fields such as camera ID, event time, event type, globally unique identifier, start time, and end time, may also contain raw reported content such as coordinate frames, target attributes, and detailed detection results. If the system parses and processes all raw reported content during the log storage, default retrieval, or candidate event generation stages, it will impose additional computational pressure when there are a large number of cameras or a high reporting frequency, affecting the efficiency of log writing, retrieval, and event filtering.

[0005] Furthermore, existing systems often rely on fixed filter options to complete queries, making it difficult to handle natural language requests such as "Please check what just happened at the door" or "Generate a story clip of recent human activity." Even if the system can review videos chronologically, it typically lacks a mechanism to bind generated content, AI log nodes, camera IDs, event times, globally unique identifiers, images, keyframes, and video clips, making it difficult to trace the generated content. For the application side, directly returning a large number of image and video files would also increase network traffic and mobile rendering pressure.

[0006] Therefore, a technical solution is needed that can uniformly parse logs from different MQTT topics, build event chains based on the user's natural language intent, parse the original AI log source data and pull back the original evidence only when needed to generate story clips, evidence display, target tag extraction or topic verification, and then fill the structured results generated by the large model into the HTML template and provide it to the application through object storage links. Summary of the Invention

[0007] This invention provides a method for on-demand video evidence retrieval and content generation based on natural language intent and AI logs. Cameras or edge devices upload AI logs via different MQTT topics by default, rather than continuously uploading complete original videos. After receiving a natural language request from a user on the application, the platform first determines the set of accessible cameras based on user permissions, and then enhances and rewrites the natural language request and parses its intent through an intelligent task orchestration process to obtain structured intent parameters.

[0008] The intelligent task orchestration process in this invention can be referred to as an Agent process, but this Agent process is not limited to a single large model or a single software framework. Instead, it is a set of task processing modules or sub-processes deployed on the platform side. This set may include one or more sub-processes such as natural language augmentation and rewriting, intent parsing, retrieval condition generation, candidate AI log filtering, event chain construction, story editing task generation, evidence retrieval task generation, large model invocation, JSON result generation, HTML template filling, topic consistency verification, and push decision-making. In a real system, multiple Agents may exist; this invention only limits the processes related to on-demand video evidence retrieval and content generation.

[0009] The AI ​​logs can be uploaded through multiple MQTT topics, such as PTZ event topics, panoramic motion detection topics, panoramic human detection topics, PTZ human detection topics, PTZ face detection topics, panoramic image topics, device network status topics, memory card status topics, fill light information topics, local AI log information topics, and PTZ tracking event topics. The system determines the log type based on the MQTT topic and calls the corresponding parser to uniformly convert different types of logs into event units. Event units can include fields such as camera_id, event_time, event_type, u_id, start_time, end_time, target_type, confidence, device_status, topic_type, evidence_status, and source. Among them, camera_id, event_time, event_type, u_id, start_time, and end_time can be used as basic fields for default retrieval and candidate event generation, and the source field is used to store the original source data of the AI ​​logs, such as the coordinate boxes, target attributes, or detection result details in human, face, vehicle, motion detection, or PTZ tracking logs. By default, the system does not perform full parsing of the source field. It only parses the data as needed when further calculations, target tag extraction, evidence retrieval, content generation, or topic consistency verification are required, thereby reducing the amount of irrelevant source data to be processed.

[0010] Device network status logs, memory card status logs, and fill light status logs can be used as supplementary information about device status. For example, when determining the retrievability of evidence, judging whether a device is offline, identifying the cause of missing files or storage anomalies, or interpreting image quality or fill light status, the system can combine these device status logs instead of treating them as the main events that must be used to generate a story clip.

[0011] When a natural language request lacks a time range, the system defaults to using the current time as the end time and a preset time period preceding the current time as the start time, such as 30 minutes prior to the current time as the default search period. If the description other than the time range is still insufficient to determine the topic, spatial scope, or target type, the system requests additional information from the user on the application side, rather than expanding data processing within an ambiguous scope.

[0012] The system retrieves candidate AI logs within the authorized scope based on structured intent parameters, scores candidate events, and constructs event chains. When an event chain matches a user's topic and a story clip needs to be generated, the system generates an evidence retrieval task based on key event nodes. Evidence retrieval tasks can locate unique data using either u_id or camera_id and event_time. For videos stored in fixed segments, the system sends the start and end times to the device or storage service, retrieves one or more video clips within that time range, and composites them in the backend.

[0013] After a successful pullback, the system uploads the original evidence, including images, keyframes, and video clips, to the object storage service and obtains the corresponding file addresses. The system then calls a large model to generate a structured JSON result based on preset prompts, event chains, AI logs, source field information obtained through on-demand parsing, evidence addresses, and tag information. Subsequently, the system populates the JSON result into a predefined HTML template, creating a complete HTML file containing video, images, text descriptions, and tag information, and uploads this HTML file to the object storage service. The application only receives the HTML access link, thus reducing the bandwidth pressure on mobile devices receiving large amounts of video, images, and structured data at once.

[0014] Before pushing the data, the system performs keyword or topic matching verification between the HTML file's theme and the user's requested theme. If the verification passes, the HTML access link is pushed to the application; if the verification fails, the system does not proactively regenerate the content, but waits for the user on the application to click to regenerate before triggering the process again. When the retrieval of original evidence fails, the system records the failure type, such as device offline, network timeout, or file non-existence, and outputs a failure notification to the application within the scope of the user's request and permissions. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the overall system architecture provided in an embodiment of the present invention.

[0016] Figure 2 This is a schematic diagram of the main process with judgment conditions provided in an embodiment of the present invention.

[0017] Figure 3 This is a schematic diagram of the Agent task orchestration process provided in an embodiment of the present invention.

[0018] Figure 4 This diagram illustrates the evidence pullback on demand and the success / failure branches provided in the embodiments of the present invention.

[0019] Figure 5 This is a schematic diagram illustrating the relationship between HTML content generation and evidence binding in an embodiment of the present invention.

[0020] Figure 6 This is a schematic diagram of the security scene story editing generation process provided in an embodiment of the present invention. Detailed Implementation

[0021] The embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0022] Implementation Method 1: System Overall Architecture and Data Flow.

[0023] In one embodiment, the system includes a camera or edge device, an MQTT log receiving module, a log parsing module, an access control module, an agent task orchestration module, an AI log database, an event scoring module, an event chain construction module, an evidence recall module, an evidence binding module, a large model invocation module, an HTML template population module, an object storage service, and an application push module. By default, the camera or edge device only uploads AI logs, not complete original videos. The platform only recalls images, keyframes, or video clips as needed based on key event nodes when generating story clips, evidence presentations, or upon explicit user request.

[0024] Implementation Method 2: AI log access, basic fields and source fields are parsed as needed.

[0025] Different types of AI logs can be uploaded using different MQTT topics. For example, gimbal events can be uploaded via ` / v1 / device / + / ptz / event`, panoramic motion detection via ` / v1 / device / + / det / event / panoramic / motionDet`, panoramic human detection via ` / v1 / device / + / det / event / panoramic / personDet`, gimbal human detection via ` / v1 / device / + / det / event / ptz / personDet`, and gimbal face detection via ` / v1 / device / + / det / event / ptz / face`. Panoramic images can be uploaded via / v1 / device / + / det / event / panoramic / image, device network status via / v1 / device / + / net / dev, storage card status via / v1 / device / + / sdcard, fill light information via / v1 / device / + / light / info, local AI log information via / v1 / device / + / localAlog / info, and gimbal tracking events via / v1 / device / + / PTZtrackEvents.

[0026] The system identifies log types based on MQTT topics and calls the corresponding parser to convert logs of different structures into unified event units. A unified event unit can include fields such as camera_id, event_time, event_type, u_id, start_time, end_time, target_type, target_id, confidence, device_status, topic_type, evidence_status, and source. Among these, camera_id, event_time, event_type, u_id, start_time, and end_time can be used as basic fields for default database entry, fast retrieval, candidate event generation, and event chain construction; u_id can be used to uniquely locate target log nodes or target events; the combination of camera_id and event_time can also be used to locate target log nodes or retrievable evidence.

[0027] The `source` field is used to store the raw source data of AI logs. For example, the `source` field of human detection logs can store human coordinate boxes, target box positions, target sizes, detection confidence details, or other raw reported content; the `source` field of face detection logs can store face coordinate boxes, face quality scores, feature extraction status, or other raw reported content; the `source` field of vehicle detection logs can store vehicle coordinate boxes, vehicle types, license plate areas, or other raw reported content. During the default retrieval, candidate event generation, and event chain construction phases, the system can use only the basic fields and necessary index fields, without fully parsing the `source` field. The system only parses the `source` field as needed when further computation is required, such as extracting object labels, verifying topic consistency, generating image or video descriptions, determining target positions in the scene, or generating more granular descriptions for story clips. This approach avoids indiscriminate processing of all coordinate boxes and raw detection details when the log volume is large, thereby reducing computational overhead and improving retrieval efficiency.

[0028] Device network status logs, memory card status logs, and fill light status logs can serve as auxiliary device status logs. Network status logs can be used to determine if the device is online and whether a network timeout is possible; memory card status logs can be used to determine if video files might be missing, if storage space is abnormal, or if the storage medium is unavailable; fill light status logs can be used to interpret nighttime image quality, fill light status, or changes in detection confidence. These device status logs can participate in candidate event scoring, evidence retrievability assessment, failure cause identification, and result description generation, but they are generally not used as the main events in personnel, vehicle, or motion detection story clips.

[0029] Implementation Method 3: Natural Language Request Enhancement Rewriting and Intent Parsing.

[0030] In this invention, the Agent refers to a set of task flows on the platform side, rather than requiring the use of a specific large model or a specific Agent framework. The Agent task orchestration module can first enhance and rewrite the user's natural language request. For example, if the user enters "Please check if there was anything happening at the door just now," the Agent can enhance it to "Retrieve AI logs related to human figures, faces, vehicles, motion detection, and device status in the doorway area within the user's permissions for the most recent time period, and generate a story clip when a topic matching event exists."

[0031] If a user request lacks a time range, the system defaults to using the current time as the end time and 30 minutes prior as the start time. If a user request lacks key information other than time, such as not specifying the region, subject, or target type, the system can return a supplementary question to the application, requesting the user to provide the information, instead of performing a boundless search across all devices or all time periods.

[0032] Implementation Method 4: Candidate Event Screening, Scoring, and Event Chain Construction.

[0033] The system generates search criteria based on structured intent parameters and user permission scope, and retrieves candidate events from the AI ​​log database. Candidate event scoring considers topic matching, time matching, spatial matching, event_type matching, topic_type matching, u_id association, event continuity, device availability, evidence retrievability, scene tag matching, and object tag matching. Scene tags can include indoor, outdoor, and other; topic tags can include relaxed, chasing, warm, interesting, and calm; object tags can include people, vehicles, refrigerators, and other objects identified in images or videos.

[0034] During the scoring process, the system can first perform coarse screening and sorting using basic fields. For example, it can first limit the device by camera_id, limit the time range by event_time, start_time, and end_time, limit the event type by event_type and topic_type, and associate the same target or event by u_id. Then, it can combine the device's network status, memory card status, and fill light status to determine whether the evidence meets the conditions for pullback. Only when the candidate event enters a critical node, needs to generate a story clip, or needs to extract more granular object tags, does the system parse the coordinate frame and raw detection details in the source field. This can reduce the number of times irrelevant AI log source data is parsed.

[0035] After scoring the candidate events, the system organizes multiple event units that are sequential in time, spatially related, u_id related, or event type related into an event chain. The event chain is used to express a process that occurs over a period of time, such as a series of events in a security scenario, including people entering, staying, moving, leaving, and equipment operating normally at the entrance area.

[0036] Implementation Method 5: Story editing trigger, evidence pullback and backend synthesis.

[0037] The system does not pull back video for all candidate events. An evidence pullback task is only generated when the event chain matches the user's topic, and the user's request or structured intent parameters indicate that a story clip needs to be generated. An evidence pullback task can include camera_id, u_id, start_time, end_time, evidence_type, user permission information, timeout, and retry policy. evidence_type can be image, key_frame, or video_clip.

[0038] The device can store videos in preset segmented periods, such as storing a video segment every two minutes. After the system sends start_time and end_time to the device or video storage service, it retrieves one or more video segments covered within that time range and synthesizes them into the target story clip in the backend. For images and keyframes, the system can directly retrieve the corresponding files. All pull operations are limited to the scope of user requests and permissions to reduce privacy risks and the amount of irrelevant data processing.

[0039] Implementation Method Six: Structured JSON Generation, HTML Template Filling, and OSS Push.

[0040] After a successful pullback, the system uploads the images, keyframes, video clips, or synthesized video to the object storage service, obtaining the OSS file address. The system provides the event chain, basic AI log fields, source field information obtained through on-demand parsing, the OSS file address, tag information, and preset prompts to the large model, which then organizes them into a structured JSON result. This JSON result may include fields such as title, summary, timeline, video list, image list, risk status label, scene label, topic label, object label, evidence integrity status, and failure reason. Field naming can use camelCase, snake_case, or other engineering conventions; this invention does not limit specific field names.

[0041] In one example, the structured JSON result returned by the large model may include the following content. This content is only an example; actual fields can be added, removed, split, or replaced based on the HTML template, business scenario, device type, or prompt word constraints: {"reportDate": "2026-06-03","updatedAt": "16:26","sampleCount": 4,"scene": {"type": "outdoor","label": "outdoor","confidence": 86,"basis": "High-risk images are concentrated in outdoor passageways and fences."},"conclusion": "Four events of concern were found, two of which are high-risk events and are recommended for priority review.","trend": "Anomalies are concentrated in entrances / exits and fenced areas from 09:00 to 14:00, and have not yet formed a continuous cross-regional spread trend.","modelNote": "This report was automatically generated by the large model based on AI logs and on-demand evidence pullback, and is for preliminary screening reference only.","video": {"objectName": "video_clip / T12345678 / final.mp4","title": "Keyframe video playback","timeRange": "09:00-14:00","posterObjectName": "picture / 1780303075206.jpg","note": "Covering two high-risk events, it is recommended to prioritize the review of passageway obstruction and fence-standing situations.""},"images": [{"imageIndex": 0,"generatedAt": "2026-06-03 09:00:00","timestampMs": 1780303075206,"keyframe":{"objectName": "picture / 1780303075206.jpg"},"device": {"sn": "541288EPM21C0013978F7F7F", "name": "Area A Channel Entrance Camera"},"clip": {"startAt":"2026-06-03 08:59:55","endAt": "2026-06-03 09:00:05","startTimeMs":1780303070206,"endTimeMs": 1780303080206,"timeRange": "0-10s"}}],"imageScenes": [{"imageIndex": 0, "type": "outdoor", "label": "outdoor", "confidence": 88}],"events": [{"id": "evt-001","time": "09:00","imageIndex":0,"deviceSn": "541288EPM21C0013978F7F7F","area": ​​"Area A, Channel Entrance","risk": "high","status": "pending_review","title": "Abnormal Obstruction at Channel Entrance","description": "The key passage area in the image is obstructed, which may affect passage recognition and anomaly verification.","evidence": "The obstruction is located in the center of the channel, and there is a significant difference from the normal field of view.","confidence": 91}],"evidenceStatus": {"complete": true,"missingRange": null,"failureReason":null}}.

[0042] The system populates the structured JSON results into a predefined HTML template, generating a complete HTML file. This HTML file can include video playback components, image display areas, text description areas, timeline areas, and tag display areas. Videos, images, or keyframes in the HTML are referenced via OSS file addresses. The system then uploads the complete HTML file to OSS, obtains an HTML access link, and pushes this link to the application. The application only needs to open a single link to display the results, thus saving bandwidth when receiving large amounts of media files and structured data.

[0043] Implementation Method 7: Topic Consistency Verification, Failure Notification, and Permission Boundaries.

[0044] Before pushing the HTML access link, the system performs keyword or topic matching verification between the HTML content theme and the user's requested theme. For example, if the user requests "Story clips of people's activities at the entrance," the system can check whether the title, summary, tags, and event type in the HTML contain relevant content such as "entrance," "people's activities," "human detection," and "face detection." If the verification passes, the HTML link is pushed; if the verification fails, the system does not actively regenerate the link, but waits for the user on the application to click to regenerate before triggering the process again.

[0045] When retrieving images, keyframes, or video clips fails, the system records the failure type and the extent of missing evidence. Failure types can include device offline, network timeout, file non-existent, insufficient permissions, or device storage anomalies. The system pushes a link to the failure reason or result to the application, but does not process data outside the user's permission or requested scope.

[0046] Implementation Method 8: Example of story clip generation in a park security scenario.

[0047] In a security scenario at a certain industrial park, a user enters into the application, "Generate a story clip of the people's activities at the entrance just now." The system first confirms that the user only has access to cameras C001 and C002 in the entrance area. Since the user did not specify a time range, the system defaults to using the current time as the end time and 30 minutes prior as the start time. The Agent enhances and rewrites this request to "Retrieve AI logs related to human figures, faces, motion detection, PTZ tracking, and device status in the entrance area within the last 30 minutes, and generate a story clip when a topic-matching event exists."

[0048] Based on user permissions and enhanced search criteria, the system retrieves candidate events from the logs corresponding to the MQTT topics / v1 / device / + / det / event / panoramic / personDet, / v1 / device / + / det / event / ptz / personDet, / v1 / device / + / det / event / ptz / faceDet, / v1 / device / + / det / event / panoramic / motionDet, and / v1 / device / + / net / dev. The system parses different logs into unified event units and prioritizes candidate event retrieval and event chain construction based on basic fields such as camera_id, event_time, event_type, u_id, start_time, and end_time. For detection logs of human figures, faces, and vehicles, the system stores the coordinate frame, target attributes, and original detection details in the source field, which are not included in the full parsing by default.

[0049] If the event chain shows that C001 detected a person entering, staying, and leaving the entrance area within the last 30 minutes, and the device's network status is normal, the memory card is available, and the evidence can be retrieved, then the system generates an evidence retrieval task. For example, camera_id=C001, u_id=U20260630161235001, start_time=2026-06-30 16:10:00, end_time=2026-06-30 16:12:30, evidence_type=video_clip. The device stores a video clip every two minutes. The system retrieves multiple video clips covering this range based on the start and end times, and combines them into a single story clip in the backend, while also retrieving relevant keyframes and images. When it's necessary to describe a person's position in the frame, generate object labels, or verify the "person activity" theme, the system further parses the original source data, such as human bounding boxes, face bounding boxes, or motion detection areas, from the corresponding AI log's source field.

[0050] Subsequently, the system uploads the synthesized video, keyframes, and images to OSS to obtain the file address. The system then sends the event chain, AI logs, OSS file address, and preset prompts to the large model, which generates a JSON result, including, for example, a title "Entrance Personnel Activity Review," a timeline of personnel entry and exit, a low-risk status, an outdoor scene tag, a calm theme tag, and a human object tag. The system then populates this JSON result into an HTML template, generating an HTML file containing video, images, descriptions, and tags, and uploads it to OSS. If the HTML content matches the theme "Entrance Personnel Activity Story Clip," the system pushes the HTML access link to the application.

[0051] If the video file is missing or the device is offline during the above process, the system records the failure type and the missing time range, and pushes the reason for the failure to the application. The system will not search other areas of cameras without authorization, nor will it proactively expand to a time range not requested by the user. Only if the user clicks "regenerate" in the application will the system re-execute the relevant process based on the user's permissions and the requested range.

Claims

1. A method for on-demand re-pulling and content generation of video evidence based on natural language intent and AI logs, characterized in that, include: Receive natural language requests input by users through the application and determine the set of accessible cameras based on the user's permission scope; The platform-side intelligent task orchestration process enhances and rewrites the natural language request and parses the intent to obtain structured intent parameters. The intelligent task orchestration process includes at least one or more sub-processes such as natural language enhancement and rewriting, intent parsing, retrieval condition generation, candidate event filtering, event chain construction, story editing task generation, content generation, and theme consistency verification. Candidate events are retrieved from the AI ​​logs corresponding to the accessible set of cameras based on the structured intent parameters; Based on the retrieved candidate events, determine the key event nodes that need to be pulled back to retrieve the original evidence, and generate evidence pull-back tasks corresponding to the key event nodes; According to the evidence retrieval task, retrieve the original images, keyframes, or video clips as needed; generate structured JSON results based on the candidate events, key event nodes, and the retrieved original evidence as needed; The structured JSON result is populated into a predefined HTML template to generate a complete HTML file. The complete HTML file is then uploaded to the object storage service, and the HTML access link returned by the object storage service is pushed to the application.

2. The method according to claim 1, characterized in that, The step of retrieving candidate events from the AI ​​logs corresponding to the accessible camera set based on structured intent parameters includes: uploading different types of AI logs through different MQTT topics and uniformly parsing them into event units; scoring the candidate events and constructing an event chain and determining key event nodes and their evidence retrieval priorities based on the scoring results; generating an evidence retrieval task based on the key event nodes when the structured intent parameters indicate that a story clip needs to be generated; retrieving original images, keyframes, or video clips as needed according to the evidence retrieval task and establishing a binding relationship between the retrieved original evidence and the corresponding AI log nodes; and calling the large model to generate structured JSON results based on the event chain, AI log nodes, bound original evidence, and preset prompts.

3. The method according to claim 1, characterized in that, The AI ​​logs include at least one of the following: face recognition logs, human recognition logs, vehicle recognition logs, PTZ event logs, motion detection logs, device network status logs, memory card status logs, fill light status logs, local AI log information, and PTZ tracking event logs. The AI ​​logs include basic fields and source data fields. The basic fields include one or more of camera_id, event_time, event_type, u_id, start_time, and end_time, where u_id is a globally unique identifier for the event or target. The source data fields are used to store the raw payload data of the corresponding AI log.

4. The method according to claim 3, characterized in that, The source data field is called the source field. The source field is used to store the coordinate boxes, target attributes, detection result details, or original reported content in the AI ​​logs of human detection, face detection, vehicle detection, motion detection, or gimbal tracking. The system does not parse or does not fully parse the source field during the default retrieval, candidate event generation, or event chain construction stages. The source field is only parsed as needed when further calculations, evidence pullback, target tag extraction, content generation, or topic consistency verification are required.

5. The method according to claim 2, characterized in that, The different MQTT topics include one or more of the following: uploading gimbal events, panoramic motion detection, panoramic human detection, gimbal human detection, gimbal face detection, panoramic images, device network status, memory card status, fill light information, local AI log information, and gimbal tracking events. The system determines the log type based on the MQTT topic and calls the parser corresponding to the log type to convert the AI ​​log into a unified event unit. Among them, the device network status log, memory card status log, and fill light status log are used to provide auxiliary device status information when screening candidate events, judging the retrievability of evidence, identifying failure reasons, or generating content.

6. The method according to claim 1, characterized in that, The structured intent parameters include one or more of the following: time range, spatial range, target type, event topic, output format, and user permission constraints. When the natural language request lacks a time range, a default time range is generated using the current time as the end time and a preset duration prior to the current time as the start time. When the descriptive information other than the time range is insufficient to determine the search topic or spatial range, a supplementary information request is returned to the application.

7. The method according to claim 2, characterized in that, Scoring the candidate events includes calculating the candidate event score based on one or more of the following: topic matching degree, time matching degree, spatial matching degree, event type matching degree, event continuity, globally unique identifier association, device availability, object label matching degree, scene label matching degree, and original evidence retrievability.

8. The method according to claim 2, characterized in that, Constructing the event chain involves organizing multiple AI log nodes into an event chain corresponding to the natural language request based on the temporal continuity between candidate events, camera location relationships, globally unique identifiers, target type associations, device status associations, and log type associations corresponding to MQTT topics.

9. The method according to claim 1 or 2, characterized in that, The evidence retrieval task locates unique data based on u_id, or based on camera number and event time; the video segments are stored by the device according to a preset segmentation period; the evidence retrieval task includes a start time and an end time; the system retrieves one or more video segments within the time range based on the start time and end time, and synthesizes the one or more video segments in the backend.

10. The method according to claim 2, characterized in that, Establishing a binding relationship between the retrieved original evidence and the corresponding AI log nodes includes establishing a mapping relationship between description units, tag units, image units, video units, AI log nodes, camera numbers, event times, event types, globally unique identifiers, evidence file addresses, or evidence indexes in HTML files.

11. The method according to claim 1, characterized in that, The complete HTML file includes videos, images, text descriptions, and tag information; the videos, images, or keyframes are referenced by the HTML file through the object storage service file address, and the tag information includes one or more of the following: risk status tags, scene tags, topic tags, and object tags.

12. The method according to claim 1, characterized in that, When retrieving original images, keyframes, or video clips fails, the failure type and the range of missing evidence are recorded, and a failure notification is output to the application. Only data within the user's request range and permissions are processed. The failure type includes one or more of the following: device offline, network timeout, and file not found.

13. The method according to claim 1, characterized in that, Before pushing the HTML access link, keyword or topic matching verification is performed between the content theme corresponding to the complete HTML file and the event theme in the structured intent parameters. If the verification passes, the HTML access link is pushed. If the verification fails, the HTML access link is not actively regenerated, and the application waits for the application to receive the user's regeneration instruction before triggering the method again.

14. A system for on-demand video evidence retrieval and content generation based on natural language intent and AI logs, characterized in that, include: The system comprises the following modules: access control module, MQTT log receiving module, log parsing module, natural language enhancement rewriting and intent parsing module, candidate event retrieval module, event scoring module, event chain construction module, evidence pullback module, evidence binding module, large model invocation module, HTML template filling module, object storage upload module, topic consistency verification module, and application push module; each module is configured to perform the method described in any one of claims 1 to 13.

15. An electronic device comprising a processor and a memory, wherein the memory stores a computer program, characterized in that, When the computer program is executed by the processor, it implements the method according to any one of claims 1 to 13.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 13.

Images