FioneのLLMアシスタント案でデータを相談し学習条件を確認する

FioneのPython刷新案に、データセットやモデルについて自然な言葉で質問できる「Fione-kun」の実装が追加されています。列の欠損やモデルの結果を確認し、学習条件の提案を画面で確認するためのLLMアシスタントです。

読み取りと提案を行い、学習開始は人が確認する

プロジェクトのメニューからFione-kunを開き、「欠損の多い列はどれか」「この列を予測する学習条件を提案して」といった質問を送ります。アシスタントは、利用者が読めるデータやモデルについて、型の決まったツールを使って調べます。

学習の提案は、対象データセット、予測する列、タスク、時間制限、除外候補の列などをカードで表示します。編集権限のある人が内容を確認して「学習開始」を押すと、サーバーに保存した条件で1回だけジョブを開始します。閲覧者には実行ボタンを表示しません。モデルの返答だけで学習を開始したり、データを変更・削除したりする仕組みではありません。

データ内の文章に影響されて誤った回答や提案をする可能性は残るため、目的変数や除外列、評価結果は人が確認します。

初期値は直接起動とComposeで異なる

Fioneプロセスを直接起動する場合、FIONE_LLM_BASE_URLの初期値は未設定で、アシスタントは無効です。一方、PRのCompose構成はhttp://host.docker.internal:11434/v1を初期値として渡し、ホスト上のOllamaへ接続します。ComposeではURLを追記しなくても、LLMサーバーがある前提の構成になります。

モデル名はgemma4:12b-mlx、Composeのプロバイダーはollamaが初期値です。Fione本体のプロバイダー初期値はopenaiなので、Compose外でOllamaを使う場合は明示します。モデルの自動取得はFIONE_LLM_AUTO_PULL=falseで、初期状態では管理者がシステム画面から取得します。Fioneはモデルを同梱しません。

試すには正式版と別の作業コピーでPRを取得します。

git clone https://github.com/codelibs/fione.git fione-assistant-review
cd fione-assistant-review
git fetch origin pull/16/head
git switch --detach FETCH_HEAD
cp docker/.env.example docker/.env

docker/.envのS3用アクセスキーと秘密キーに、それぞれopenssl rand -hex 16、openssl rand -hex 32などで生成した値を設定し、Gitへ登録しません。DockerとCompose v2を用意して、次を実行します。

docker compose -f docker/compose.yaml --env-file docker/.env up -d --build

Web画面の初期ポートは127.0.0.1:8080です。初回はdocker compose -f docker/compose.yaml --env-file docker/.env logs fioneで確認したSetup tokenを使って管理者を作成します。既定の管理者パスワードはありません。

macOSの標準経路はホストのOllamaアプリです。Ollama側のコンテキストをOLLAMA_CONTEXT_LENGTH=16384へ設定して起動し、モデルを取得します。これはFione側の初期値FIONE_LLM_CONTEXT_TOKENS=16384だけを設定しても代わりにはなりません。モデルの準備中や接続できない間は質問欄が無効になり、通常のFione機能は使えます。

LinuxなどでCompose内のOllamaを使う場合は、.envの次の設定を有効にします。

COMPOSE_PROFILES=ollama
FIONE_LLM_BASE_URL=http://ollama:11434/v1
FIONE_LLM_MODEL=gemma4:12b
FIONE_LLM_AUTO_PULL=true

このプロファイルはCPU動作で、Ollamaのポートをホストへ公開しません。初回はイメージ約3.8GBとモデル約8GBの取得があり、応答も遅くなります。サイズはPRでの目安です。別の互換サーバーならURL、FIONE_LLM_PROVIDER=openai、モデル名、必要に応じてAPIキーを設定します。

送信する情報と実行上限を確認する

質問とともに、プロジェクト名、データセット名、列名、型、欠損率や範囲などの統計、モデルの結果をLLMサーバーへ送ります。セルの例示値は初期状態では送らず、管理者がその接続先に対して許可した場合に頻出値などを含めます。接続先アドレスを変えると、この許可は無効に戻ります。例示値を許可しなくても名前や統計は送られる点を確認します。

会話は作成者だけが画面から参照でき、管理者にも共有されません。ただしデータベースでは暗号化せず保存します。外部サーバーへの接続では利用者へホスト名の警告が出ますが、送信の可否は運用側で判断します。

質問は4,000文字、1会話100質問、利用者とプロジェクトの組み合わせにつき100会話が上限です。1回答は初期値でツールの往復6回、180秒、サーバー全体で同時2回答です。利用者ごとは3件、待機は8件が上限です。Fione再起動時に進行中の回答は中断されます。PR内の自動試験は模擬LLMが中心で、実モデルの試験は任意実行です。

MCPは有効化する

FIONE_MCP_ENABLEDの初期値はfalseです。必要な検証環境でtrueにすると、Fione自身のポートの/mcp、例えばhttp://127.0.0.1:8080/mcpへ対応クライアントから接続できます。

認証はアカウント画面で発行する通常のfull APIトークンをAuthorization: Bearerで渡します。ログインCookieやNotebook用トークンは使えません。MCPはトークン所有者が読めるプロジェクトの情報を参照し、学習条件の提案を返せますが、提案の保存や学習開始は行わず、セルの例示値も返しません。

