翻訳について：2026年10月22日に公開されたVaneブログの中国語記事と英語記事に基づく日本語版です。 本文、表、図中のラベル、画像の説明を翻訳し、図5点を日本語で描き直しました。 動画投稿者名、数値、時刻、出典の関係を保持し、動画の画面には元の画像を使用しています。 操作画面の図は翻訳して再構成した説明図であり、日本語版アプリの実行画面ではありません。 実行可能なコード例は英語記事のまま保持し、文書への相対リンクを絶対URLに変更しています。
同じレビューの話題を複数の動画が扱っていても、テスト内容や着目点は異なることがあります。 特定の問いに答えるには、関連する場面を探し、何をどの条件で試したのかを把握する必要があります。 この記事ではVane DataとHawDBを使った実験を紹介します。 字幕と映像から発言を抽出し、テスト条件が比較を許すかを確認しながら、元の動画へ戻れる参照を残します。
このアプリケーションでは、字幕、フレーム、モデルの出力と一緒に出典情報を扱います。 Vane Dataはメディアの読み取りと構造化されたモデル呼び出しを、HawDBは根拠資料と出典の関係の保存を担当します。 検索、参照の検証、バージョン管理はアプリケーションが組み合わせます。
この実験の読み方
この概念実証（PoC）では、実行時の自動分析結果と、その後に元動画を見直して確認した結果を区別しています。 デモの要約や視聴案内は事前に整理したものであり、動画全体の分析をリアルタイムで生成しているわけではありません。 コード例は主要な手順を示し、ファイルパス、候補の区間、モデル設定はアプリケーションから与える前提です。 データベースへの取り込み、サービス設定、完全なエラー処理は省略しています。 以下の操作画面の図は、元の中国語デモを日本語に翻訳して描き直したものです。
複数動画の比較から始める
比較にはMediastorm（影视飓风）とGeekerwan（极客湾）の字幕区間を使います。 フレームの抽出とテスト時間の違いを示す例には、Zhong Wenze（钟文泽）とHe Tongxue（何同学）の動画も使います。
デモは4本の動画をまとめた視聴ガイドです。 バッテリー持ちや動画撮影などの話題を入力すると、各投稿者が何を扱っているかを確認でき、該当する場面を開いて発言やテスト条件を確かめられます。
元の中国語デモを日本語に翻訳して再構成した説明図です。投稿者名、時刻、元資料を保持しています。
ガイドでは要約と動画区間へのリンクを話題別、投稿者別にまとめます。 以下のフィールドと比較ラベルは、実際に行った分析の結果です。 元資料と照らし合わせると、抽出できた情報と見落とした情報を確認できます。
iPhone 18の発熱に関する、この2つの報告は直接比較できるか
検索と比較に使った問いは次のとおりです。
iPhone 18 Proの冷却性能の改善には、どのような利点とトレードオフがありましたか？
システムは発熱に関する2つの区間を見つけました。 しかし、後から元動画を確認すると、その一方が扱っていたのは、問いで指定したiPhone 18 ProではなくDuoでした。 比較するには、各区間で扱う機種とテスト方法を確認する必要があります。
下の表は、人による確認の結果です。 後の節では当初の自動抽出フィールドとラベルを残し、モデルが何を見落としたかを示します。
| 出典 | 動画で述べている内容 | 元動画の確認位置 |
|---|---|---|
| A：Mediastorm | Duoで約3分間4K60動画を撮影した後の局所的な発熱と持ち心地を説明し、ほとんど持てないほど熱いと述べる | 12:46–13:16。12:47の画面字幕にDuoと明記されている |
| B：Geekerwan | 前面表面の熱平衡温度を約44–45°Cと説明。グラフでは、30分間の高負荷ストレステスト後のiPhone 18 Pro Maxが44.3°C、17 Pro Maxが45.2°C | 17:23–17:37。テスト時間の説明は17:08以降の前後の字幕にある |
この2つの区間は異なる機種とテスト場面を扱っています。 投稿者同士の結論が矛盾していると判断する根拠にはなりません。
当初の参照範囲は不十分でした。 Aは12:53から始まり、投稿者がDuoと述べた場面が含まれていませんでした。 Bには温度の説明が入っていたものの、その前の「30分間のストレステスト」という条件が抜けていました。 機種と条件の特定には、前後の字幕と映像が必要でした。
このワークフローでは字幕とフレームを出典付きで保存し、問いに関連する区間を検索して、比較する発言を抽出します。 各結果には、引用した場面へ戻るための参照を残します。
Vane DataとHawDBの役割分担
Vane DataはAI処理向けのマルチモーダルデータエンジンです。 画像、動画、テキストを処理してモデルに渡すためのPythonとSQLのインターフェースを提供します。
このPoCでは、Vaneで動画フレームを読み、モデルを呼び出して字幕と画像から発言やテスト条件を抽出し、比較可能かを評価します。 アプリケーションはこれらの手順を実行し、返されたフィールドと参照を元資料に照らして検証します。
Vaneでは動画フレームをタイムスタンプ付きの行として扱います。 モデル呼び出しはテキスト列と画像列を受け取り、構造化されたフィールドを返します。 アプリケーションは列の選択とArrowによるデータ交換で各手順をつなぎ、抽出した条件、観察結果、参照を検証します。
HawDBはRustで書かれたマルチモーダル組み込みデータベースで、Cypherクエリとトランザクションによる読み書きを提供します。 このPoCでは、動画のメタデータ、字幕、フレーム分析の記録、出典の関係、処理バージョンを保存します。 意味検索を有効にした場合には、テキストとベクトルも保存して類似度クエリを実行します。 HawDBはアプリケーション内でローカルに動作するため、別のデータベースサービスは必要ありません。
グラフクエリは、その記録がどの投稿者、動画、処理実行に由来するかを答えます。 ベクトル検索は、どの記録が現在の問いに関連するかを答えます。 根拠資料の識別子で両者をつなぐことで、検索結果から出典をたどれます。
| 段階 | ツールが提供するもの | アプリケーションが制御するもの |
|---|---|---|
| フレームの準備 | Vaneが動画フレームと時刻をバッチで返す | サンプリング間隔、画像サイズ、PNG出力、画面内テキストの認識 |
| 意味検索（任意） | FastEmbedがベクトルを生成。HawDBがテキスト、ベクトル、出典メタデータを保存し、類似度クエリを実行 | チャンク分割、インデックスのバージョン、候補区間の選択 |
| 抽出と比較 | Vaneがテキストと画像の入力、構造化出力を整理 | 候補資料、プロンプト、フィールドの検査、参照の検証 |
| 保存と出典確認 | HawDBが根拠資料と出典の関係を保存し、トランザクションで読み出す | 元資料のバージョン、参照から動画の位置へのリンク、キャッシュ |
元動画と抽出したPNGファイルは、ローカルのファイルシステムに置きます。 Rustプログラムが字幕とフレーム分析の記録をJSONLからHawDBへ取り込みます。 比較結果は、使用した元資料のバージョンとともにアプリケーションがJSONとして保存します。
以下では、フレームの読み取りと保存から、検索、抽出、比較までのデータの流れを追います。
出典をたどれるマルチモーダル処理を組み立てる
資料を集めて構造化する
AとBには、どちらも字幕があります。 取り込み時には元の文面と開始時刻、終了時刻を保持します。 字幕がない動画にはfaster-whisperで文字起こしを行います。 グラフや画面内の文字を読むためにフレームをサンプリングして画像認識に渡し、フレーム時刻と保存画像のパスを残します。
次の例ではVaneで5秒ごとに1フレームを読み、ミリ秒のタイムスタンプを名前にしたPNGとして保存します。
video_pathはローカル動画のパス、output_dirは事前に用意した空のディレクトリです。
ここではframe_limitを指定していません。
from pathlib import Path
from PIL import Image
import vane
con = vane.connect()
height, width = 720, 1280
frames = vane.read_video_frames(
video_path, image_height=height, image_width=width,
sample_interval_seconds=5.0,
connection=con,
)
with frames.select("frame_time", "data").to_arrow_reader(batch_size=4) as reader:
for batch in reader:
times = batch.column("frame_time").to_pylist()
for timestamp, frame in zip(times, batch.column("data"), strict=True):
pixels = frame.value.values.to_numpy().reshape(height, width, 3)
path = Path(output_dir) / f"{round(timestamp * 1000)}.png"
Image.fromarray(pixels).save(path)frame_timeの単位は秒です。
data内のRGBピクセルを指定した画像サイズに並べ直します。
batch_size=4は1バッチ4フレームという意味であり、合計フレーム数の上限ではありません。
APIの入力サイズとデコードフレーム数の安全上限は引き続き適用されます。
後の例ではconを再利用し、処理終了後にcon.close()を呼び出します。
選択した各フレームはVane上の1行であり、frame_timeが時刻列、dataが画像列です。
アプリケーションは両方の列を選び、動画から抽出する全フレームを先に集めることなく、Arrowのバッチとしてピクセルを読み出します。
画像とタイムスタンプが同じ行にあるため、後のモデル出力からフレーム時刻をたどれます。 この例では読者が確認できるようにPNGを保存しています。 Vaneが担当するのは、フレームの読み取り、列の選択、バッチ出力です。
続いてアプリケーションはVane経由でモデルを呼び出して画面内の文字を認識し、動画の出典、フレーム時刻、PNGのパスを記録します。 これらの結果は字幕とともに保存し、検索と比較に使います。 インターフェースはread_video_framesのドキュメントを参照してください。
5秒間隔のサンプリングでは、短時間しか表示されないグラフを見逃すことがあります。 1秒または2秒間隔なら詳しく確認できますが、保存容量と認識処理のコストが増えます。 それでも細部を取りこぼす可能性は残ります。
例えば、システムはZhong Wenzeの動画の16:48.583のフレームから、iPhone 18 Pro Maxで15分間4K120動画を撮影するとバッテリーを4%消費したと読み取りました。 元動画を確認すると、条件が1つ抜けていました。 比較したiPhone 17 Proのバッテリー最大容量は98%で、ほかの3台は100%だったのです。 保存画像があるため、この見落としを確認できます。 バッテリー消費の数値だけでは、冷却性能を判断できません。
根拠資料、バージョン、出典の関係を保存する
アプリケーションは字幕とフレームの記録を、HawDB用のRustインポーターに渡します。
各根拠レコードにはテキストまたはフレーム分析結果、タイムスタンプ、コンテンツハッシュを保存します。
run_idで処理バージョンを表すRunに関連付けます。
データベースには投稿者、動画、区間の関係も記録します。
このPoCではsrc/corpus.rsにある次のCypherクエリで、投稿者、動画、Runを読み出します。
ここでは読みやすい形に整形しています。
MATCH (a:Author)-[:PUBLISHED]->(v:Video)-[:PROCESSED]->(r:Run)
RETURN a.payload AS author, v.payload AS video, r.payload AS run
ORDER BY v.id, r.id
LIMIT 1001PUBLISHEDは投稿者と動画を、PROCESSEDは動画とRunをつなぎます。
アプリケーションは取得したRun識別子を使って根拠資料を読みます。
MATCH (e:Evidence)
WHERE e.run_id IN $runs
RETURN e.payload AS payload
ORDER BY e.run_id, e.start_ms, e.id
SKIP $offset LIMIT $limit$runsは直前のクエリで取得した値であり、$offsetと$limitでページ分割を制御します。
グラフクエリで出典を確定し、プロパティの条件で該当Runの根拠資料を選択します。
どちらもHawDBのクエリインターフェースを使います。
各レコードは、投稿者、動画、処理バージョンと一緒に参照できます。
字幕やサンプリング設定が変わったら、アプリケーションは新しいRunを作成し、古いバージョンを保持します。
比較の前に完了済みのRunを選び、run_idで根拠資料を読み出します。
この選択したバージョンの資料一式を、元資料のスナップショットとします。
検索前に、すべての根拠資料をHawDBの1つの読み取りトランザクションで取得します。 各比較は使用した元資料のバージョンを記録するため、その後に字幕を更新しても当時の根拠資料を確認できます。
HawDBの読み取りトランザクションは、出典の関係とページ分割された根拠資料を、読み出し中に一貫した状態に保ちます。 履歴バージョンの保持はアプリケーションの責任です。 いつRunを作るか、どう命名するか、いつまで残すかをアプリケーションが決めます。
検索結果から構造化された分析へ
候補となる区間を検索して選ぶ
アプリケーションは問いごとに、保存した字幕とフレーム記録を検索します。 字幕の各キューを区間にまとめ、文脈を補うために前後のキューを加え、同じ時間帯のフレームを関連付けます。
キーワード照合には、タイトル、字幕、フレームから認識したテキストを使います。 意味検索を有効にした場合、FastEmbedで資料と問いをベクトル化します。 HawDBはテキスト、ベクトル、出典メタデータを保存し、類似度クエリを実行します。 アプリケーションがキーワードとベクトルのスコアを組み合わせて候補区間を選び、順位を付け、モデルの入力予算内に収まる資料を渡します。
各処理バージョンには対応する検索インデックスがあり、元の記録から再構築できます。
検索レコードにはチャンク識別子、テキスト、ベクトル、出典メタデータを持たせます。
字幕や画面テキストのチャンクにはevidence_id、video_id、run_id、kind、start_msを残します。
チャンク識別子は根拠資料の識別子とチャンク番号を組み合わせ、検索結果を元の根拠資料に結び付けます。
FastEmbedはPythonでベクトルを計算します。
Rustインポーターは、HawDBのSearchDocumentを通じてテキスト、ベクトル、メタデータを書き込みます。
HawDBがベクトル類似度クエリとメタデータのフィルターを担当し、アプリケーションがヒットを動画の区間にまとめます。
埋め込みモデルがなければ、検索はキーワードだけで行います。 次のクエリは任意で利用できるベクトル検索の例であり、後で説明する比較実行とは別の例です。
use hawdb::{SearchMode, SearchQueryOptions};
use std::collections::BTreeMap;
let result = index.search_with_options(
"",
Some(&query_vector),
SearchMode::Vector,
SearchQueryOptions {
limit: document_count,
offset: 0,
rank_window: None,
fusion_weights: Default::default(),
metadata_filters: BTreeMap::from([("video_id".into(), video_id)]),
policy_epoch: None,
},
)?;
let hits: Vec<_> = result.hits.into_iter()
.map(|hit| (hit.id, hit.vector_score))
.collect();indexには選択したバージョンの記録が入っています。
FastEmbedがquery_vectorを生成して正規化します。
インデックスがデータの対象範囲を定め、video_idで動画を絞り込みます。
ここではインデックス内の総文書数document_countを取得上限にし、アプリケーション側でキーワードスコアと合わせて順位を付けるためのベクトルスコアを取得します。
hitsにはチャンク識別子とベクトルスコアが入ります。
アプリケーションは元レコードを引き、対応する字幕区間にスコアを割り当てます。
こうして得られるpassagesは、それぞれ識別子、キューの一覧、時間範囲、関連フレームを持ちます。
これはSearchMode::Vectorを使う例であり、キーワードとベクトルのスコアを組み合わせるのはアプリケーションです。
チャンク分割や埋め込みモデルを変更したら、対応するインデックスの再構築が必要です。
元の根拠資料と出典の関係は、そのまま保持できます。
発言を構造化して抽出する
アプリケーションは関連区間をVane経由でモデルに渡し、動画ごとに発言を抽出します。 各発言には、1つの観察結果または評価、テスト条件、比較対象の機種、不確実な点、根拠となる字幕キューへの参照を記録します。 機種を特定できない場合など、情報がない項目は空のままにします。
この字幕の例では、passagesと問いをリクエストテーブルに入れます。
フィールドはレビュー用途向けに定めたもので、ほかの話題では変更できます。
アプリケーションがmodel_optionsにプロバイダー、モデル、実行オプションを設定します。
詳細はPrompt APIを参照してください。
conは先ほどの接続です。
返されるevidence_idは、入力した区間のidを参照します。
first_cueとlast_cueは、その区間内のキューを1から数えた番号で、両端を含みます。
アプリケーションはこれらを使って元のテキストと時刻を取得します。
以下のコードでは、英語記事に掲載された、中国語の例示プロンプトの英訳をそのまま残しています。 翻訳したプロンプトでは出力が変わる可能性があります。 報告された実行を再現するには、当時の元プロンプト、モデル、コード、入力が必要です。
import json
import pyarrow as pa
from pydantic import BaseModel, ConfigDict
class Statement(BaseModel):
model_config = ConfigDict(extra="forbid")
evidence_id: str
first_cue: int
last_cue: int
target_model: str | None
observed_result: str | None
evaluation: str | None
comparison_objects: list[str]
conditions: list[str]
uncertainties: list[str]
class Statements(BaseModel):
model_config = ConfigDict(extra="forbid")
selections: list[Statement]
request = {
"question": question,
"passages": [
{
"id": passage["id"],
"cues": [
[number, cue["text"]]
for number, cue in enumerate(passage["cues"], start=1)
],
}
for passage in passages
],
}
relation = con.from_arrow(pa.table({
"text": [json.dumps(request, ensure_ascii=False)],
}))
result = vane.ai.prompt(
relation, vane.col("text"),
return_format=Statements,
system_message=(
"Extract supported statements relevant to the question, one point per statement. "
"Preserve the subject, conditions, numeric units, and source uncertainty. "
"Use only supplied evidence identifiers and locations; do not mix sources. "
"Set evidence_id to the passage id. Use the passage's subtitle numbers for "
"first_cue and last_cue, inclusive at both ends. "
"Return the requested structure, with null or [] for missing information. "
"Do not add information outside the supplied material."
),
**model_options,
)
extracted = Statements.model_validate(result.select("response").fetchone()[0])return_formatは出力構造を指定します。
responseを読み出すとモデル呼び出しが実行され、その後にアプリケーションが結果を検査します。
動画フレームは別途画像入力として渡し、識別子とタイムスタンプで元動画内の位置を特定します。
con.from_arrow()はリクエストテーブルを作り、vane.col("text")は入力列を選択します。
vane.ai.prompt()でモデル呼び出しと戻り値の構造を宣言し、テーブルのresponse列から結果を読み出します。
この例では、候補区間のまとまりを1行のテキストに入れています。
完全な実装では、task_id、text、imagesを持つテーブルにタスクをまとめ、テキスト列と画像列を一緒に送り、タスク識別子ごとに結果を回収します。
Vaneはマルチモーダルな列入力と結果の読み出しを提供します。
タスクの分け方、プロンプト、入力予算、完全性の検査はアプリケーションが制御します。
Statementsの各フィールドには用途があります。
conditionsは比較可能性の検査に使います。
observed_resultとevaluationは、観察結果と投稿者による評価を分けます。
evidence_idとキュー番号は引用テキストを特定します。
アプリケーションは各フィールドを調べられますが、正確さは元資料に照らして確認する必要があります。
アプリケーションは各区間の識別子が現在の入力に含まれるか、キューの範囲が有効かを検証します。
その後に元のテキストと時刻を取得し、run_idを付け、前後にキューを1つずつ加えます。
元資料で裏付けられないフィールドは削除し、部分的な抽出失敗として記録します。
当初の実行は、字幕に存在する情報を見落としました。 Mediastormは約3分間の4K60撮影に触れていましたが、モデルはテスト条件に含めませんでした。 Geekerwanは約44–45°Cと述べていましたが、モデルはそれを観察結果として抽出できませんでした。 どちらも発言の比較に関わるため、元字幕も比較入力に残します。
根拠資料と比較可能性を検証する
比較モデルは、抽出フィールド、引用テキスト、不確実な点を合わせて検討します。 未確認の情報を事実として扱ったり、テスト条件を作り足したりすることはできません。
まず機種、指標、条件を調べ、comparabilityに記録します。
comparableは直接比較を裏付ける根拠があること、different_conditionsは機種や主要条件が異なること、unknownは根拠が不足していることを示します。
欠けている条件を同一だと仮定してはいけません。
次にrelationで、一致、矛盾、相互補完、関係未確定に分類します。
これもvane.ai.prompt()の呼び出しですが、入力、指示、出力構造を変えています。
アプリケーションは参照の有効性、発言が異なる動画に由来すること、一致または矛盾のラベルがcomparableの条件を満たすことを検証します。
これらはアプリケーションのルールであり、モデルの判断には引き続き元資料の確認が必要です。
当初のAとBの比較は、次の結果を返しました。
{
"comparability": "different_conditions",
"relation": "undetermined"
}モデルは主に負荷の種類と、発熱が観察された箇所の違いを判断の根拠にしました。 具体的な機種は特定できていませんでした。 DuoとPro Maxの違いは後から元動画を見直して分かったもので、自動分析の結果には含まれていません。
時間も比較を左右します。 Zhong Wenzeは16:38–16:59で、15分間の4K120撮影テストを示しています。 He Tongxueは11:17–11:28で、iPhone 16、17、18 Pro Maxによる30分間の4K120撮影後の温度を比較しています。 撮影モードは同じでも時間が違うため、両者の温度を直接比較することはできません。
結果から根拠資料へ戻る
アプリケーションは問い、双方の発言、比較ラベル、限界をJSONとして保存します。
各発言には動画、元資料のrun_id、原文、タイムスタンプを残し、ページ上で参照先を特定できるようにします。
字幕の再生では、文脈を補うために検索した区間の前後を最大3秒ずつ広げます。 フレーム参照では該当時刻へ移動し、元画像を表示できます。 過去の結果は、その時点の元資料バージョン、処理設定、資料を保持します。
Aの「約3分間の4K60撮影」という参照を追うと、各段階のデータのつながりが分かります。 この表は、当初の実行で任意のベクトル検索を使ったことを意味しません。
| 段階 | 次へ渡すデータ | 目的 |
|---|---|---|
| 資料の保存 | 元字幕、開始時刻と終了時刻、根拠識別子、run_id | HawDBが根拠資料と元資料バージョンを保持し、アプリケーションから読み出せるようにする |
| 候補区間 | 区間識別子、順序付き字幕キュー、関連フレーム | アプリケーションがモデル入力を準備する |
| Vaneによるモデル呼び出し | evidence_id、first_cue、last_cue、抽出フィールド | モデルが区間と字幕範囲で参照を指定する。ここでのevidence_idは候補区間を指す |
| 参照の解決 | 元字幕、時刻、元資料バージョン | アプリケーションが識別子と範囲を検証し、引用資料を取得する |
| 比較と再生 | ラベル、双方の発言、動画内の位置 | ページが結果と出典確認リンクを表示する |
モデルが条件フィールドから時間を落としても、引用テキストには残っていました。 Vaneは検査可能なフィールドと参照範囲を返し、HawDBは確認に必要な資料と出典の関係を保存します。 アプリケーションが両者をつなぎます。
性能や発熱に関心があっても、見たいテストは人によって異なります。 下のデモでは4人の投稿者の区間をまとめています。 例えば温度測定の方法ならGeekerwan、長時間の動画撮影ならZhong Wenzeを参照できます。 時刻を選ぶと該当場面を開き、後で見るリストにも追加できます。
元の中国語デモを日本語に翻訳して再構成した説明図です。投稿者名、時刻、元資料を保持しています。
これらは性能と発熱という話題のために別途選んだ区間であり、先ほどのAとBの参照範囲とは完全には一致しません。 それぞれのテスト条件を確認する必要があります。
Geekerwanの16:52の区間では温度センサーと比較機種を紹介しています。 17:08の字幕には、テスト時間が30分だと示されています。 プレーヤー上部のボタンで投稿者ごとの区間を切り替えられます。
元の中国語デモを日本語に翻訳して再構成した説明図です。投稿者名、時刻、元資料を保持しています。
左の動画は16:53、右のテキストは17:08に対応しています。 両方を合わせると、テストの背景を確認できます。 操作欄から元動画を続けて再生したり、Bilibiliで開いたりすることもできます。
原文と人による確認を合わせると、AとBについて次のように視聴を案内できます。
| 視聴者の問い | 最初に見る資料 | 確認する内容 |
|---|---|---|
| Duoで撮影するときの持ち心地はどうか | A：Mediastorm、12:46–13:16 | 約3分間の4K60撮影後の使用感 |
| Pro Maxの前面表面の熱平衡温度はどの程度か | B：Geekerwan、17:23–17:37。時間の条件は17:08から確認 | グラフ上の2世代を区別する。30分間の高負荷ストレステスト |
| 両者の説明は矛盾するか | 双方の機種、原文、条件を照合 | 異なる機種と場面からは、同一機種についての矛盾は導けない |
| この区間だけで冷却性能の利点とトレードオフを判断できるか | 該当機種と条件をそろえた比較をさらに探す | 選択した区間だけでは根拠がそろわない |
この案内が対象とするのは選択した区間であり、動画全体の内容ではありません。
各結果には、関連資料が見つかった、発言を抽出できなかった、一部の抽出に失敗した、処理が失敗した、といった状態を記録します。 裏付けのないフィールドを取り除いても、元資料は残ります。 出力に発言がないことは、投稿者がその話題を扱っていないことを意味しません。
動画を追加したら、保存したデータを再利用する
保存した字幕、フレーム、出典記録は再利用できます。 5本目の動画を追加した場合、キャッシュが有効なら、既存4本の抽出結果と、その間の6組の比較結果を保持できます。 新しい動画と、既存動画との4組の比較だけを処理すれば済みます。
再利用には、元の問い、モデル設定、処理プロトコル、ランナー、元資料バージョンが変わっておらず、既存の結果が完全であることが必要です。
新しい問いでは資料を再利用しながら、検索、抽出、比較をやり直せます。 モデル、ルール、元資料を変えたときは対応する結果を更新し、過去の比較が使った元資料バージョンを保持します。
同じ役割分担は、講義資料、製品調査、複数の出典から得た知識についての問いにも応用できます。 Vaneが資料を処理してモデルを呼び出し、HawDBが関係と来歴を保存します。 アプリケーションは各分析と元資料のバージョン、参照を結び付け、読者が確認できるようにします。