Month: October 2025

LLMの「会話ログ分析（chat log analysis）」は、AIの品質改善・ユーザー理解・安全性検証などに直結する重要な工程

LLMの会話ログ分析は、次の3段階で行うのが一般的
1️⃣ データ収集・整形
2️⃣ 定量分析（メトリクス）
3️⃣ 定性分析（内容・品質）

1️⃣ データ収集・整形
ログは通常、以下のような形式で保存される：
JSONL（1行ごとに1チャット）
PostgreSQL / BigQuery（大規模ログ）
ログ収集基盤（例：Datadog, ElasticSearch）

2️⃣ 定量分析（メトリクス）
数値的に「モデルがどのくらい良かったか」を分析
品質 BLEU / ROUGE / BERTScore 生成文と理想解の一致度
自然さ perplexity / fluency 文章の滑らかさ
応答速度 latency 応答にかかった時間
満足度 thumbs up/down, rating ユーザーのフィードバック
業務指標 解決率 / 再質問率 実務上の有効性

Pythonの分析例

import pandas as pd

df = pd.read_csv("chat_logs.csv")

# 応答時間の平均
print("平均応答時間:", df["latency"].mean())

# 再質問率（ユーザーが同じ質問を繰り返した回数）
repeat_rate = df[df["input_text"].duplicated()].shape[0] / len(df)
print("再質問率:", repeat_rate)

# フィードバックスコア
positive_rate = (df["feedback"] == "👍").mean()
print("満足度:", positive_rate)

3️⃣ 定性分析（内容・品質）
数値だけでは分からない「中身の良し悪し」を人が確認します。
分析方法：
要約分析：どんなテーマの質問が多いか（例：経費、勤怠、福利厚生）
回答品質の分類：正確・不正確・曖昧など
トーン分析：丁寧／フレンドリー／冷たいなど
ハルシネーション（幻覚）検出：根拠のない出力があるか

from openai import OpenAI
client = OpenAI()

log = "ユーザー: 経費申請の期限は？\nAI: 翌月15日までに提出してください。"
prompt = f"次のAI回答は正確ですか？ Yes/Noで答えてください。\n\n{log}"

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": prompt}]
)

print(resp.choices[0].message.content)

モデル品質評価 BLEU, ROUGE, GPT-based eval
カスタマーサポート分析 意図分類、トピッククラスタリング
改善ポイント抽出 ネガティブフィードバック解析
安全性検証 不適切発言検出、機密情報流出検出
運用指標 応答時間、利用回数、解決率

AIが社内データから答えを探して答える —
というのが「社内QAシステム」です。

⚙️ 仕組み（RAG：検索拡張生成）
1️⃣ 社内データを集める
　例：マニュアル、議事録、FAQ、Slackログ、PDF資料などを収集
2️⃣ ベクトル化（Embedding）
　→ テキストを「意味の近さ」で比較できる数値ベクトルに変換します
　（例: OpenAI の text-embedding-3-small など）
3️⃣ 検索（Retrieval）
　→ ユーザーの質問も同じようにベクトル化し、
　「最も意味が近い文書」を検索します
　（例: FAISS, Chroma, Weaviate などを利用）
4️⃣ 生成（Generation）
　→ 検索した文書をLLM（GPTなど）に渡し、
　「この情報に基づいて答えて」と指示して回答を生成

🏢 実際の構成イメージ
[社員の質問]
↓
[Embedding検索]
↓
[社内ナレッジDB（PDF, Word, Wiki…）]
↓
[関連情報を抽出]
↓
[LLM（GPTやGeminiなど）が回答生成]
↓
[自然な日本語で答えを返す]

✅ メリット
メリット 内容
情報探索の効率化 社員がFAQや文書を探さずに即回答を得られる
ナレッジの再利用 社内に散らばった文書を有効活用できる
属人化の解消 ベテラン社員の知識もシステムに蓄積可能
社内チャット連携 Slack / Teamsボットとして導入しやすい
⚠️ 注意点
課題 対策
機密情報の扱い オンプレ・プライベートクラウドで構築する
検索精度の低下 文書構造化・適切な分割（chunking）が重要
更新管理 ナレッジDBを定期的に再インデックス化する

Rag

import os
import numpy as np
import faiss
from openai import OpenAI

# === APIキー ===
client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

# === 社内文書（例） ===
docs = [
    "有給休暇の申請は人事システムから行います。",
    "出張申請は上長の承認を経て経理部に提出してください。",
    "経費精算は翌月10日までにシステムへ登録してください。",
    "社内Wi-Fiは社員IDとパスワードで接続できます。",
]

# === 文書を埋め込み（ベクトル化） ===
print("🔹 Generating embeddings...")
embs = [client.embeddings.create(model="text-embedding-3-small", input=d).data[0].embedding for d in docs]
dim = len(embs[0])

# === ベクトルDB（FAISS）を作成 ===
index = faiss.IndexFlatL2(dim)
index.add(np.array(embs).astype("float32"))

# === 質問 ===
query = "経費はいつまでに提出する必要がありますか？"
q_emb = client.embeddings.create(model="text-embedding-3-small", input=query).data[0].embedding

# === 類似文書を検索 ===
k = 1  # 上位1件を取得
D, I = index.search(np.array([q_emb]).astype("float32"), k)
context = docs[I[0][0]]

print(f"\n📝 検索された文書: {context}")

# === LLMで回答生成 ===
prompt = f"次の社内資料を参考に質問に答えてください。\n\n資料:\n{context}\n\n質問:\n{query}"
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": prompt}],
)

