合并分支
* Merge branch 'main' into feature/cluster-gemini * PERF prompt存储在secrets中以便更改 * Merge remote-tracking branch 'origin/main' into feature/cluster-gemini * FIX 修复webhook导致modal状态无法正常透传问题 * Merge branch 'main' into cluster-gemini * PERF 尝试修复gemini推理超出思考token上限的问题 --------- Merge request URL: https://g-ldyi2063.coding.net/p/dev/d/modalDeploy/git/merge/4813 Co-authored-by: 康宇佳
This commit is contained in:
Coding
@@ -24,6 +24,7 @@ with downloader_image.imports():
|
||||
|
||||
@app.function(cpu=(0.5, 64), timeout=1800,
|
||||
max_containers=config.video_downloader_concurrency,
|
||||
secrets=[modal.Secret.from_name("gemini-prompt")],
|
||||
volumes={
|
||||
config.S3_mount_dir: modal.CloudBucketMount(
|
||||
bucket_name=config.S3_bucket_name,
|
||||
@@ -250,7 +251,8 @@ with downloader_image.imports():
|
||||
async def inference_api():
|
||||
try:
|
||||
logger.info("请求推理接口")
|
||||
product_list_str = "，".join(product_title_list)
|
||||
prompt = os.environ["prompt_text"]
|
||||
logger.info(f"Prompt text: {prompt}")
|
||||
image_parts.extend([
|
||||
{
|
||||
"file_data": {
|
||||
@@ -259,122 +261,7 @@ with downloader_image.imports():
|
||||
}
|
||||
},
|
||||
{
|
||||
"text": """<prompt>
|
||||
<instruction>
|
||||
你是一个专业的AI视频分析师。你的任务是根据提供的视频、多张商品图片网格和商品列表，精确识别直播中展示的商品及其对应的时间线。
|
||||
|
||||
**核心任务**：严格遵循分析流程，同时主动管理内部思考过程的Token消耗，确保分析的深度和效率，避免超出限制65535。
|
||||
|
||||
---
|
||||
### 零阶段：元分析与Token管理策略
|
||||
|
||||
**目标**：在开始正式分析前，预估任务复杂度并制定思考策略。
|
||||
|
||||
1. **输入评估**：快速扫描输入材料，评估关键复杂度指标：
|
||||
* `视频时长`：视频的总分钟数。
|
||||
* `商品数量`：多张图片网格中待分析的商品总数。
|
||||
2. **策略选择**：根据评估结果，选择思考的详细程度：
|
||||
* **高复杂度（如 >10分钟视频 或 >20个商品）**：**必须采用“摘要式”思考**。在内部思考过程中，仅记录关键决策点，省略详细的描述性文字。例如，用“商品A：四维验证通过”代替详细的验证过程描述。
|
||||
* **低复杂度**：可以使用较详细的思考过程，但仍需保持简洁。
|
||||
3. **全程监控**：在后续所有阶段，持续关注思考过程的长度，确保总Token消耗在安全范围(小于65535)内。
|
||||
|
||||
---
|
||||
### 第一阶段：图片解析与候选建立
|
||||
|
||||
**目标**：仅基于商品图片网格，建立一个可靠的候选商品数据库。
|
||||
**商品列表（标准名称参考）：** {0}
|
||||
1. **独立分析图片**：完全忽略视频和商品列表内容。
|
||||
2. **扫描网格区域**：从左上角开始，按行顺序扫描每个黑色边框的商品区域。
|
||||
3. **提取与编号**：为每个区域分配一个从1开始的连续序号 (`image_order`)。精确提取区域内的商品名称文字。
|
||||
4. **初步匹配**：将提取的文字与提供的`商品列表`进行高相似度匹配。
|
||||
5. **生成候选列表**：创建一个包含所有成功匹配项的候选列表，记录其`image_order`、图片原文`image_name`和匹配到的标准名称`matched_list_name`。匹配失败的项在此阶段被丢弃。
|
||||
|
||||
---
|
||||
### 第二阶段：多模态交叉验证
|
||||
|
||||
**目标**：对第一阶段生成的候选列表中的每一项进行严格的多模态一致性验证。
|
||||
|
||||
1. **限定分析范围**：只分析候选列表中的商品，绝不添加新商品。
|
||||
2. **逐项验证**：按`image_order`顺序，对每个候选商品进行验证。
|
||||
3. **四维一致性检查**：
|
||||
* **商品名称 (Material/Style)**：分析`matched_list_name`中包含的材质（如纯棉、莱赛尔）和款式信息。
|
||||
* **图片特征 (Image)**：**重新仔细观察**图片网格中对应`image_order`位置的商品，记录其真实的视觉特征（颜色、图案、领型、袖型等）。
|
||||
* **视频内容 (Video)**：在视频中找到主播展示该商品的片段，观察其动态效果、版型、和上身细节。
|
||||
* **主播语音 (Voice)**：识别主播对该商品的口头描述，包括材质、卖点和款式特征。
|
||||
4. **决策**：以上四个维度的信息必须高度一致。如果存在明显矛盾（如图片为V领但视频中为圆领，或主播描述的材质与商品名不符），则该商品未通过验证，必须被移除。
|
||||
|
||||
---
|
||||
### 第三阶段：时间线生成与最终输出
|
||||
|
||||
**目标**：为所有通过验证的商品生成精确的时间线，并构建最终的JSON输出。
|
||||
|
||||
1. **确认最终清单**：整理所有通过第二阶段验证的商品。
|
||||
2. **时间线分析**：
|
||||
* 为每个确认的商品，在视频中定位所有相关的出现时间段。
|
||||
* 合并碎片化的时间段。
|
||||
* 为每个时间段标注内容类型：`(穿着本品+介绍本品)`、`(穿着本品+他品)` 或 `(穿着本品+无关)`。
|
||||
3. **生成JSON**：按照指定的格式生成最终的JSON数组。确保`product`字段值与`matched_list_name`完全一致，且数组顺序严格遵循`image_order`。
|
||||
|
||||
</instruction>
|
||||
|
||||
<rules>
|
||||
<!-- 核心逻辑 -->
|
||||
<rule>**Token管理优先**：必须将零阶段的“元分析与Token管理策略”作为首要任务。思考过程的简洁性是成功完成任务的关键。</rule>
|
||||
<rule>**阶段性执行**：必须严格遵循"图片解析 → 交叉验证 → 时间线生成"的顺序。后一阶段的输入必须是前一阶段的输出。严禁跨阶段操作。</rule>
|
||||
<rule>**图片基准原则**：所有分析的起点必须是图片网格中带黑色边框且有文字的商品。输出的商品数量不得超过符合条件的图片区域数量。</rule>
|
||||
<rule>**位置严格对应**：在第二阶段验证时，必须重新观察并确保描述的图片特征与`image_order`所指向的网格位置的商品完全一致，严禁混淆不同位置的商品特征。</rule>
|
||||
<rule>**一致性否决**：在第二阶段，任何一个维度（名称、图片、视频、语音）出现明显不一致的商品，都必须被淘汰。宁缺毋滥。</rule>
|
||||
<rule>**同款保留**：如果视频中出现同一款式的不同颜色或图案版本，并且它们在图片网格和商品列表中都存在，则必须全部识别并保留。</rule>
|
||||
|
||||
<!-- 输出格式 -->
|
||||
<rule>**JSON结构**：输出必须是JSON数组`[]`。每个商品对象`{{}}`包含`match_info`、`product`和`timeline`三个键。</rule>
|
||||
<rule>**名称规范**：`product`和`matched_list_name`字段的值必须100%来自提供的`商品列表`中的标准名称。</rule>
|
||||
<rule>**时间戳格式**：时间格式必须为`HH:MM:SS.mmm - HH:MM:SS.mmm`。例如，`00:05:23.500`代表5分23.5秒。</rule>
|
||||
<rule>**时间线标签**：每个时间段后必须附带内容类型标签，如`(穿着本品+介绍本品)`。</rule>
|
||||
|
||||
<!-- 识别精度 -->
|
||||
<rule>**多模态线索**：综合利用主播的手势、视线、身体动作以及语音中的关键词（如商品名、特征词）和语气变化，来精确定位商品介绍的起止时间点。</rule>
|
||||
<rule>**画面内容**：时间线片段中不能包含主播不在画面的内容。</rule>
|
||||
<rule>**多商品同框**：如果一个画面内同时演示多个不同的商品，需将它们的活动时间线精确地分配到各自的商品条目中。</rule>
|
||||
</rules>
|
||||
|
||||
<examples>
|
||||
<example_process>
|
||||
**零阶段：元分析与Token管理策略**
|
||||
- **评估**：视频时长25分钟，商品数量30个。
|
||||
- **决策**：复杂度高。启用“摘要式”思考模式。内部思考必须极为精简。
|
||||
|
||||
**第一阶段：图片解析与候选建立**
|
||||
- **思考（摘要式）**：“开始图片解析。扫描30个区域。与列表匹配。候选列表生成完毕。”
|
||||
- **输出（候选列表示例）**：
|
||||
- 正确 `image_order: 1`, `image_name: "FORNI Baby tee..."`, `matched_list_name: "6月12日...T恤"`
|
||||
- 错误 `image_order: 2`, `image_name: "FORNI 三明治空气裤"` → 无匹配，丢弃。
|
||||
|
||||
**第二阶段：多模态交叉验证**
|
||||
- **思考（摘要式）**：“开始交叉验证。逐项处理候选列表。序号1：四维一致。通过。序号3：四维一致。通过。序号5：视频与图片不符。淘汰。”
|
||||
|
||||
**第三阶段：时间线生成与最终输出**
|
||||
- **思考（摘要式）**：“验证完毕。开始为通过项生成时间线。输出JSON。”
|
||||
- **输出（最终JSON）**：
|
||||
```json
|
||||
[
|
||||
{{
|
||||
"match_info": {{ "image_order": 1, ... }},
|
||||
"product": "6月12日16:00新品 FORNI Baby tee 高克重100纯棉V领正肩修身T恤",
|
||||
"timeline": ["00:01:15.200 - 00:02:30.800 (穿着本品+介绍本品)"]
|
||||
}}
|
||||
]
|
||||
```
|
||||
</example_process>
|
||||
<reason>
|
||||
此流程的优势在于：
|
||||
- **主动管理**：通过“零阶段”的预评估，模型能主动适应任务复杂度，从根本上避免`thoughtToken`超限。
|
||||
- **高效**：“摘要式”思考让模型能将计算资源集中于核心逻辑判断，而非繁琐的内部记录，处理复杂任务时更高效。
|
||||
- **鲁棒**：在保留原有三阶段验证流程的严谨性基础上，增加了对自身资源消耗的监控，使整个系统更加稳定可靠。
|
||||
</reason>
|
||||
</examples>
|
||||
</prompt>
|
||||
""".format(product_title_list)
|
||||
"text": prompt.format(product_title_list)
|
||||
}
|
||||
])
|
||||
json_data = {
|
||||
|
||||
Reference in New Issue
Block a user