A method of semantic alignment of constrained LLM output with a structured resource system

Abstract

The application discloses a method for semantic alignment of LLM output under constraints and a structured resource system, relates to the technical field of artificial intelligence content generation and structured data management, and solves the technical problem that the existing semantic gap processing method causes subsequent resource binding and video generation to fail. The method comprises the following steps: S1: before the LLM generates content, all entity names in a resource mapping table are formatted into constraint prompt texts according to categories, and the constraint prompt texts are injected into an LLM System Prompt to constrain the LLM to only use the existing names; S2: a regular expression is used to analyze the output text of the LLM, and the entity names in the analysis result are matched with the entity names in the resource mapping table; S3: a double-source timbre analysis method is used to add timbre entries to the default timbre information of the roles; and S4: an entity list corresponding to the entity names is stored persistently. The application realizes the double protection of "prevention + fault tolerance".

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence content generation and structured data management technology, and more specifically, to a method for semantic alignment between constrained LLM output and structured resource systems. Background Technology

[0002] Currently, mainstream AI Agent orchestration frameworks (LangGraph, Swarm, CrewAI, Dify, AutoGen) do not provide an automatic alignment mechanism between LLM outputs and structured resource systems.

[0003] In addition, the patent documents most relevant to the technical direction of this invention are as follows: The patent with publication number CN122029536A discloses a contextualization of a generative language model based on entity resource identifiers. The patent discloses a technical solution that populates entity resource identifiers (ERIs) into a linked entity database and generates a contextualized prompt data structure based on them, so that the LLM response is conditional on the linked entity context information.

[0004] Patent CN120764523A discloses a method for fixing uncontrollable output format of LLMs. The patent discloses a three-step process: S1 Before the LLM generates text, the user-defined format rules are dynamically converted into metadata templates and embedded into the original input to generate enhanced prompt text with format constraints; S2 During the LLM text generation process, the format is verified in real time and potential errors are detected through lightweight rule engine or syntax tree analysis; S3 The format error text of the LLM output is classified and matched with the repair strategy library and combined with the context semantics to generate repair instructions.

[0005] The patent with publication number CN121327044A discloses a multimodal entity linking method based on large model knowledge enhancement. This patent involves multimodal large language model to perform mention enhancement description and semantic similarity calculation of entities, candidate entity screening and difference comparison.

[0006] Patent CN120181077B discloses an entity linking method and system based on a large language model. This patent uses LLM to generate a candidate entity list and constructs a single-choice question-answering task for entity linking.

[0007] Patent CN121960467A discloses a Named Entity Recognition (NER) method, device, apparatus, storage medium, and program product. This patent relates to a NER method for maintaining different entity types for different tasks.

[0008] The patent with publication number CN121327044A discloses a multimodal entity linking method based on large model knowledge enhancement. This patent involves multimodal large language model to perform mention enhancement description and semantic similarity calculation of entities, candidate entity screening and difference comparison.

[0009] Patent CN120181077B discloses an entity linking method and system based on a large language model. This patent uses LLM to generate a candidate entity list and constructs a single-choice question-answering task for entity linking.

[0010] Patent CN121960467A discloses a Named Entity Recognition (NER) method, device, apparatus, storage medium, and program product. This patent relates to a NER method for maintaining different entity types for different tasks.

[0011] The aforementioned patent has the following defects: Defect 1: LLM output may contain entity names not in the database. LLM can freely output any name (such as a custom character name "Zhang San" instead of the existing "Male Lead"). Custom names cannot be mapped to existing entities in the database, causing subsequent resource binding and video generation to fail. None of the five frameworks have a mechanism to "constrain the LLM to use only existing entity names before generation".

[0012] Defect 2: LLM may output too many entity references. Video models have a hard limit on the number of reference graphs (e.g., 7), and LLM may reference too many entities, exceeding the processing capacity of the video model. None of the frameworks have a mechanism to "limit the number of entity references output by LLM and discard them according to priority".

[0013] Defect 3: Character voice binding relies on manual operation. Each character requires manual voice selection, which can lead to hundreds of manual operations in batch scenarios. None of the frameworks have a mechanism to "automatically add default voices to character entities".

[0014] Defect 4: Entity information in the LLM output cannot be automatically persisted; the entity list needs to be manually organized and stored, and it cannot be automatically written to the structured resource fields of the storyboard record. All frameworks lack a pipeline for "LLM output → automatic entity recognition → database mapping → JSONB persistence".

[0015] The core pain point is the "semantic gap" between LLM's free output and structured resource systems. When an LLM outputs a name not found in the database, subsequent resource binding and video generation will fail. In the specific scenario of video storyboard generation, there is also a physical constraint of a hard upper limit on the number of video model reference graphs—the LLM may reference too many entities, exceeding the limit. Existing solutions rely on manual operation, which is extremely inefficient in batch scenarios. The technical problem solved by this invention is not only the general problem of "LLM output alignment with entities," but also the specific technical problem of "LLM output alignment under the specific physical constraint (hard upper limit on the number of reference graphs) of video generation." Summary of the Invention

[0016] The technical problem this invention aims to solve is to address the shortcomings of existing technologies by providing a semantic alignment method between LLM output and structured resource systems under constraints. This method addresses the technical problems of existing methods for processing the semantic gap between LLM free output and structured resource systems, which lead to subsequent resource binding and video generation failures, a hard upper limit on the number of video model reference graphs, and low efficiency of manual operation.

[0017] The present invention discloses a method for semantic alignment between constrained LLM output and structured resource systems. The method is as follows: S1: Before generating content in the LLM, construct a resource mapping table, format all entity names in the resource mapping table into constraint prompt text according to category, and inject the constraint prompt text into the LLM System Prompt to constrain the LLM to only use existing names; at the same time, attach entity reference upper limit constraints and priority selection rules to the LLM that match the hard upper limit of the number of video model reference graphs. S2: Use the regular expression "@name" to parse the output text of LLM, and match the entity name in the parsing result with the entity name in the resource mapping table. When the match is successful, the complete information of the role entity corresponding to the entity name is retained; when the match fails, the entity name that failed to match is used as a custom name and the custom name is ignored, forming a fault tolerance compensation for the incompleteness of the above S1 constraint. S3: Collect manually bound timbre information for the character entity, query the manually bound timbre information to obtain the character's default timbre information, and add timbre entries to the character's default timbre information through dual-source timbre parsing; S4: Persistently store the list of entities corresponding to the entity names.

