ローカルLLM知識基盤構築作業記録
1 ローカルLLM知識基盤構築作業記録
1.1 概要
本作業では，ローカルLLMに追加知識を与えるための前処理基盤を構築した．
主な目的：
- HTMLアーカイブ群をMarkdownへ変換
- YAMLヘッダ付与によるメタデータ管理
- 再帰処理による一括変換
- 将来的なRAGへの備え
- 自律ツール呼び出し構造の理解
最終的に，数千〜数万規模のMarkdown知識ベースを構築可能な状態に到達した．
1.2 第1段階：HTML → Markdown変換パイプライン
1.2.1 方針
- 再帰的にディレクトリを走査
- 文字コード正規化
- 不要タグ除去
- pandocでMarkdown変換
- 出力ディレクトリ構造を保持
1.2.2 特徴
- ストリーム処理中心
- 一時ファイル最小化
- 純粋なUNIXパイプ設計
1.3 第2段階：YAMLヘッダ付与
各Markdownファイルに以下を付与：
1.3.1 実装方針
- ファイル名から正規表現で日付抽出
- dateコマンドで処理日時生成
- ブロックリダイレクトで本文と連結
- 既存パイプ構造は破壊しない
1.3.2 意義
- ベクトル検索時のメタ情報保持
- 後段フィルタリング容易化
- 階層破壊時の情報保全
1.4 第3段階：チャンク設計検討
10,000規模を想定．
1.4.1 結論
- 全文注入は非現実的
- 見出しベース分割が最適
- 800〜1200文字程度が妥当
- YAML保持型チャンクが有利
1.4.2 検索戦略候補
- grepベース簡易RAG
- ベクトル検索
- 自律ツール呼び出し型
1.5 第4段階：ツール呼び出し構造の理解
重要な理解：
- LLMはテキスト生成のみ
- ツール実行は外側プログラム
- 自律ループは制御層で実装する
構造：
LLM（推論） ↑ Agent層（ツール制御） ↑ クライアント/UI
1.6 第5段階：Open WebUI検討
利点：
- 自動Embedding生成
- ベクトルDB管理
- Tool呼び出し機構
- UI付き
注意点：
- 再チャンクの可能性
- 階層構造は基本保持されない
- 初回Embeddingコスト大
1.7 現在の到達点
- 再帰変換基盤完成
- YAMLメタデータ整備完了
- 大規模知識ベース生成可能
- RAG設計理解済み
- 自律ツール構造理解済み
1.8 実コード
フィルタの実装については別記事も参考にして下さい．
llmを通したり，mozilla/readabilty を通したり，色々試行錯誤してます．
#!/usr/bin/env bash
set -euo pipefail
if [ "$#" -ne 2 ]; then echo "Usage: $0 input_dir output_dir" exit 1 fi
INPUT_DIR="${1%/}" OUTPUT_DIR="${2%/}"
if [ ! -d "$INPUT_DIR" ]; then echo "Error: input_dir does not exist"
exit 1 fi
find
"$INPUT_DIR" -type f -print0 | while IFS= read -r -d '' src; do rel_path="${src#$INPUT_DIR/}" dest="$OUTPUT_DIR/$rel_path" mkdir -p "$(dirname"$dest")"
echo "[*] Processing: $src"
filename="$(basename "$src")" extracted_date="$(echo "$filename" | grep
-oE '[0-9]{4}-[0-9]{2}(-[0-9]{2})?' | head -n1 || true)"
processed_at="$(date '+%Y/%m/%d %H:%M:%S')"
{ echo "---" echo "source: $src" echo "processed_at:
$processed_at" if [ -n "$extracted_date" ]; then echo "date:
$extracted_date" fi echo "---" echo
cat "$src" \ | sed -e 's/localaddress/dummy.net/g' \ | nkf -w -Lu \ | pandoc -f html -t markdown --wrap=none --strip-comments
} > "${dest}.md"
done