利用者要件の確認支援として、利用目的・利用するデータ・利用者のバックグラウンド(実績・論文アブストラクト等)の要約、及びそれに基づく判定

[matsusho070]

No description provided.

[matsusho070]

入力データの例を、実際のデータの中からご提供いただく予定

[matsusho070]

申請が通ったデータ例に関して拝受済み

[matsusho070]

当方が想定しているフロー、および評価方法などに関して、以下に記載させていただきます。
認識、想定などに違いがありましたらご指摘いただければ幸いです。
また評価用データのうち、特に各種要約の例に関してもご共有をお願いできれば幸いです。

---

想定処理フロー

1. ユーザは申請書 PDF と、その申請書の対象であるデータセットの ID のリストを入力する
2. システムはデータセット ID を元に NBDC ヒトデータベースの対応するページからメタデータを取得し、データセット情報の要約を作成する
3. システムは申請書 PDF の「申請内容に関連した研究代表者の発表論文など 」の内容を元に Web 検索を行い、研究代表者のこれまでの研究内容の要約を作成する
4. システムは 2.と 3.の要約結果に加えて「利用を希望するデータを使用した研究の概要」と「利用を希望するデータと利用目的」を参照することで、
   利用者が要件を満たしているかどうかに対する判定を根拠などを加えた形で出力する

評価に関して

1. まず評価用データとして、以下の組を複数用意する

• 入力データ
  • 申請書 PDF とデータセット ID のリスト
  • NBDC ヒトデータベース上でのデータセットの表示内容
  • Web検索の結果として得られた Web ページのリスト（HTML）
• 出力データ
  • 研究代表者に関する Web 検索を行うためのクエリ
  • 利用目的の要約
  • データセット情報の要約
  • 研究代表者のこれまでの研究内容の要約
  • 利用者が要件を満たしているかどうかに対する判定文書

2. 評価データセットを用いて、以下の点に着目したシステムの精度検証を行う。

• Web 検索用クエリの一致度
  • クエリに含まれる単語ごとに、文字列の編集距離や、埋め込みベクトルの類似度、LLM as a judge などを用いて評価
• 利用目的の要約の一致度
  • 期待される要約結果を意味単位ごとに分割し、生成された結果に対して、意味単位ごとの一致度を LLM as a judge で評価
• データセット情報の要約の一致度、研究代表者のこれまでの研究内容の要約の一致度、利用者が要件を満たしているかどうかに対する判定文書の一致度
  • 利用目的と同様の手順で評価

[matsusho070]

その他確認事項

• データセット ID（JGAD...）もしくは Study ID（JGAS...）からメタデータの Web ページを取得したい時、人間の作業者はどのようにたどり着いているか？

[matsusho070]

2025-02-04の議論を元に修正

想定処理フロー

1. ユーザは申請書 PDF と、その申請書の対象であるデータセットの ID のリストを入力する
2. システムはデータセット ID を元に NBDC ヒトデータベースの対応するページからメタデータを取得し、データセット情報の要約を作成する
3. システムは申請書 PDF の「申請内容に関連した研究代表者の発表論文など 」の内容を元に Web 検索を行い、研究代表者のこれまでの研究内容の要約を作成するとともに、研究論文の概要などを示すファイル（doi必須）を作成する。
4. システムは 2.と 3.の要約結果に加えて「利用を希望するデータを使用した研究の概要」と「利用を希望するデータと利用目的」を参照することで、
   利用者が要件を満たしているかどうかに対する判定を根拠などを加えた形で出力する

要件との一致度を評価する軸の候補

• 疾患の類似度
  • サンプルの疾患と、研究者が扱ったことのある疾患の間の類似度
    • 完全に同じ疾患でなくても、関連する疾患であれば部分点を出せるようにする
• 解析手法の類似度
  • サンプル内の分子データに記載されている解析手法と、研究者が扱ったことのある解析手法の間の類似度
    • 解析手法に関しても同じく、関連しているのであれば適格と見なせる場合がある。

[matsusho070]

データセット ID（JGAD...）もしくは Study ID（JGAS...）からメタデータの Web ページを取得したい時、人間の作業者はどのようにたどり着いているか？

https://humandbs.dbcls.jp/component/search/?searchword=JGAD000018&searchphrase=allのような検索を行う。

もしくは、一旦のテストとしてはhttps://raw.githubusercontent.com/dbcls/humandbs/refs/heads/import_json_skwsm/json_from_joomla/humandb_20231223_both.json から取得可能（エントリーによっては古い可能性があるので、実験のため）

[matsusho070]

一旦、https://nanbyodify.dbcls.jp/app/634b6f1f-1973-40a0-80e2-16d2c167bb7d/workflow に上記の流れを実装したプロトタイプのワークフローを定義しました。

[matsusho070]

2025/02/17 確認事項

• 申請書類に関して記載されているデータセットIDが、事務局コメントに含まれないのはどういった場合か？
  • →特にそういったフローは無いはず。もしあるようなら別途連絡いただく
• 事務局コメントに記載される要約は、データセットID単位というよりは研究ID単位に見受けられるが、正しいか？（研究ID単位でグルーピングし、データセット単位で記載する？）
  • 正しい。今のところ、研究IDは申請書類には含まれないため別途グルーピングする必要がある。

[matsusho070]

「利用を希望するデータと利用目的」にデータセットIDが含まれない場合は、自由記載の方にIDが記載される

[matsusho070]

適格 / 非適格の判定は一括ではなく、データセットID単位で行われることが望ましい

[matsusho070]

想定する出力

• データセットID単位でのICD10のコード
• 利用目的の疾患に対応するICD10コード
• 論文情報ファイル（Abstract_***として作られている情報）
  • 論文ごとに対応するICD10コード
  • 論文ごとに取得元のURL
• データセットのICD10に対応する疾患分類 vs （利用目的＋論文情報の対象）の類似度
• データセットID単位での適格 / 非適格の判定（根拠つき）
• 解析手法の類似度（LLMに「これこれこういう理由で似ている/似ていない」という文章を作らせる。低中高の３段階くらいで）
• 【優先度低】事務局コメントフォーマットでの出力

[matsusho070]

上記出力を行えるプロトタイプを、URL ＋ID パスワードを知っているユーザであれば使える状態にすることを目標とする