[0018] As a further improvement, in S1, the method for constructing the resource mapping table is as follows: The database is queried to identify three types of entities: character entities, scene entities, and prop entities. A basic reference diagram is obtained for each of these entities. A resource mapping table is then constructed based on the basic reference diagram, with the entity name as the key and the entity information as the value.

[0019] Furthermore, in S1, the priority selection rule is as follows: the character entity is set as the first priority, the scene entity is set as the second priority, and the prop entity is set as the third priority. Obtain the number of entities after silent ignoring in S2, and compare the number of entities with the hard upper limit of the number of video model reference images. If the number of entities is greater than or equal to the hard upper limit of the number of video model reference images, then prop entities are discarded first. If prop entities are discarded and the number of entities is still greater than or equal to the hard upper limit of the number of video model reference images, then secondary scene entities that appear later in the script segment are discarded.

[0020] Furthermore, in S1, the method for formatting all entity names in the resource mapping table into constraint hint text by category is as follows: The entity information in the resource mapping table is filtered to obtain three types of entity name lists, including a list of character entities, a list of scene entities, and a list of prop entities. These three lists of entity names are then used to create constraint prompt text.

[0021] Furthermore, in S2, the method for parsing the LLM output text using the regular expression "@name" is as follows: Obtain the storyboard text from the LLM output text, perform a findall operation on the storyboard text using the regular expression "@name", extract all Chinese and English character sequences following the "@" prefix in the storyboard text, and use the Chinese and English character sequences following the "@" prefix as the parsing result.

[0022] Furthermore, in S2, the method for matching the entity names in the parsed results with the entity names in the resource mapping table is as follows: Initialize the seen set, iterate through each entity name in the parsed results. If the entity name is already in the seen set, the match is successful. Use the entity name as the key to search the resource mapping table. If the entity name is not in the resource mapping table, the match is unsuccessful.

[0023] Furthermore, in S3, the method for adding timbre entries to the default timbre information of the character through dual-source timbre analysis is as follows: Extract the OSS storage key of the timbre that directly matches the character from the character entity, remove the whitespace characters from the OSS storage key, and when the OSS storage key with the whitespace characters removed is not empty, convert the OSS storage key with the whitespace characters removed into a temporary pre-signed access URL. When the timbre OSS storage key after removing the whitespace characters is empty, set the filter conditions, query the standard timbre directory table according to the filter conditions to obtain the timbre directory record, remove the whitespace from the storage key in the timbre directory record and assign it to the timbre OSS storage key after removing the whitespace characters, convert the assigned timbre OSS storage key into a temporary pre-signed access URL, and append the temporary pre-signed access URL to the list of role entities.

[0024] Furthermore, in S3, the entity function component is called to collect manually bound timbre information for the character entity and skip automatic appending; an automatically appended set is created, and the character's default timbre information is compared with the automatically appended set. If the character's default timbre information is within the automatically appended set, automatic appending is skipped.

[0025] Furthermore, in S4, the method for persistently storing the entity list corresponding to the entity name is to serialize all the entity information into JSON and write it into the source_resources field of the storyboard record.

[0026] Furthermore, the source_resources field stores JSON format strings, and each entry in the JSON format string includes an entity database ID, entity type, reference graph record ID, OSS storage key, and pre-signed access URL.

[0027] Beneficial effects The advantages of this invention are: 1. This invention uses "@name" as a specific tag syntax. The format design of "@prefix + Chinese name" provides a clear anchor point for the regular expression parsing in step S2. The two form a collaborative design rather than an independent step and involve hard upper limit constraints on the number of reference graphs in the video generation scenario and priority selection rules. This invention forms an adaptive combination of entity constraints and video model physical constraints. This invention achieves dual protection of "prevention + fault tolerance" through the collaborative combination of steps S1 and S2.

[0028] 2. This invention constrains the output of the LLM to align with the database entities before LLM generation, avoiding the creation of custom names from the source; after LLM generation, it automatically parses entity references and maps them to database entities to obtain reference graph information; it automatically appends default timbres to role entities, realizing cross-modal automatic binding of text → image → audio; and it automatically writes the entity list into a JSONB field for direct use by front-end rendering and video generation.

[0029] 3. Step S1 alone cannot completely eliminate custom names. As a probabilistic model, LLM does not adhere to the "prohibit custom names" instruction 100%. Without the fault-tolerance mechanism of step S2, the failure rate of entity recognition will lead to frequent failures in subsequent resource binding and video generation, requiring extensive manual correction. Using S2 (regular expression parsing) alone cannot guarantee that LLM outputs entity mentions in the @name format, resulting in a significant drop in hit rate. Only by combining both can reliable alignment be achieved at low cost.

[0030] 4. After the LLM is generated, this invention uses regular expressions to parse entity references marked with the @ prefix in the LLM output text, matches the parsing results with the resource mapping table, retains the complete information of successfully matched entities, and silently ignores user-created names that fail to match, thus forming a fault-tolerant compensation for the incomplete constraints of the resource constraint injection module. Attached Figure Description

[0031] Figure 1 This is a flowchart of the semantic alignment method between constrained LLM output and structured resource system according to the present invention. Figure 2 This is a flowchart illustrating the automatic entity mapping generated in the semantic alignment method between constrained LLM output and structured resource systems according to the present invention. Figure 3 This is a flowchart illustrating the automatic addition of default character timbres in the semantic alignment method between constrained LLM output and structured resource systems of this invention. Figure 4 This is a comparison chart showing the differences between the semantic alignment method of the LLM output and the structured resource system under constraints of the present invention and the patent with publication number CN122029536A. Figure 5 This is a comparison chart showing the differences between the semantic alignment method of the LLM output and the structured resource system under constraints of the present invention and the patent with publication number CN120764523A. Figure 6 This is a comparison chart showing the differences between the semantic alignment method of the LLM output under constraints of this invention and the structured resource system, and other entity linking patents. Detailed Implementation

[0032] The present invention will be further described below with reference to embodiments, but this does not constitute any limitation on the present invention. Any limited modifications made by any person within the scope of the claims of the present invention are still within the scope of the claims of the present invention. See Figures 1-6 The present invention provides a method for semantic alignment between constrained LLM output and structured resource systems, such as... Figure 1 As shown, the method includes, Step S1: Pre-generation resource constraint injection: Step S11: Resource map construction (build_resource_map) Query the database for three types of entity data: characters, scenes, and props, and construct a resource mapping table with entity name as the key and entity information as the value.

