ID:80546さん

【自然言語でデータベースに問い合わせるアプリ(Text-to-SQL)】 ※業務ではなく、学習を目的とした個人開発プロジェクトです。 「データを見たいが、SQLを書けないと欲しい情報にたどり着けない」という課題を、LLMを用いて解決するアプリケーションです。「在庫が10個以下の商品は?」のように日本語で質問すると、AIがSQL(SELECT文)を生成してデータベースに問い合わせ、結果を返します。ブラウザ上で、生成されたSQLの整形表示と実行結果のテーブル表示を確認できます。 RAGを扱った前プロジェクト(TechDoc QA Bot)がベクトルDBによる「曖昧な意味検索」だったのに対し、本プロジェクトはRDBに対する「厳密なデータ照会」を扱い、LLMの別の活用パターンとして取り組んでいます。 --- ### ▼ ロードマップ - [x] MVP実装(SQLite・3テーブル・単一テーブルへのSELECT生成) - [x] 読み取り専用ガード(生成SQLがSELECT以外なら実行を拒否・複文も拒否) - [x] JOIN・集計・ランキングクエリへの対応 - [x] Text-to-SQLの精度評価(想定質問18問で正答率を計測、100%を達成) - [x] FastAPIによるAPI化・画面UI化(生成SQLの整形表示・コピー機能付き) - [ ] SQLインジェクション対策の強化 - [ ] SQLite → MySQL / PostgreSQL への載せ替え --- ### 設計方針 | 項目 | 内容 | |---|---| | DB | SQLite(MVP)→ MySQL / PostgreSQL(本番想定) | | 題材 | EC/購買データ(customers / products / orders の3テーブル) | | LLMの役割 | 自然言語の質問とテーブル構造(スキーマ)を渡し、SELECT文を生成させる | | 安全性 | 生成SQLをそのまま実行せず、SELECT以外の命令・複文を実行前に弾く読み取り専用ガードを実装 | | インターフェース | CLIに加え、FastAPIによるAPI(POST /query)とブラウザUI(GET /)を提供 | | 設計 | スキーマ(schema.sql)とダミーデータ(seed.sql)をバージョン管理し、DBファイル自体はコミットしない | --- ### 精度評価の取り組み 単一検索・JOIN・集計・ランキング・「データに存在しないものを問う」質問をバランスよく含む18問の評価データセットを自作し、生成SQLの「実行結果」が期待結果と一致するかで正答率を自動計測しました。 ベースラインは44.4%でしたが、不正解を分析すると、その多くはモデルの誤りではありませんでした。改善の過程で、①プロンプトの指示不足、②評価データセット側の質問の曖昧さ、③同名列の衝突によるアプリ側の実装バグ、という3つの異なる層のバグを切り分けて修正し、最終的に18/18(100%)に到達しました。詳細はリポジトリ内の docs/evaluation.md に記録しています。 ### このプロジェクトで示したいこと 前プロジェクトで確立した「作って終わりにせず、評価データセットを自作して測定・改善する」という進め方を、Text-to-SQLでも踏襲しました。特に、精度を「モデルの性能」だけの問題として捉えず、プロンプト・評価データ・実装コードのどこに原因があるかを切り分けて改善する過程を重視しています。 https://github.com/nd-3/llm_learning_journey/tree/main/03_portfolio/text-to-sql