MCPのツールは読み取り用途でも、使うトークン自体は通常のREST APIと同じ権限を持ちます。読み取り専用の資格情報だと誤解せず管理します。同時呼び出しは2件で、ほかのレート制限はありません。リバースプロキシ越しにFioneを公開している場合、MCPも同じポートに出るため、外部利用を認めないなら/mcpへのアクセスをプロキシ側で制限します。

関連PR

Fessのファイル権限とサジェストで閲覧対象を確認する

ファイルの読み取り権限を検索へ引き継ぐ処理と、文書から候補語を生成する処理が見直されました。FessのPR #3685・#3686・#3688・#3689はマージ済みです。

権限欄のdenyを保存し直したときの変化

クロール設定の権限欄に「(deny) {user}bob」のように接頭辞の後へ空白を入れた場合、拒否として保存されず、再保存で許可へ変わる問題がありました。修正後は(allow)・(deny)の後をtrimしてから解釈します。

拒否は「(deny){user}bob」「(deny){group}staff」「(deny){role}editor」のように、対象の種類を指定します。型のない「(deny)foo」は拒否として保存されず、呼び出し側で空値として除外されます。またDevelopersのようにDで始まる通常の値を、拒否の接頭辞と誤認しないようになります。

以前に拒否が許可へ変換されて保存された値は、修正版だけでは元に戻せません。該当するクロール設定を確認し、意図したdenyを入れ直します。初期の内部接頭辞はユーザー1・グループ2・ロールR・拒否Dですが、通常の設定欄では内部表現を直接書かず上記の形式を使います。

ローカルファイルのACLは読み取りだけを反映

file.role.from.fileの初期値はtrueです。file:のクロールでAclFileAttributeViewが得られるファイルシステムを対象に、READ_DATAを含むALLOWを許可、同じ権限を含むDENYを拒否として登録します。書き込みだけの許可やAUDIT・ALARMは読み手の追加に使いません。

これはNTFSなどのACL情報を取得できる場合の処理で、POSIXの完全な権限モデルを実装したり、あらゆるリモートストレージのACLを扱う変更ではありません。旧処理で登録した文書のロールは再クロールまで残るため、設定修正後は対象を再取得し、許可・拒否のそれぞれのユーザーで検索結果を確認します。

検索できない文書の語を候補へ出さない

文書を元にするサジェスト生成では、roleがない文書と、ユーザー・グループ・ロールへのdenyを含む文書を読み込み対象から除外します。サジェスト要求で個別ユーザーのdenyを表せないため、allowも持つ文書であってもdenyがあれば文書全体を除外します。閲覧できるユーザーにとっても、その文書由来の候補語が減る場合があります。

すでに作成済みの候補は、更新した瞬間に一括削除されるのではなく、通常のpurgeで期限切れになります。文書の再クロールとサジェストの更新・purgeを別々に確認します。検索ログなど別の供給元もあるため、単語が残っていることだけで今回の文書フィルターが未適用とは断定しません。

人気ワードのメモリー内キャッシュも、複数のロール名を区切りなしで結合したキーが別の組み合わせと衝突しないよう修正します。新しい有効化設定はありません。更新後は閲覧ロールの異なるユーザーを切り替え、文書・サジェスト・人気ワードをそれぞれ確認します。

関連PR

Fessの起動失敗を終了コードで検知する修正案と確認点

Fessが起動せず、すべてのURLが404になる一方で、Javaプロセスと待ち受けポートは残っていることがあります。Webアプリケーションの初期化に失敗したとき、プロセスを終了コード1で止めるための変更が進んでいます。

ポートが開いているだけでは起動成功と分からない

たとえば起動時にOpenSearchへ接続できず、待ち時間内にWebアプリを初期化できない場合でも、Tomcat本体は動き続けることがあります。失敗したコンテキストへ要求すると404になりますが、サービス管理やコンテナの再起動ポリシーはプロセスが生きているため反応しません。

PR #3710ではTomcat起動後に各Webアプリの状態を調べ、利用可能でないものがあれば、標準エラーへlogs/fess.logを参照するメッセージを出してSystem.exit(1)で終了する処理を加えています。新しい有効化設定はありません。

マージ済みの変更だけでは不足する

ランチャーのFessBootは限定されたクラスパスで動きます。#3710の失敗判定がコアライブラリのStringUtilを参照したため、実際の配布物ではNoClassDefFoundErrorとなり、Tomcatのスレッドが残る問題が報告されています。

運用では失敗検知と再試行条件を確認する

修正がそろった配布物を使う段階で、検証環境から接続不能な検索エンジンを指定し、メッセージと終了コード1を確認します。正常に起動する場合に終了しないことも対で確認します。

Fess自身が接続先を修復して自動復旧する機能ではありません。再起動するかどうかはsystemdやコンテナ側のポリシーに依存します。検索エンジンのURL、接続・認証エラー、fess.logとコンソールの原因を先に確認し、再試行の間隔や上限も運用に合わせます。

この確認が済むまでは、プロセスの存在やTCPポートだけに頼らず、アプリケーションの応答も監視します。既存の外部OpenSearch向けsystemd起動依存関係の変更とは、確認する段階が異なります。

関連PR