[0033] Execution logic and parameter flow: The entity list is automatically written into a JSONB field for direct use by the front-end rendering and video generation.

[0034] Input parameter: script_id (integer, identifying the current script), used to filter entity data belonging to this script from the database.

[0035] Initialization: Create an empty dictionary resource_map, with the key being the entity name (string) and the value being a dictionary of entity information.

[0036] Character entity query and construction: Using script_id and deleted=0 as filter conditions, query the CpResourceCharacter table to obtain all non-deleted character entity records under this script.

[0037] For each character entity c, call _get_base_image(db, c.id, "character") to obtain the basic reference image information for that character. The returned value img is a dictionary {"image_id": int, "file_url": str, "url":str} or an empty dictionary {}.

[0038] Using the role name c.name as the key, write an entity information dictionary into the resource_map, which contains 6 fields: type="character" (entity type identifier), entity_id=c.id (role database ID), name=c.name (role name), and image_id / img.get("image_id") (reference image record ID). file_url / img.get("file_url") (refer to the OSS storage key in the image), url / img.get("url") (refer to the pre-signed access URL in the image).

[0039] Scene entity query and construction: Similar to roles, query the CpResourceScene table, call _get_base_image(db,s.id, "scene") to get the basic reference image of the scene, and write it into resource_map with the scene name as the key and type="scene".

[0040] Item entity query and construction: Similar to the character, query the CpResourceProp table, call _get_base_image(db,p.id, "prop") to get the basic reference image of the item, and write it into resource_map with the item name as the key, type="prop".

[0041] Output parameters: Returns a resource_map dictionary with the structure Dict[str, dict], where the keys are all entity names and the values ​​are dictionaries of the corresponding entity information. This resource_map will serve as the shared input for steps S1 (build_resource_hint) and S2 (parse_entity_mentions). Each entity_info contains: type (character / scene / prop), entity_id, name, image_id, file_url, and url.

[0042] Step S12: Get the base reference image (_get_base_image): For each entity, query the image table of the corresponding type.

[0043] Execution logic and parameter flow: Input parameters: db (database session object), entity_id (integer, entity database ID), resource_type (string, entity type identifier, value is one of "character" / "scene" / "prop").

[0044] First priority query (explicit base graph): Select the corresponding image table based on resource_type. ("character"→CpResourceCharacterImage, "scene"→CpResourceSceneImage, "prop"→CpResourcePropImage) is filtered by four conditions: entity ID (character_id / scene_id / prop_id), is_base_resource=1 (explicitly marked as base image by user), deleted=0 (not deleted), and status="1" (image generated successfully). The images are sorted in descending order by update_time, and the most recent record that meets the conditions is retrieved from first(). If resource_type does not belong to any of the above three conditions, an empty dictionary {} is returned directly.

[0045] Rollback query (if the first priority query result is empty): Remove the condition is_base_resource=1 and filter only by the three conditions: entity ID, deleted=0, status="1". Also sort in descending order of update_time and take the first(), that is, the most recently successfully generated image. This ensures that even if the user does not explicitly mark the base image, a usable reference image can be obtained.

[0046] Result processing: If a record 'row' is found, extract the 'file_url' field (OSS storage key), call get_presigned_url(fk) to convert it into a temporary pre-signed URL. If get_presigned_url returns an empty value but 'file_url' itself is a complete URL starting with http / https, then use 'file_url' directly as the 'url' value and return a dictionary {"image_id":row.id, "file_url": fk, "url": url}, where image_id is the image record database ID, file_url is the original OSS storage key, and url is the accessible pre-signed URL. If no results are found for any query, or an exception occurs, return an empty dictionary {}.

[0047] Key Logic Explanation: First Priority: Query records explicitly marked by the user as the base reference graph (is_base_resource=1, status="1", deleted=0), and retrieve the latest record in descending order of update time. Rollback Mechanism: If there is no explicit base graph, query the most recently successfully generated image (status="1", deleted=0, update_time DESC) to ensure that each entity has a usable reference graph URL. After obtaining the file_url, call get_presigned_url() to convert the OSS storage key into a temporary pre-signed URL. If the URL is already in HTTP format, use the returned structure directly: {"image_id": int, "file_url": str, "url": str}, where image_id is the image record ID, file_url is the original OSS storage key, and url is the accessible pre-signed URL.

[0048] Step S13: Constraint hint text formatting (build_resource_hint): Format all entity names in the resource mapping table into constraint hint text by category and inject it into the LLM's System Prompt: Execution logic and parameter flow: Input parameters: resource_map (a dictionary, a resource mapping table produced by build_resource_map, with the key being the entity name and the value being a dictionary of entity information), max_refs (an integer, with a default value of 7, corresponding to the hard limit on the number of video model reference maps).

[0049] Entity category extraction: Iterate through all values ​​in resource_map (entity information dictionary), and filter by the type field to get three categories of entity name lists: characters (all entity names with type="character"), scenes (all entity names with type="scene"), and props (all entity names with type="prop"). Each list retains only the name field value of the entity for subsequent formatting.

[0050] Constraint prompt text construction: First line: Fixed title "[List of available themes for the current script (names must be referenced using @ in storyboards, and custom names are prohibited)]".

[0051] If characters is not empty, add a line "Character: " followed by all character names, with each name preceded by an @ prefix and separated by commas, such as "Character: @Male Lead, @Roommate, @Female Second Lead".

[0052] If scenes is not empty, add a line "Scenes: " followed by all scene names, in the same format as above.

[0053] If props is not empty, add a line "props: " followed by the names of all props, in the same format as above.

[0054] The last line adds important restrictions, including three key constraints: ① The number of deduplicated @ subjects must be ≤ max_refs (hard limit in video model reference graph); ② Priority: character > scene > prop. If the limit is exceeded, props are discarded first. If the limit is still exceeded, secondary scenes that appear later in the script segment are discarded; ③ Adding @ subjects outside the list is strictly prohibited.

[0055] Output parameters: Returns a constraint hint text string (all lines connected by newlines), which will be injected into the LLM as part of SystemPrompt.

[0056] Key constraint rules: 1. "Disallow custom names" - Ensures that LLM outputs are precisely aligned with database entities.