【技術ドキュメント検索・要約AIアシスタント】 ※業務ではなく、学習を目的とした個人開発プロジェクトです。 開発者が公式ドキュメントや技術ブログから情報を探す際の「目的の情報が 見つからない」「全体像を掴むのに時間がかかる」という課題を、RAG(検索拡張生成) 技術を用いて解決するツールです。 指定した技術文書(PDF)に対して自然言語で質問するだけで、AIが関連箇所を特定し、 参照元と共に回答を生成します。 現在はCLIとAPI(FastAPI)、ブラウザUIで動作します。 --- ### ▼ ロードマップ - [x] RAGパイプラインのMVP実装(単一PDF・コンソール対話) - [x] RAG精度の評価(想定QAセットを用意し正答率を計測) - [x] chunk_size / top_k / 埋め込みモデルの選定理由をドキュメント化 - [x] pytest による基本テスト + GitHub Actions CI - [ ] 複数ドキュメント対応 - [ ] 会話履歴の保持 - [ ] ストリーミング応答 - [x] Web API化(FastAPI、`POST /ask`) - [x] 画面UI化 --- ### 技術スタック(実装済み) | 分類 | 技術 | |---|---| | 言語 | Python 3.10 | | RAGフレームワーク | LangChain(langchain, langchain-community, langchain-text-splitters) | | ベクトルDB | ChromaDB(ローカル永続化) | | LLM | Claude Haiku 4.5(Anthropic API 経由、langchain-anthropic) | | 埋め込みモデル | text-embedding-3-small(OpenAI Embeddings、評価により選定 → docs/evaluation.md) | | PDF読み込み | pypdf(langchain_community.document_loaders.PyPDFLoader 経由) | | Web | FastAPI(POST /ask API + GET / でHTML画面を提供) | | 環境変数管理 | python-dotenv | | 動作環境 | WSL2(Ubuntu) | ### 技術スタック(今後予定) - インフラ/DevOps: Docker, AWS(ECS, S3) --- ### 精度評価の取り組み 261ページの公開PDF(大学のPython教材)を対象に25問のQAデータセットを自作し、正解率・検索ヒット率を自動計測する評価基盤を構築しました。 埋め込みモデルの比較検証を行い、実測データに基づいて正解率76%→96%への改善を達成。 さらに、唯一残った不正解1問について、パラメータを総当たりする前に根拠チャンクの検索順位を特定する診断を行い、原因(top_kの不足)を突き止めた上でtop_k=8を採用し正解率100%を達成しました。 選定理由はリポジトリ内に文書化しています。 評価の過程では判定ロジックの正規化やキャッシュのバグ修正も行い、「測定自体の信頼性」にもこだわっています。 ### 今後の展望 最終的にはFastAPIによる画面UI化とAWS上へのデプロイを目指しています。 また、本プロジェクトで得たLLM活用の知見をベースに、RDBと組み合わせた 別のアプリケーション開発にも取り組む予定です。 https://github.com/nd-3/llm_learning_journey

【求人・案件の要件と自分のスキルを照合する分析ツール(skill-match-analyzer)】 ※業務ではなく、学習を目的とした個人開発プロジェクトです。 求人票や案件の要件テキストと、自分のスキルプロファイルを突き合わせ、マッチ度・合致するスキル・不足しているスキル・想定される確認事項・応募判断を、構造化された形で出力するツールです。 前プロジェクト(TechDoc QA Bot)がRAGによる「文書からの回答生成」だったのに対し、本プロジェクトはLLMの出力を決まったスキーマ(型)に固定する「構造化出力」を扱い、LLMの別の活用パターンとして取り組みました。 --- ### ▼ ロードマップ - [x] 出力スキーマの設計(Pydanticでマッチ度・根拠・ギャップ・想定質問・応募判断を型定義) - [x] コアロジック実装(要件テキスト+スキルプロファイルをLLMに渡し構造化出力を生成) - [x] preferences(志向)を判断に組み込む設計(スキル適合だけでなく方向性の一致も考慮) - [x] FastAPIによるAPI化(POST /analyze) - [x] pytestによるテスト + GitHub Actions CI - [ ] 判定精度の評価データセット化 - [ ] 画面UI化 --- ### 設計方針 | 項目 | 内容 | |---|---| | LLMの役割 | 要件テキストと自分の情報を渡し、決まったスキーマで分析結果を生成させる | | 出力の信頼性 | Pydantic(BaseModel)でスキーマを定義し、型や範囲(マッチ度0〜100等)を外れた出力を自動で検出 | | 根拠の追跡 | 合致スキルは「要件テキストからの引用」と「自分のプロファイルの対応項目」をペアで持ち、要件にない項目を創作していないか検証できる | | 志向の反映 | スキルが合致していても志向(避けたい方向性)と衝突する場合は応募判断を保留にする | | データ管理 | 実データのプロファイルはコミットせず、ダミーのテンプレートのみ公開 | --- ### 工夫した点 スキル適合度だけで応募可否を判断すると、「できるが、やりたくない案件」が高評価になってしまう欠陥に気づきました。そこで、目指す方向性や避けたい方向性といった「志向」を判断材料に組み込み、スキルが合致していても志向と衝突する場合は応募を推奨しない設計にしました。実際に、スキルは高く適合するが志向と合わない求人が「保留」と判定されることを、架空の求人データで確認しています。 また、公開用のデモには架空の求人票とダミーのプロファイルのみを使い、実データの求人・プロファイルは手元での利用に限定しています。 ### このプロジェクトで示したいこと LLMの出力は自然文で不確実なため、そのまま使うと信頼できません。Pydanticでスキーマを定義して型・範囲を強制し、根拠を追跡可能な構造で持たせることで、「LLMの出力を、検証できる形に固める」という設計を重視しました。 https://github.com/nd-3/llm_learning_journey/tree/main/03_portfolio/skill-match-analyzer