讓我們繼續Day19 的議題吧~~
為了模擬真實舞者所擁有的「舞蹈的記憶」、「風格選擇能力」、「經驗累積」,
Tutting 模擬器需要能夠隨著時間累積記憶、學習偏好,要實現這一點必須替模擬器打造一個資料庫系統,作為「舞蹈記憶」的容器。
為了儲存複雜的舞蹈數據,並因應不同操作需求,本研究採用 SQL 與 NoSQL 混合架構:
{
"_id": "action_001",
"name": "Box Pose",
"category": "Box",
"default_skeleton": {
"joint_angles": [45, 90, 30, ...],
"control_points": [...]
},
"recommended_combinations": ["Line Pose", "Slide Pose"],
"metadata": {
"difficulty": 3,
"style_tags": ["geometric", "sharp"]
}
}
{
"_id": "rhythm_001",
"action_id": "action_001",
"type": "Bounce",
"intensity": 0.8,
"frequency": 1.2,
"duration": 2.5
}
CREATE TABLE Dancer (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(50),
role VARCHAR(20),
precision FLOAT,
creativity FLOAT,
stamina FLOAT,
preferred_actions JSON,
preferred_rhythms JSON,
growth_curve JSON
);
{
"_id": "history_001",
"dancer_id": 1,
"dance_sequence": [
{"action_id": "action_001", "rhythm_id": "rhythm_002"},
{"action_id": "action_003", "rhythm_id": "rhythm_005"}
],
"generated_time": "2025-08-21T10:00:00Z",
"evaluation": {
"success_rate": 0.92,
"audience_score": 4.7,
"internal_score": 0.85
}
}
在 Tutting 模擬器的資料庫設計上,其實單靠 SQL 或 NoSQL 都不夠。
最佳做法是 混合式架構:
這樣能同時兼顧 資料一致性 與 彈性擴充,更符合「模擬真實舞者」的需求。
最終,我們希望這個資料庫不只是一個「資料倉庫」,而是能讓 AI 舞者藉由查詢與更新,真正地「成長」與「展現風格」。