[0057] 2. STORYBOARD_MAX_REF_ASSETS=7 — Limits the number of entities referenced in the LLM.

[0058] 3. Priority selection (character > scene > item) — a truncation strategy when the limit is exceeded.

[0059] 4. "Secondary Scene" Judgment Criteria—When the number of scene entities exceeds the remaining quota, scenes are judged according to their order of appearance in the script fragment text. Scenes appearing later are considered "secondary scenes" and are discarded first; that is, scenes that appear / are mentioned first are retained first, and scenes that appear / are mentioned later are discarded first. This criterion ensures that the constraints of S1 injection are actually effective during the LLM generation stage, because the LLM can perceive the order of scene appearance in the text during generation.

[0060] Step S14: Injection method of constraint prompt text and LLM call In the `generate_segment_node` of `storyboard_script_subgraph`, `resource_hint` is injected as the first part of the `System Prompt`: Execution logic and parameter flow: Input parameter: state (StoryboardScriptState dictionary, containing fields such as current_index, segments, resource_map, script_id, endpoint_id, director_template, etc.).

[0061] Resume interruption check: Retrieve the current_index from the state to locate the current segment, and obtain seg = state["segments"][idx]. If the segment already has a description field and force_rebuild in the state is not set to True, skip the LLM call and directly return the segment's description as _current_text. Constraint hint text construction: Call build_resource_hint(state["resource_map"], `max_refs=STORYBOARD_MAX_REF_ASSETS` generates the string `resource_hint`.

[0062] System Prompt assembly: Extract director_template (director template, if not in state, use the default value "Please generate storyboard for the following script segment.") Extract segment_text (segment script text, from seg["content"]).