print("\n💬 回答:")
print(response.choices[0].message.content)

1. BLEU（Bilingual Evaluation Understudy）
主に「機械翻訳」や「文章生成の精度」を自動で測る指標。

生成文 と 正解文（リファレンス） の間で、
単語やフレーズ（n-gram） の一致率を計算
「どれだけ同じ単語列が出てきたか」を重視する手法です。
正解文: 私はリンゴを食べました
生成文: 私はリンゴを食べた

共通の n-gram が多いため、
BLEUスコアは高くなる（例: 0.8 など）。

「食べた」 vs 「食事した」 は同じ意味でも評価されない

2.ROUGE（Recall-Oriented Understudy for Gisting Evaluation）
目的:主に「要約タスク」の自動評価に使われます。
BLEUが「生成文にどれだけ正解単語が含まれるか（Precision）」を重視するのに対し、
ROUGEは正解文の情報をどれだけ拾えているか（Recall） を重視します。
特に有名なのは ROUGE-1（単語）、ROUGE-2（2-gram）、ROUGE-L（最長共通部分列）。

正解要約: 富士山は日本で最も高い山である。
生成要約: 富士山は日本一高い山。
→ 多くの重要単語（富士山、日本、高い山）が共通
→ ROUGEスコア高め

3.人手評価（Human Evaluation）
目的:
AIが出力した文章を人間が直接見て判断する方法。
一番信頼できるが、一番コストが高い。
正確性（Accuracy） 事実・情報が正しいか
一貫性（Consistency） 文全体に矛盾がないか
流暢性（Fluency） 日本語として自然か
関連性（Relevance） 質問や文脈に合っているか
創造性（Creativity） 独自性・表現力があるか

4. ガイドラインベース評価（Guideline-based Evaluation）
人手評価の主観を抑え、一貫性のある基準で評価する方法。
💡 概念
OpenAIやAnthropicが内部で使用しているように、
評価者に「詳細な採点基準（ガイドライン）」を与えることで、
人手評価を半構造化・定量化します
指標 種類 評価対象 特徴 長所 短所
BLEU 自動 翻訳・生成 単語の一致率 定量的で高速 意味を理解できない
ROUGE 自動 要約 単語の網羅性 要約に適する 言い換えに弱い
人手評価 手動 全般 主観ベース 正確・柔軟 高コスト・主観的
ガイドライン評価 手動＋基準化 全般 定義ベース 再現性が高い 準備が必要

### ファインチューニング（fine-tuning） とは?
すでに学習済みのLLM（例：LLaMA, GPT, Mistralなど）を
自分のデータで「再訓練」して、特定の用途に特化させること。

e.g.
ChatGPTを「医療専門AI」にしたい
LLaMAを「企業マニュアルの質問回答AI」にしたい
Mistralを「社内チャットボット」に最適化したい

### why it need fine tuning
LLMは汎用的なので、例えば次のような弱点があります。

通常のLLM チューニング後
「契約書の条文っぽい文章」を知らない 法律文体で出力できる
「企業内の独自用語」を知らない 社内専門語で答える
指定フォーマットを守らない JSON形式で必ず回答する

### LoRA / PEFTとは？（軽量ファインチューニング）
通常のファインチューニングは、
巨大モデル全体を再学習するため、
GPU・時間・コストが非常に高くつきます（数十GB〜数百GB）。
→ そこで登場したのが LoRA や PEFT。

🔹 LoRA（Low-Rank Adaptation）
LoRAは、「モデル全体ではなく一部の重みだけを微調整」する仕組みです。
📘 ざっくり言うと：
「LLM本体は凍結（変更しない）」
「一部の行列（重み）だけを低次元（rank低い）で学習」

これにより👇
項目 通常ファインチューニング LoRA
学習パラメータ数 数百億 数百万（1〜3%）
必要GPUメモリ 数百GB 数GB
コスト 非常に高い 低コスト
再利用 不可（モデルごと） 可能（LoRA層だけ切り替え可）

元の重み W に、小さな変化 ΔW を足してチューニングする。
ΔW = A × B （A,Bは小さい行列＝低ランク）

🔹 PEFT（Parameter-Efficient Fine-Tuning）
LoRAを含む「軽量ファインチューニング技術の総称」です。
PEFTには以下のような手法があります：

手法 概要
LoRA 一部の重みを低ランクで更新
Prefix Tuning プロンプトに「学習したベクトル」を前置
Prompt Tuning 入力部分だけ学習（モデル本体は凍結）
Adapter Tuning モデルの中間層に追加ネットワークを挿入
➡️ Hugging Face の peft ライブラリ はこれらを統一的に扱えます。

from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import LoraConfig, get_peft_model

# ベースモデル
model_name = "meta-llama/Llama-2-7b-hf"
model = AutoModelForCausalLM.from_pretrained(model_name)
tokenizer = AutoTokenizer.from_pretrained(model_name)

# LoRA設定
lora_config = LoraConfig(
    r=8,               # rank（低次元のサイズ）
    lora_alpha=16,     # 学習率スケーリング
    target_modules=["q_proj", "v_proj"],  # attention層だけチューニング
    lora_dropout=0.05,
)

# LoRAモデルを作成
model = get_peft_model(model, lora_config)

# 学習用データ（例）
texts = [
    {"input": "会社の理念を説明してください。", "output": "私たちは顧客の信頼を第一とします。"},
]

# トークナイズと学習処理（実際はTrainerを使用）
# model.fit(...)

# 学習済みLoRAを保存（ベースモデルと分離）
model.save_pretrained("my_lora_adapter/")