前回は「JSONが全部NULLになった話」を書きました。
今回はその続きです。
金融データ活用チャレンジで実際にSnowflakeを回してみて、
教科書には書いてないけど、実戦で効いたこと
をまとめます。
① VARIANTは「とりあえず入れる箱」として最強
最初、評価結果をどう保存するか悩みました。
- カラム分ける？
- JSONのまま持つ？
結論：
とりあえずVARIANTで全部入れる
これが正解でした。
INSERT INTO results
VALUES (doc_id, TRY_PARSE_JSON(json_text));
あとから
eval:overall.rank
eval:items.structure.rank
のように直接取れる。
設計を後回しにできるのが神。
② JSONは「正規表現よりタグ」
前記事でも書きましたが、これ本当に重要。
正規表現で {...} を抜こうとすると壊れます。
LLMは：
- 前に文章をつける
- 後ろに説明を足す
- 複数JSONを出す
平気でやります。
だから最初から：
<JSON>...</JSON>
で囲ませる。
これで
eval_null = 0
になりました。
LLMは信用しない。
③ 長文JSONを一気に10件は危険
fixesやstrengthsを含む長いJSONを
10件まとめて生成したら
- 途中で切れる
- JSONが壊れる
- NULLになる
という地獄。
解決策：
まず短いJSONで全件成功させる
長文は1件ずつ生成する
これだけで安定。
④ Warehouseサイズを上げてもLLMは速くならない
これ、最初誤解してました。
X-Small → Small に変えたら速くなると思っていた。
でも、
Cortex(LLM)は別で動いている
ので、SQL部分しか速くならない。
つまり：
- 普通のSELECTは速くなる
- LLM応答は変わらない
無駄にサイズ上げない方がいい。
⑤ LATERAL FLATTENが想像以上に便利
fixes配列を展開するのに使いました。
SELECT
f.value:section,
f.value:instruction
FROM results,
LATERAL FLATTEN(input => eval:fixes) f;
これで
- JSON配列
- ネスト構造
が一瞬でテーブルになる。
他のRDBより扱いやすいと感じました。
⑥ 無料枠は意外と持つ。でも油断すると減る。
やったこと：
- データ取り込み
- 何度もCortex再実行
- JSONデバッグ
それでも無料枠内で十分回せました。
ただし：
Warehouse止め忘れは地味に効く
Usage画面は定期チェック必須。
今回の学びまとめ
- VARIANTは後悔しない選択
- LLM出力はタグで囲ませる
- 長文×大量は壊れる
- WarehouseサイズとLLM速度は無関係
- JSONはSnowflakeだとかなり扱いやすい
結論
Snowflakeは「難しいデータ基盤」というより、
LLMと組み合わせると急に化ける基盤
でした。
特に金融データのように
- 構造化データ(数値)
- 非構造化データ(文章)
- 評価JSON
が混在するケースでは、VARIANTが本当に強い。
次回は：
- Cortexを本格的に使った評価自動化の話
- コスト最適化ログ
- コンペでの設計全体像
を書こうと思います。