[0063] Concatenate `system_prompt = resource_hint + director_template + "

Segment script content

[0064] LLM call configuration: Create a GatewayChatModel instance, pass in endpoint_id (specify the model endpoint), task_meta (carrying task meta information such as agent_name="storyboard_script", user_id, project_id, script_id, etc.), callback_url (callback address), and construct the messages list: [SystemMessage(content=system_prompt),HumanMessage(content="Please generate a storyboard script for this clip")).

[0065] Streaming generation and output: Call llm.stream(messages) to generate tokens one by one. Each token is obtained through chunk.content and concatenated into the string full_content. The dictionary {"_current_text": full_content, "_batch_event": None} is returned, where full_content is the complete storyboard text generated by LLM.

[0066] Explanation of LLM invocation method: The synergistic and complementary relationship between steps S1 and S2: Invocation method: Call the remote large language model service through the API gateway encapsulated by GatewayChatModel. endpoint_id specifies the specific model endpoint, and task_meta carries task meta information (agent name, user ID, project ID, script ID).

[0067] Prompt Template Structure: The System Prompt consists of four parts stacked in order of priority: style_prompt (style hint) → resource_hint (resource constraint text) → director_template (director template) → segment script content. The resource_hint is always located within the system_prompt, ensuring that the LLM is subject to resource constraints under any style and director's instructions.

[0068] Streaming generation: Outputs tokens one by one using llm.stream(messages), with tokens transmitted via LangGraph. astream_events are passed to the front-end SSE via the on_chat_model_stream event, allowing users to see the text resume from where it left off in real time: if there is already a description and it is not force_rebuild, the LLM is skipped and the existing content is reused directly.

[0069] The synergistic and complementary relationship between steps S1 and S2: Step S1 (resource constraint injection before generation) and step S2 (automatic entity mapping after generation) are not simply two independent technical means linked together, but rather form a complementary closed loop of collaborative design: Limitations of step S1: As a probabilistic generative model, LLM may still violate the constraint "prohibit custom names" even if the System Prompt explicitly states "prohibit custom names," outputting names not in the resource_map. Experimental observations show that LLM's compliance with the "prohibit custom names" directive is not 100%, especially noticeable in complex scenario scenarios. Therefore, S1 alone cannot completely eliminate the custom name problem.

[0070] Fault tolerance compensation in step S2: Step S2's `parse_entity_mentions` uses the `@name` marker injected in step S1 as the anchor point for regular expression parsing. Entities matching `resource_map` are retained, while custom names not in `resource_map` are silently ignored (if not entity_info: continue). Step S2, as a fault tolerance mechanism, compensates for the limitation of step S1 in not being able to fully constrain LLM output. Anchor point supply from step S1 to step S2: Step S1 injects entity names into the System Prompt in the format "@name" through `build_resource_hint`. This specific marker format (`@prefix + Chinese name`) provides an explicit parsing anchor point for the regular expression `r"@([\u4e00-\u9fa5\w]+)"` in S2. Without the `@name` format constraint from S1, LLM might mention entities in arbitrary formats in the output (such as "male protagonist" or "that boy" instead of "@male protagonist"), and S2's regular expression parsing would not be able to reliably identify entity mentions.

[0071] The technical effect of the collaborative closed loop: S1 prevents problems at the source, while S2 provides post-event fault tolerance, forming a dual-protection closed loop of "prevention + fault tolerance". Using S1 alone cannot completely eliminate custom names, and using S2 alone cannot guarantee that the LLM outputs entity references in the @name format. Only by combining the two can reliable semantic alignment between the LLM output and the database entities be achieved.

[0072] like Figure 2As shown, step S2: automatic post-generation entity mapping.

[0073] Step S21: @Name Regular Parsing (parse_entity_mentions): Execution logic and parameter flow: Input parameters: text (string, the storyboard script text generated by LLM), resource_map (dictionary, the resource mapping table produced by build_resource_map).

[0074] Null check: If text is empty or resource_map is empty, directly return an empty list [].

[0075] @Name extraction: Use the regular expression r"@([\u4e00-\u9fa5\w]+)" to perform the findall operation on text, and extract all Chinese and English character sequences following the @ prefix. Regular meaning: @ is a fixed anchor prefix (the format convention injected by build_resource_hint in S1), [\u4e00-\u9fa5] matches Chinese characters, \w matches English letters, numbers and underscores, + means matching one or more characters. Return the mentions list, each element is the name string after the @ prefix (without the @ prefix itself), for example, "@Hero walks into@Dormitory" in text will extract ["Hero", "Dormitory"].

[0076] Entity matching and deduplication: Initialize the seen set (for deduplication, to avoid repeated recording of multiple mentions of the same name) and the entities list (for storing successfully matched entity information).

[0077] Iterate over each name in the mentions list: a. If the name is already in the seen set, skip it (only keep the first occurrence when the same entity is mentioned multiple times).

[0078] b. Use the name as the key to look up resource_map to obtain the entity_info dictionary.

[0079] c. If the name is not in resource_map (that is, a name created by the LLM itself, entity_info is None), skip it (silently ignore, no error is reported and no record is made) — this is the core implementation of the S2 fault tolerance mechanism d. Add the name to the seen set e. Construct an entity information dictionary appended to the entities list, containing 7 fields: name (entity name), type (entity type, taken from entity_info), entity_id (entity database ID), image_id (reference graph record ID), file_url (reference graph OSS storage key), and url (reference graph pre-signed URL).

[0080] Output parameters: Returns a list of entities (List[dict]), where each element is a dictionary containing information about a successfully matched entity. This list will serve as input for steps S3 (timbre appending) and S4 (persistence).

[0081] Key mechanisms: 1. The regular expression r"@([\u4e00-\u9fa5\w]+)" supports both Chinese and English @ names.

[0082] 2. Names that fail to match (such as names created by LLM) are ignored.

[0083] 3. Remove duplicates from the seen set (only the first instance of the same name is retained).

[0084] 4. Each entity information includes a basic reference diagram (for use in video generation).

[0085] Step S22: Integrate in save_segment_node: In the `save_segment_node` of `storyboard_script_subgraph`, `parse_entity_mentions` is executed immediately after writing the library: Execution logic and parameter flow: 1. Input parameters: state (StoryboardScriptState dictionary, containing fields such as segments, resource_map, script_id, etc.), and full_text (the storyboard script text generated by generate_segment_node).

[0086] 2. Step 1: Store business data in the database: Call SegmentService.update_and_sync_storyboards_batch to write the storyboard script content generated by LLM into the cp_segment.description field.

[0087] 3. Step 2: Entity Mapping (S2): Call parse_entity_mentions(full_text, state["resource_map"]), with full_text as the LLM output text and state["resource_map"] as the resource mapping table, to produce a list of entities (a dictionary list of successfully matched entity information).

[0088] 4. Step 3: Add Voice (S3): Call `enrich_source_resources_with_character_voice(entities,int(state["script_id"]), log_context=...)`, taking the list of entities and `script_id` as input, to automatically add voice to the character entities. Add a timbre entry to generate an expanded list of entities.

[0089] 5. Step 4: Persistent Storage (S4): If entities are not empty, call... The `save_storyboard_source_resources(seg["id"], entities)` function serializes the expanded list of entities into JSON and writes it to the `source_resources` field of the `CpStoryboard` table.

[0090] like Figure 3 As shown, step S3: The default voice for the character is automatically added.

[0091] Step S31: Tone Analysis and Automatic Enrichment (enrich source resources with character voice) 1. Input parameters: entities (list, a dictionary of entity information generated by parse_entity_mentions), script_id (integer, the current script ID), log_context (string, log context information, optional).

[0092] 2. Collect manually bound timbre information: Call _entity_ids_with_explicit_audio(entities) to extract the set of entity_ids of roles that have already been explicitly manually bound to timbres (type="audio" and voice_enrich_source is not "auto_character_voice") from the entities list, and denote them as explicit_audio_ids. The timbres of these roles have been manually selected by the user and should not be automatically added to avoid overriding the user's intentions.

[0093] 3. Query the default voice for a role: Extract the set of all entity_ids with type="character" from the entities list, denoted as character_entity_ids. Using scriptid, deleted=0, and id.in(character_entity_ids) as filter conditions, query the CpResourceCharacter table to obtain the corresponding role record. For each role c, call _resolve_voice_payload_for_character(db, c) to parse the voice URL, returning a payload dictionary {"file_url": str, "url": str} or an empty dictionary {}. Only retain roles whose URL or file_url in the payload is not empty, and store them in the voice_by_character_id dictionary with the role ID as the key.

[0094] 4. Iterate through the entity list and append timbre entries: Create an output list `out` and an auto-append collection `already_auto_for` (to prevent the same role from being auto-appended repeatedly). Iterate through each entity item in the `entities` list. a. First, copy the item exactly as it is and append it to the out list (keeping all original entity information unchanged).

[0095] b. If the item's type is not "character" (i.e., scene, prop entity), skip the timbre addition logic and continue traversing the next entity.

[0096] c. Obtain the item's entity_id and denote it as eid.

[0097] d. If eid is in the explicit_audio_ids set, skip (if there is already a manually bound timbre, it will not be automatically appended).

[0098] e. If eid is in the already_auto_for set, skip it (it has been automatically appended to prevent duplicates).

[0099] f. Retrieve the voice payload corresponding to eid from the voice_by_character_id dictionary. If the payload is empty, skip this step (there are no available voices for this character).

[0100] g. Construct an audio entry to be appended to the out list, containing 8 key fields: name (display label, such as "Male Lead Audio"), character_name (character name), type="audio", resourceType="audio", entity_id=eid, mention_label and label (both equal to the display label), image_id=None (audio entry has no reference image), file_url and url (path to the sound resource obtained from the payload), and voice_enrich_source="auto_character_voice" (marks this entry as automatically appended rather than manually bound).

[0101] h. Add eid to the already_auto_for set.

[0102] Output parameters: Returns an out list (List[dict]), containing all existing entity entries and newly added audio entries. Audio entries carry the voice_enrich_source="auto_character_voice" flag to distinguish them from manually bound audio entries.

[0103] Step S32: Voice URL Resolution (_resolve_voice_payload_for_character) Execution logic and parameter flow: 1. Input parameters: db (database session object), character (CpResourceCharacter instance, role entity record, including fields such as id, default_voice_oss_key, default_voice_catalog_id).

[0104] 2. First source resolution (direct OSS path): Extract the default_voice_oss_key field (the OSS storage key for the voice directly configured for the character) from the character record, remove whitespace characters and record it as fk. If fk is not empty, skip the second source parsing and proceed directly to the URL conversion step.

[0105] 3. Second source parsing (voice catalog table rollback): If fk is empty but character.default_voice_catalog_id is not empty, convert catalog_id to an integer and record it as cid. Use id=cid, deleted=0, enabled=1 as filtering conditions to query the CpVoiceCatalogItem table to get the voice catalog and record row. If row exists and row.storage_key is not empty, remove the whitespace from storage_key and assign it to fk (get the OSS storage key from the voice catalog table).

[0106] 4. Null value handling: If fk is still empty after two source parsings, return an empty dictionary {} (indicating that there are no usable timbre resources for this character).

[0107] 5. URL Conversion: Call get_presigned_url(fk) to convert the OSS storage key into a temporary pre-signed access URL, denoted as url. Returns a dictionary {"file_url": fk, "url": url or ""}, where file_url is the original OSS storage key and url is the accessible pre-signed URL.

[0108] Step S33: OSS pre-signed URL generation (get_presigned_url) Source code location: utils / oss_url.py → get_presigned_url function Both _resolve_voice_payload_for_character and _get_base_image call get_presigned_url to convert the OSS storage key into a temporary accessible URL.

[0109] Execution logic and parameter flow: 1. Input parameters: key (string, the storage key of the object in OSS, such as "resource / character / 1 / xxx.png").

[0110] 2. Null value check: If the key is empty or is an empty string after removing whitespace, return None (URL cannot be generated).

[0111] 3. Non-OSS format detection: Remove spaces from the key and denote it as 'k'. Check the leading prefix of 'k': If k starts with "placeholder: / / " (placeholder format), return the original value of k directly (placeholders do not need to be pre-signed).

[0112] 4. OSS Pre-signed URL Generation: If k does not belong to the above non-OSS format, call... The `S3StorageClient().generate_presigned_url(k)` method sends a signature request to the OSS service to generate a time-sensitive temporary access URL for direct access by video generation and front-end rendering.

[0113] 5. Exception handling: If the generate_presigned_url call fails (such as a network error or permission issue), log a warning and return None (to ensure that subsequent processes can gracefully degrade).

[0114] 6. Output parameters: Returns a pre-signed URL string (normal case), a raw key string (non-OSS format case), or None (empty value / abnormal case).

[0115] Key logic explanation: For null or blank keys, return None directly. For non-OSS key formats starting with placeholder: / / , http: / / , or https: / / (i.e., already a complete URL or placeholder), return the original value directly without generating a pre-signature. For normal OSS keys, generate a temporary pre-signed URL using S3StorageClient().generate_presigned_url(k). This URL is time-sensitive and directly accessible for video generation and front-end rendering. If generation fails, return None and log a warning to ensure graceful degradation in subsequent processes.

[0116] Key Design: Dual-Source Voice Analysis: Prioritizes `default_voice_oss_key` (direct path), then falls back to `default_voice_catalog_id` → `storage_key` in the voice catalog table. The `voice_enrich_source="auto_character_voice"` flag distinguishes between automatic appending and manual binding. To prevent duplicate appending: use explicit_audio_ids (already manually bound) + already_auto_for (already automatically appended) for double deduplication.

[0117] Step S4: Persistent storage of the entity list: Step S41: JSONB Writing (save_storyboard_source_resources) Source code location: utils / storyboard_entity_parser.py → save_storyboard_source_resources function.

[0118] Execution logic and parameter flow: Dual-source timbre parsing: prioritize default_voice_oss_key (direct path), fall back to default_voice_catalog_id → storage_key of the timbre catalog table The voice_enrich_source="auto_character_voice" flag distinguishes automatic appending from manual binding Duplicate appending prevention: Dual deduplication via explicit_audio_ids (existing manually bound items) + already_auto_for (items that have been automatically appended)

[0119] 1. Input parameters: segment_id (integer, storyboard segment ID), entities (list, composed of the list of extended entity information dictionaries output by enrich_source_resources_with_character_voice, including character, scene, prop entity entries and automatically appended audio entries).

[0120] 2. Null value check: If entities is an empty list, return directly (no persistence required).

[0121] 3. Serialization: Call json.dumps(entities, ensure_ascii=False) to serialize the entities list into a JSON format string. ensure_ascii=False ensures that Chinese characters (such as "male lead", "dormitory") are retained in the original Unicode form instead of being escaped to ASCII.

[0122] 4. Database write: Using segment_id and deleted=0 as filter criteria, locate the corresponding segment record in the CpStoryboard table, write the serialized entities_json string into the source_resources field (Text type) of the record, use the update() method to perform a single record update, synchronize_session=False to avoid ORM session synchronization overhead, and call db.commit() to commit the transaction.

[0123] 5. Exception handling: If an exception occurs during the write process (such as database connection loss or field length exceeding limit), call db.rollback() to roll back the transaction and ensure database consistency.

[0124] 6. Output parameters: No explicit return value (the function returns None). After persistence is complete, the front-end and video generation pipeline can query the CpStoryboard record via segment_id and read the source_resources JSON field to obtain all entity information.

[0125] The `source_resources` field is a Text type, storing a JSON string containing all entity information (entity_id, type, reference image, and audio). It allows front-end rendering and video generation to directly read the data without requiring manual binding. The front-end read process is as follows: The front-end queries the CpStoryboard record using the `segment_id`, parses the `source_resources` JSON field, and renders the character reference image, scene reference image, prop reference image, and audio resource based on the type (character / scene / prop / audio) of each entry.

[0126] The overall technical effect of the three-step pipeline synergy: The technical effect produced by the combination of the three-step pipeline (S1→S2→S3→S4) surpasses the simple sum of the individual effects of each step. Specifically, it is reflected in the following causal chain: S1 constrains the @name format → S2 regular expression parsing has a clear anchor point → S2 fault tolerance compensates for the incompleteness of S1's LLM constraints → S3 adds timbre based on the entity_id produced by S2 for association query → S4 serializes all outputs of S2+S3 into JSONB for persistence → The front-end and video generation pipelines can directly read it without any manual intervention.

[0127] Textual descriptions of execution logic and parameter flow: All eight functions (build_resource_map, _get_base_image, build_resource_hint, generate_segment_node, parse_entity_mentions, save_segment_node, enrich_source_resources_with_character_voice, _resolve_voice_payload_for_character, get_presigned_url, save_storyboard_source_resources) supplement the complete textual description of "execution logic and parameter flow". Each function includes input parameters (type, meaning, source), step-by-step execution logic, key decision points (such as silent ignoring of regular expression matching failures, deduplication judgment for timbre appending, etc.), and output parameters (return value type, structure, downstream flow). The complete technical solution can be understood without relying on the code.

[0128] Predictability of combinations: S1 (injecting entity names into System Prompt) alone cannot completely eliminate custom names and does not generate persistent structured data. S2 (regular expression parsing @name) alone cannot guarantee that the LLM will be output in @name format; without the @name format constraint from S1, the hit rate of regular expression parsing will drop significantly. S3 (timbre appending) alone requires the entity_id produced by S2 to query the role table to retrieve the timbre and cannot run independently. S4 (JSONB persistence) alone requires the output of S2 + S3 to write complete information and cannot run independently. Only a four-step collaborative combination can achieve a complete closed loop from "LLM free text output" to "automatic binding of structured resources + persistent storage"; the absence of any step will lead to pipeline breakage.

[0129] Technical effect: The three-step pipeline combination achieves automatic cross-modal binding of text → image → audio. This is a technical effect resulting from the combination, not an independent technical feature. The front-end and video generation pipelines can directly read the source_resources field to obtain all resource information, achieving a complete closed loop with zero manual intervention.

[0130] The difference between this invention and CN122029536A: Microsoft CN122029536A only involves "injecting entity resource identifiers into hints to constrain LLM output," that is, it only has "pre-generation constraints" and not "post-generation fault-tolerant resolution." This invention forms a "prevention + fault tolerance" closed loop through the synergistic combination of S1 and S2. Specific differences are as follows: Figure 4 As shown.

[0131] The differences between this invention and CN120764523A: CN120764523A discloses a two-stage process architecture of "pre-injection constraint rules + post-output verification," which is similar in concept to the S1+S2 link of this invention—both are "pre-generation constraints + post-generation verification." However, there are five essential differences. This invention addresses specific alignment and fault tolerance at the semantic level (cross-dimensional collaboration: S1 anchor point supply + S2 fault tolerance compensation), and the technical problems they solve are fundamentally different. Furthermore, the non-obviousness argument for S1+S2 has been updated, such as... Figure 5 As shown.

[0132] The differences between this invention and other entity-linked patents are as follows: Figure 6 As shown.

[0133] Proof of the non-obviousness of the S1+S2 combination: From a trial-and-error cost perspective: Using S1 alone cannot completely eliminate custom names, and LLM, as a probabilistic model, does not adhere to the "prohibit custom names" directive 100%. Without combining it with the fault-tolerance mechanism of S2, the failure rate of entity recognition will lead to frequent failures in subsequent resource binding and video generation, requiring a large amount of manual correction. Using S2 (regular expression parsing) alone also cannot guarantee that LLM outputs entity mentions in the @name format, and the hit rate will drop significantly. Only by combining the two in a coordinated manner can reliable alignment be achieved at low cost.

[0134] Existing technologies lack similar combined solutions: A search revealed that none of the existing technologies, whether AI Agent orchestration frameworks (LangGraph and 5 others), entity linking patents (CN122029536A, CN121327044A, CN120181077B), or format verification patents (CN120764523A), provide a combined solution similar to this invention: "pre-generation @name entity constraint injection + post-generation @name regular expression parsing + fault tolerance ignoring." Microsoft's patent only involves pre-generation entity constraints without post-generation fault tolerance parsing; CN120764523A's pre- and post-processing are for format compliance rather than semantic alignment; and entity linking patents all rely on model inference rather than symbolic matching. The technical problems (semantic alignment + video model physical constraint adaptation), technical means (@name format + regular expression parsing + fault tolerance ignoring), and synergistic relationships (complementary closed loop rather than two-stage sequential processing) addressed by this invention have corresponding solutions in the existing technologies.

[0135] Contribution to the identification of technical problems: The technical problem solved by this invention is not limited to the general problem of "LLM output alignment with entities," but rather to the specific technical problem of "LLM output alignment under the specific physical constraint of video generation (hard upper limit on the number of reference graphs). The identification of this specific problem itself constitutes part of the inventive contribution—only by considering both LLM output alignment and the physical constraints of the video model simultaneously can the combined solution of "constraint injection + upper limit on the number of reference graphs + priority trade-offs + fault-tolerant resolution" be derived.

[0136] Difference from all other frameworks: None of the other frameworks have a collaborative closed-loop mechanism of "@name constraint before generation + @name resolution after generation".

[0137] Reference diagram hard upper limit constraint and priority rounding rules: Difference from all frameworks: No framework has a mechanism to "limit the number of entity references in the LLM output and round them down by priority".

[0138] The difference in this invention: STORYBOARD_MAX_REF_ASSETS=7 corresponds to the hard upper limit of the video model reference graph. It is not a general parameter, but a priority selection of the adaptation of the physical constraints of the video model (characters > scenes > props > discarding secondary scenes according to the order of appearance of script segments). It forms an adaptation combination of resource constraints and physical constraints of the video model. This constraint is injected into System Prompt through S1 and takes effect during the LLM generation stage, rather than being truncated after generation.

[0139] The following are several specific embodiments provided by us: Example 1: S1+S2 Core Closed Loop in Storyboard Generation In the storyboard generation scenario, S1 and S2 form the core closed loop, while S3 and S4 are further extended as preferred implementation methods: Step S1 (executed in generate_segment_node): Step S2 (executed in save_segment_node): After step S2 is completed, the entity list is available for use by downstream systems. S3 and S4 further expand the functionality as preferred implementations.

[0140] Step S3 (Preferred Extension): enrich_source_resources_with_character_voice to add character voice.

[0141] Step S4 (Preferred Extension): Persistent storage of save_storyboard_source_resources The entire process does not involve LLM and consumes zero tokens.

[0142] Example 2: Independent operation of the S1+S2 core closed loop The S1+S2 core closed loop does not depend on a specific pipeline derivation framework and can run independently in any scenario that requires LLM output to be aligned with structured resources.

[0143] The standalone operation mode is as follows: 1. Pre-build resource mapping table: Obtain entity data from the database or configuration file and build resource_map.

[0144] 2. Format constraint hint text: Call build_resource_hint to generate resource_hint and inject it into the System Prompt of any LLM call flow.

[0145] 3. LLM Generation: Call any LLM service (local deployment or API), and the LLM will generate text containing entity references under the @name constraint.

[0146] 4. Parsing and Mapping: The `parse_entity_mentions` function is called to parse the LLM output, match it with the `resource_map`, and generate a list of structured entities.

[0147] 5. Downstream Delivery: The entity list is available for direct use by video generation, front-end rendering, or any downstream system. The independent operation mode does not require any pipeline inference mechanism or specific framework support. It only relies on two inputs, resource_map and LLM output text, to complete entity recognition and resource mapping.

[0148] Example 3: Specific Data Examples Let's take a script containing 3 characters (male lead, roommate, and second female lead), 2 scenes (dormitory and classroom), and 1 prop (stinky socks) as an example: Step S1 output: [List of available themes for the current script (names must be referenced using @ in storyboards; custom names are prohibited)] Characters: @Male Lead, @Roommate, @Second Female Lead Scenes: @Dormitory, @Classroom Props: @StinkySocks Important Restriction: The number of unique @mentions in the full asset list must be ≤7. Priority: Characters > Scenes > Items. Adding @mentions outside the list is strictly prohibited.

[0149] LLM output: Scene 1: The male protagonist walks into the dormitory, carrying smelly socks... Scene 2: @Roommate sitting in @Classroom... Step S2 output: 5 entities (male protagonist character, dormitory scene, smelly socks prop, roommate character, classroom scene), each containing entity_id and reference image URL.

[0150] Step S3 output: 7 entries (5 entities + 2 automatically appended audio entries: male protagonist audio, roommate audio), voice_enrich_source="auto_character_voice" flag.

[0151] Step S4 output: 7 entries are serialized into JSON and written to the cp_storyboard.source_resourcesJSONB field.

[0152] The above description is only a preferred embodiment of the present invention. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention, and these will not affect the effectiveness of the implementation of the present invention or the practicality of the patent.

Claims

1. A method for semantic alignment between LLM output and structured resource system under constraints, characterized in that, The method is as follows: S1: Before generating content in the LLM, construct a resource mapping table, format all entity names in the resource mapping table into constraint prompt text according to category, and inject the constraint prompt text into the LLM System Prompt to constrain the LLM to only use existing names; at the same time, attach entity reference upper limit constraints and priority selection rules to the LLM that match the hard upper limit of the number of video model reference graphs. S2: Use the regular expression "@name" to parse the output text of LLM, and match the entity name in the parsing result with the entity name in the resource mapping table. When the match is successful, the complete information of the role entity corresponding to the entity name is retained; when the match fails, the entity name that failed to match is used as a custom name and the custom name is ignored, forming a fault tolerance compensation for the incompleteness of the above S1 constraint. S3: Collect manually bound timbre information for the character entity, query the manually bound timbre information to obtain the character's default timbre information, and add timbre entries to the character's default timbre information through dual-source timbre parsing; S4: Persistently store the list of entities corresponding to the entity names.

2. The method for semantic alignment of LLM output with structured resource systems under constraints, as described in claim 1, is characterized in that... In S1, the method for constructing the resource mapping table is as follows: The database is queried to identify three types of entities: character entities, scene entities, and prop entities. A basic reference diagram is obtained for each of these entities. A resource mapping table is then constructed based on the basic reference diagram, with the entity name as the key and the entity information as the value.

3. The method for semantic alignment of LLM output with structured resource systems under constraints according to claim 2, characterized in that, In S1, the priority selection rule is as follows: the character entity is set as the first priority, the scene entity is set as the second priority, and the prop entity is set as the third priority. Obtain the number of entities after silent ignoring in S2, and compare the number of entities with the hard upper limit of the number of video model reference images. If the number of entities is greater than or equal to the hard upper limit of the number of video model reference images, then prop entities are discarded first. If prop entities are discarded and the number of entities is still greater than or equal to the hard upper limit of the number of video model reference images, then secondary scene entities that appear later in the script segment are discarded.

4. The method for semantic alignment of LLM output with structured resource systems under constraints according to claim 1, characterized in that, In S1, the method for formatting all entity names in the resource mapping table into constraint hint text by category is as follows: The entity information in the resource mapping table is filtered to obtain three types of entity name lists, including a list of character entities, a list of scene entities, and a list of prop entities. These three lists of entity names are then used to create constraint prompt text.

5. The method for semantic alignment of LLM output with structured resource systems under constraints according to claim 1, characterized in that, In S2, the method for parsing the LLM output text using the regular expression "@name" is as follows: Obtain the storyboard text from the LLM output text, perform a findall operation on the storyboard text using the regular expression "@name", extract all Chinese and English character sequences following the "@" prefix in the storyboard text, and use the Chinese and English character sequences following the "@" prefix as the parsing result.

6. The method for semantic alignment of LLM output with a structured resource system under constraints, as described in claim 1, is characterized in that... In S2, the method for matching the entity names in the parsed results with the entity names in the resource mapping table is as follows: Initialize the seen set, iterate through each entity name in the parsed results. If the entity name is already in the seen set, the match is successful. Use the entity name as the key to search the resource mapping table. If the entity name is not in the resource mapping table, the match is unsuccessful.

7. A method for semantic alignment between constrained LLM output and structured resource systems according to claim 1, characterized in that, In S3, the method for appending timbre entries to the default timbre information of the character using dual-source timbre analysis is as follows: Extract the OSS storage key of the timbre that directly matches the character from the character entity, remove the whitespace characters from the OSS storage key, and when the OSS storage key with the whitespace characters removed is not empty, convert the OSS storage key with the whitespace characters removed into a temporary pre-signed access URL. When the timbre OSS storage key after removing the whitespace characters is empty, set the filter conditions, query the standard timbre directory table according to the filter conditions to obtain the timbre directory record, remove the whitespace from the storage key in the timbre directory record and assign it to the timbre OSS storage key after removing the whitespace characters, convert the assigned timbre OSS storage key into a temporary pre-signed access URL, and append the temporary pre-signed access URL to the list of role entities.

8. A method for semantic alignment between constrained LLM output and structured resource systems according to claim 1, characterized in that, In S3, the entity function component is called to collect manually bound timbre information for the character entity and skip automatic addition; an automatically added set is created, and the character's default timbre information is compared with the automatically added set. If the character's default timbre information is within the automatically added set, automatic addition is skipped.

9. A method for semantic alignment between constrained LLM output and structured resource systems according to claim 1, characterized in that, In S4, the method for persistently storing the entity list corresponding to the entity name is to serialize all the entity information into JSON and write it into the source_resources field of the storyboard record.

10. A method for semantic alignment between constrained LLM output and structured resource systems according to claim 9, characterized in that, The source_resources field stores JSON format strings, and each entry of the JSON format string includes the entity database ID, entity type, reference graph record ID, OSS storage key, and pre-signed access URL.

Images