fix:句子問卷個性化推薦規則、

This commit is contained in:
雷汀岚
2026-01-30 18:02:46 +08:00
parent 192008986a
commit 3868bf53d1
6 changed files with 1002 additions and 0 deletions

View File

@@ -0,0 +1,255 @@
# 正念 APP文案畫像打分標準Content Profile · Cᵢ · V1
> **用途**
> 本文件定義「每一句文案如何被轉換為可計算的內容畫像Content Profile」。
> 該畫像將與 **用戶畫像 U** 進行匹配,用於個性化推薦與推送排序。
>
> **使用對象**
>
> * AI Reviewer自動打分
> * 人工內容審稿/校準
> * 推薦系統selector / ranker
---
## 一、核心原則(請務必遵守)
1. **不是評價文案好不好**,而是:
> 這句話「適合對誰說、在什麼狀態下說」
2. **能不標就不標**
* 沒有明確指向,就標為 `general`
* 不要為了打分而硬塞標籤
3. **高個性化 = 高風險**
* 指向越具體(孕吐、育兒比較、婆媳),越需要搭配禁推規則
---
## 二、Content Profile 結構總覽
每一句文案 Cᵢ需產出以下欄位
```text
C_i.stage // general / expecting / parenting / unknown
C_i.emotion_score // 01 或 general
C_i.context_suitability // 各 context 的 {0, 0.5, 1}
C_i.need_suitability // 各 need 的 {0, 0.5, 1}
C_i.personalization_power // 0 / 0.5 / 1
C_i.risk_flags // 風險標記可多個Hard Filter / Soft Penalty 會使用)
// Rerank / 去重 / 頻控所需(若資料源可提供,強烈建議補齊)
C_i.content_id // 句子唯一 ID建議 stable不隨文案微調而變
C_i.author_id // 作者/來源 ID可為空
C_i.template_id // 模板 ID可為空用於多樣性與頻控
// 置信度(可選;用於 Push 的「不確定性懲罰 / 降個性化」)
C_i.review_confidence // 01AI/人工對標註結果的置信度(缺省可按流程給預設值)
```
---
## 三、mom_stage母職階段定位規則
### 可選值
* `general`(預設)
* `expecting`
* `parenting`
* `unknown`
### 判斷標準
#### `expecting`
**必須出現以下任一類語義**
* 懷孕、孕期、孕吐、胎動、產檢、待產
* 明確指向「即將成為媽媽」的心理狀態
> 若只是提到「未來」「新階段」,不算 expecting
---
#### `parenting`
**必須出現以下任一類語義**
* 已有孩子的日常(哄睡、尿布、育兒、學校、教養)
* 明確「身為媽媽正在照顧孩子」
---
#### `unknown`
**僅在以下情況使用**
* 文案明確「不論你在哪個階段」「不管你是否是媽媽」
* 明確避免母職角色語言
---
#### `general`
* 沒有任何明確母職階段指向(**最常見**
---
## 四、emotion_score情緒調性— 連續型
### 對齊用戶 emotion 軸
| 調性 | emotion_score |
| --------- | ------------- |
| 安撫低落 / 陪伴 | 0.00.2 |
| 減壓、縮小世界 | 0.20.4 |
| 疲累修復 | 0.4 |
| 中性穩定 | 0.6 |
| 平靜、呼吸 | 0.8 |
| 慶祝、喜悅 | 1.0 |
### 打分規則
* 若文案同時包含多種調性,取**主導語氣**
* 若無明確情緒調性 → 設為 `general`
---
## 五、context_suitability影響來源適配
### 可選 context
* family / work / relationship / friends / health
### 打分方式(對每一個 context
| 分數 | 含義 |
| --- | -------- |
| 1.0 | 明確命中該情境 |
| 0.5 | 通用可推 |
| 0.0 | 不適合/可能刺痛 |
### 示例
* 提到「老公/婆婆/孩子」→ family = 1
* 提到「上班/職場拉扯」→ work = 1
* 完全抽象支持 → 所有 context = 0.5
---
## 六、need_suitability支持需求適配— **最重要**
### 可選 need
* emotional_support
* parenting_pressure
* self_worth
* anxiety_relief
* rest_balance
### 打分方式(對每一個 need
| 分數 | 含義 |
| --- | ---------- |
| 1.0 | 明確回應此 need |
| 0.5 | 部分相關/通用支持 |
| 0.0 | 無關或反向 |
### 判斷原則(舉例)
* 「你不需要撐著,我在」→ emotional_support = 1
* 「你已經做得夠好了」→ self_worth = 1
* 「慢一點、休息一下」→ rest_balance = 1
* 「不是你做錯,只是育兒真的很難」→ parenting_pressure = 1
---
## 七、personalization_power個性化力度
> 用於控制「專屬程度 vs 風險」
| 值 | 定義 |
| --- | ------------ |
| 0.0 | 完全通用(任何人都可推) |
| 0.5 | 弱指向(稍微貼近某情境) |
| 1.0 | 強指向(高度具體) |
### 判斷依據
* 是否提及具體角色/場景/困境
* 是否假設用戶正在經歷某件事
---
## 八、risk_flags禁推規則標記
> 用於 **Hard Filter**,優先於任何分數
### 重要語義(工程側必讀)
1. `risk_flags` **描述的是「這句話對哪些用戶/狀態不安全」或「需要降權」**,而不是內容的 `stage`
2. **命名規範(工程側定死)**:一律使用 `unsafe_for_*` / `block_*` / `soft_*` 前綴。
- `unsafe_for_*`:對特定用戶狀態不安全,通常進 Hard Filter場景不同可調
- `block_*`:高風險健康/醫療等,進 Hard Filter特別是 Push
- `soft_*`不做硬性過濾但在排序中做風險懲罰Soft Penalty
3. 若不確定,寧可標更保守的 flagPush 安全優先)。
### 標準 flagsV1.1,推薦使用)
* `unsafe_for_stage_unknown`
* 文案假設用戶正在育兒 / 有孩子 / 以「你作為媽媽」為前提(對 `mom_stage=unknown` 容易冒犯)
* `unsafe_for_stage_parenting`
* 文案明確懷孕語境(對 `mom_stage=parenting` 可能刺痛)
* `unsafe_for_emotion_low`
* 高昂慶祝型、過嗨、強刺激(對 `emotion_score ≤ 0.2` 不適合)
* `block_health_medical`Hard Block
* 具「醫療/診斷/嚴重暗示」:疾病確診、用藥、治療方案、醫囑、手術、急重症、危險警示等
* 這類內容在 **Health 情境** 下特別容易翻車,建議 Hard Filter
* `soft_health_sensitive`Soft Penalty
* 健康/身心照顧相關,但不含診斷/治療/嚴重暗示:疲憊、睡眠、壓力、呼吸、覺察身體、日常照護
* 不做禁推,但在 Push/Widget 需降權,避免過度私密或觸發
### 舊 flagsV1已棄用但需兼容
> 若歷史資料仍使用舊 flag工程側需在入庫/讀取時做一次映射,避免語義漂移。
* `block_stage_unknown``unsafe_for_stage_unknown`
* `block_stage_parenting``unsafe_for_stage_parenting`
* `block_emotion_low``unsafe_for_emotion_low`
* `block_health_sensitive``block_health_medical``soft_health_sensitive`
* 判斷原則:含診斷/治療/嚴重暗示 → `block_health_medical`;否則 → `soft_health_sensitive`
> AI Reviewer 若不確定,寧可標記 flag
---
## 九、AI Reviewer 打分流程(強烈建議)
1. **先判斷是否 general**(能 general 就 general
2. 再標註stage若有
3. 再決定 emotion_score主導語氣
4. 再填 context / need suitability
5. 最後判斷 personalization_power
6. 若有任何「可能翻車」風險 → 加 risk_flag
---
## 十、設計總結(一句話)
> Content Profile 的目的不是把話分門別類,
> 而是避免在錯的時間,用錯的方式,對錯的人說話。
本文件為 V1可隨實際推送數據進行校準與升級。