1 つのモデルの解釈に依存せずに顧客インタビューを統合する

テーマを尋ねる前に証拠を準備する

調査権限と組織のルールにより、選択したサービスとの資料の共有が許可されていることを確認してください。識別子と不要な機密情報を削除します。各インタビューに安定した ID を割り当て、各抜粋に段落やタイムスタンプなどの場所を割り当てます。識別キーは提出する資料の外に保管してください。

マテリアルが利用可能なコンテキストに適合しない場合は、同じコーディング指示を使用して明示的なバッチで作業します。バッチ メンバーシップを保存し、元の抜粋へのリンクを保持します。モデルが省略されたトランスクリプトを読んだとか、別々のチャットが自動的にお互いを記憶しているとは想定しないでください。

観察、解釈、行動を分離する

GOV.UK の調査分析ガイドは、観察、その解釈から得られた知見、次の行動を分けています。AI を使う場合も、この三層を出力で明示します。顧客の発言を、そのまま製品要件に置き換えてはいけません。

まず、Ask separatelyを通じて対応可能なエージェントに、同じ抜粋からのコードを提案するよう依頼します。次に、それらの定義、サポート ID、例外を比較します。異なるラベルが同じ動作を説明している場合があります。一致するラベルには異なる意味が隠されている可能性があります。いずれかをマージする前に、基礎となるマテリアルを確認してください。

• 英国政府: 研究セッションを分析↗

例：同じ発言の繰り返しは、別の参加者の証拠ではない

架空のデータセット: 予約に関する 20 件のインタビュー。 5 人の参加者が予約変更の難しさを述べています。参加者の 1 人、I07 は同じ出来事を 3 回説明しました。別の I12 さんは、予約の変更は簡単だったが、確認内容を理解するのは難しかったと述べています。これらは、メソッドを説明するために作成された入力です。

I07 の三つの抜粋を独立した三人として数えたり、違いを確認せず I12 を同じ問題にまとめたりしないでください。「20 人中 5 人」という確認済みの数も、このサンプルを示すだけです。全顧客における割合は分かりません。

有益な意見の相違は、一方のモデルはマテリアルをナビゲーションの難しさとしてコード化し、もう一方のモデルは変更後の不確実性としてコード化することです。抜粋に戻り、これらが個別のテーマであるか、1 つの経験の段階であるかを判断します。ストーリーをすっきりさせるために、矛盾するケースは削除せずに保存してください。

追跡可能な解釈を求めるプロンプト

統合時は、元の抜粋とラベル付きの分析案を Consensus に渡します。モデルの一致を追加の証拠と扱わず、重なりと意見の違いを示すよう依頼します。書き換え後も出典 ID を残します。生成された引用が原文に見つからなければ削除し、記憶で修復せず出典に戻ります。

調査の問い：[問い]。共有可能で匿名化した抜粋と、インタビュー ID・位置：[資料]。分析用コードとテーマを提案してください。各テーマに定義、根拠となるインタビュー ID、正確な抜粋位置、矛盾するケース、別の解釈を付けてください。資料から裏付けられる場合だけ参加者の実人数を数え、未提供のインタビューを推測しないでください。観察、解釈、提案する行動を分け、引用を作らないでください。原文の確認が必要な主張を示してください。

チームが挑戦できる研究成果物を完成させます

コードブック、証拠表、未解決の解釈、提案された次の研究課題を提出します。読者は、主張から関連する抜粋に移動し、なぜその解釈を受け入れたのかを理解できるはずです。すべてのモデルが同意した結果を含む、結果として得られた結果をすべてレビューします。

生成された分析情報の数ではなく、トレーサビリティの質とレビューの労力によって作業を比較します。 Colay はクレジットと制限を使用します。拡張する前に、管理可能な許可された抜粋セットから開始します。いくつかのモデルは候補の解釈を広げることができますが、研究上の判断と参加者の証拠が結論の基礎となることに変わりはありません。

質問と回答