有了day10爬蟲取得的資料後 我們要為查詢做準備, 爬蟲取得的資料格式是JSON檔, 而我們的使用情境會是針對口語問題作出回答, 我們需要把現有的資料內容向量化, 方便之後查詢時可以進行向量比對得知最符合問題的答案

第一件事是定義 Ingestion Job 的輸入與輸出。
輸入面，我們會把 Cloud Storage 的 raw JSON 視為唯一來源，Job 每次執行時要知道要處理哪些檔案、是全量還是增量、是否限制單次處理數量。
輸出面，Job 要產出可追蹤的執行結果，例如本次讀了幾個檔案、成功寫入幾筆文件、產生幾個 chunk、呼叫了幾次 embedding、跳過了幾筆既有資料、有哪些錯誤。
這些資訊不是附加品，而是未來排錯和成本控制的核心。

這裡的全量是指不管資料是否存在都進行覆蓋, 也就是打掉重做, 增量則是判斷是要增加資料或是對既有資料進行修改

第二件事是定義資料表 DDL。
我們會把資料拆成文件層、切片層、向量層三層結構。文件層保存來源與語意主體，切片層保存可檢索文字與順序，向量層保存 embedding 與模型版本。這樣做的好處是清楚、可查、可維護，日後你要改 chunk 策略或升級 embedding 模型，也不會把整個資料庫設計打爛。今天要完成的不是只有欄位清單，而是明確定義主鍵、唯一鍵、外鍵與必要索引，確保查詢與重跑都能穩定。
DDL(data definition language) 是用來定義和修改資料的schema, 通常包含 建立,刪除, 修改, 清空

第三件事是定義增量規則。
這會直接決定你後續費用與效率。我們會採用內容雜湊去重，讓同一份內容不會重複向量化；同時保留來源檔案與時間戳，讓你知道每筆資料從哪裡來、何時進來。增量規則會包含三個判斷：文件是否已存在、chunk 是否已存在、向量是否已存在。只要其中任一層已存在且內容未變，就跳過重算。這樣你每天更新資料時，成本會接近只支付新增內容，而不是反覆全量重建。

今天這些任務完成後會有一個可持續運作的基礎：
資料能進、能查、能重建、能控成本。下一步再接 Cloud Run Job 實作與實際驗證時，風險和不確定性會少非常多。

本日實作

今天新增一個 /ingestion 的資料夾, 裡面定義向量化,增量的cloud run job

主要邏輯是在main.py 進行 GCS raw JSON 轉成 可檢索向量資料 的完整管線，且有做「增量與去重」，重跑不會無限重算

cd <project-root-path>

# 打包 crawler image（D10）
gcloud builds submit crawler \
  --tag gcr.io/chat-bot-484615/bank-crawler:latest

# 打包 ingestion/vectorize image（D11）
gcloud builds submit ingestion \
  --tag gcr.io/chat-bot-484615/bank-vectorize:latest

把爬蟲和塞資料的job打包上傳cloud run job

另外在cloudrun.tf 新增了 vectorize_job的job定義

以及在makefile中定義了 爬蟲 與塞資料的處發

make crawl-sync 與 make reindex

觸發兩次reindex就可以驗證增量的用途 不會讓重複的內容寫入sql資料庫

第一次觸發log

第二次觸發log 可以看到跑第二次時 沒有新增的document與chunks因為已經存在