Xây pipeline JTBD bằng AI và JSON-ready

Mục lục bài viết23 mục

• 1.Mục tiêu nghiên cứu JTBD bằng AI
• 2.Tổng quan quy trình end-to-end (bước theo bước)
• 3.Kiến trúc JSON input chuẩn cho phỏng vấn / khảo sát / nhật ký người dùng
• 4.Ví dụ JSON mẫu: interview long-form (phỏng vấn sâu)
• 5.Ví dụ JSON mẫu: short survey free-text
• 6.Ví dụ JSON mẫu: in-app event note (nhật ký sự kiện)
• 7.Prompt mẫu: tổng hợp và phân loại jobs theo tần suất và mức đau | 360 | prompt để LLM aggregate outputs từ many utterances (list of JSON utterances) thành ranked jobs list với supportcount, painscore, personasaffected; yêu cầu cite top-3 evidence quotes và cung cấp confidencescore cùng justification ngắn; kèm cách parse và validation
• 8.Prompt mẫu: sinh hypothesis opportunity space từ tập jobs & outcomes
• 9.Quy trình thu thập dữ liệu JSON-ready (checklist)
• 10.Hướng dẫn chunking & tóm tắt an toàn trước khi nạp model
• 11.Cơ chế mapping vào JSON: rules, provenance và trạng thái inferred
• 12.Kiểm tra chất lượng output AI: checklist và tiêu chí precision/recall thực dụng
• 13.Cách đánh giá fidelity giữa raw transcript và extracted components
• 14.Quy trình thử nghiệm phân bổ nguyên nhân lỗi (root-cause analysis)
• 15.Cách hiệu chỉnh ngưỡng tiền xử lý và prompt bằng experiment
• 16.Pha trộn AI và con người: quy trình review & feedback loop
• 17.Cách build meta-classifier chống hallucination (SBERT+NLI+meta)
• 18.Kiểm soát solution-bias: prompt + post-filters
• 19.Tổng hợp và phân cụm jobs: embedding + clustering + ngưỡng merge/split
• 20.Tạo template báo cáo JTBD (cho stakeholders)
• 21.Cách gắn insights JTBD vào backlog
• 22.Các rủi ro và bias đặc thù khi dùng AI cho JTBD và cách giảm thiểu
• 23.Kết luận

Mình sẽ hướng dẫn bạn cách xây pipeline nghiên cứu JTBD dùng AI: chuẩn hoá JSON input, prompt extraction thành job/outcome, clustering, kiểm soát chất lượng và mapping thành epic trong backlog. Ví dụ minh họa áp dụng cho phỏng vấn audio và survey free-text.

Mục tiêu nghiên cứu JTBD bằng AI

Mục tiêu ngắn gọn: giúp bạn (product researcher / PM) tạo một pipeline AI có thể chuyển dữ liệu nghe/nhìn/text thô thành bộ Jobs, Desired Outcomes, và Actionable Insights đủ tin cậy để ưu tiên roadmap hoặc sinh hypotheses cho thí nghiệm. Dưới đây là mục tiêu cụ thể, phạm vi, người thực hiện, ràng buộc và tiêu chí chấp nhận cùng trade-off cần cân bằng.

• Đầu ra mong đợi (deliverables)
• Danh sách canonical Jobs (chuẩn hoá, id duy nhất).
• Desired Outcomes liên kết với mỗi Job, kèm metric đề xuất (baseline + target).
• Actionable Insights: hypotheses + suggested experiments (A/B, prototype, concierge).
• Metadata provenance cho mỗi item: sourcerefs, supportcount, confidence_score.
• Báo cáo tóm tắt để đưa vào backlog: priority_score và mapping job→epic.

• Phạm vi nghiên cứu
• Input: transcripts cuộc phỏng vấn, survey free-text, nhật ký sử dụng; không bao gồm thu thập người tham gia hoặc chi tiết kỹ thuật tích hợp API.
• Output: JSON-ready artifacts để tự động hoá bước phân tích và tạo draft epics.

• Người thực hiện chính
• Product researcher hoặc PM chịu trách nhiệm thiết kế study, kiểm duyệt schema, và review final outputs.
• AI cung cấp extraction, clustering, và synthesis; con người chịu review quyết định chiến lược.

• Ràng buộc thời gian và nguồn lực
• MVP: chạy trên 100–300 transcripts trong 2–4 tuần với 1 researcher + engineering support.
• Human review budget: dự trù 10–25% của items auto-extracted để kiểm duyệt.

• Tiêu chí chấp nhận (acceptance)
• Precision việc trích job >= 0.75 trên sample audited.
• Mỗi job auto-published phải có ≥ 3 distinct supporting utterances hoặc ≥2 nguồn độc lập.
• Evidence attached cho mọi job; nếu confidence < 0.7 thì review bắt buộc.

• Trade-offs cần nêu rõ
• Precision vs recall: ưu tiên precision khi tự động push vào backlog; ưu tiên recall cho giai đoạn khám phá.
• Automation vs human-review: tự động hoá các mapping có confidence cao và support_count đủ; giữ người review cho novel, high-impact hoặc low-confidence items.

Mục tiêu này nhằm đảm bảo AI tăng tốc phân tích JTBD nhưng không thay thế kiểm duyệt con người khi rủi ro quyết định sản phẩm cao.

Tổng quan quy trình end-to-end (bước theo bước)

Mục tiêu: chuyển dữ liệu âm thanh và text thô thành Jobs, Desired Outcomes và insight có thể hành động, kèm metadata provenance và checkpoints chất lượng ở mỗi bước.

1. Audio capture

• Input: file âm thanh, meta session
• Output: file audio, sample rate chuẩn, nguồn/consent tag
• Checkpoint: audio_length, SNR, mic channel, presence of participant consent

1. ASR (speech-to-text)

• Input: raw audio
• Output: verbatim transcript + token-level confidence + speaker diarization if có
• Checkpoint: avg ASR confidence, WER estimate on sample, speaker labels hợp lý

1. Transcript cleaning & normalization

• Input: raw transcript
• Output: cleaned transcript giữ nguyên câu trích dẫn, alt_transcripts, timestamps
• Checkpoint: không loại bỏ negation/temporal cues; percent of short/truncated utterances

1. Preprocessing (tokenization, sentence segmentation, NER)

• Input: cleaned transcript
• Output: tokenized sentences, entity spans, temporal tags
• Checkpoint: preservation of named entities, negation tokens, sentence-boundary sanity

1. JSON mapping (field mapping & provenance)

• Input: processed sentences + metadata
• Output: per-utterance JSON with fields: participantid, timestamp, questionid, utteranceraw, sourcespan, asrconfidence, participantprofile
• Checkpoint: schema validation pass, percent missing critical fields < threshold

1. Chunking & summarization (for model context limits)

• Input: JSON utterances
• Output: semantically segmented chunks with overlap and extractive summaries, plus raw excerpts attached
• Checkpoint: chunk overlap >= 20%, check that evidence spans not split across chunks

1. LLM extraction (map chunk -> JTBD components)

• Input: chunks + prompt + schema
• Output: extracted fields: jobtext, trigger, struggle, desiredoutcomes, evidencespans, extractionconfidence
• Checkpoint: JSON validity, evidence presence, model confidence threshold

1. Clustering & deduplication

• Input: extracted jobs with embeddings
• Output: clustered canonical jobs, support_count, representative quotes
• Checkpoint: cluster cohesion metrics, duplicate rate, manual review candidates

1. Synthesis & hypothesis generation

• Input: clustered jobs + outcomes
• Output: opportunity hypotheses with suggested experiments, prioritized list, estimated impact, confidence
• Checkpoint: each hypothesis has >=1 supporting quote per source type or marked low-confidence

1. Validation & human review

• Input: hypotheses + provenance
• Output: adjudicated hypotheses, corrected labels, final confidence
• Checkpoint: sample audit rate, reviewer overturn rate, inter-annotator agreement

1. Backlog integration

• Input: validated hypotheses with metrics and scope
• Output: draft epics/tickets with acceptance criteria, instrumentation tasks, priority tag
• Checkpoint: mapping to analytics metrics exist, instrumentation required flagged, review_required true for low-confidence or high-impact items

Vận hành: log provenance at mọi bước, compute uncertainty score per item, sample audits (5%+) và alerts nếu missing-field rate vượt ngưỡng.

Kiến trúc JSON input chuẩn cho phỏng vấn / khảo sát / nhật ký người dùng

Mục tiêu ngắn: cung cấp schema đầu vào chuẩn để feed LLM/AI cho nghiên cứu JTBD, bảo toàn provenance, profile người tham gia, nội dung nguyên gốc, các phiên bản transcript thay thế, và trường kiểm tra chất lượng. Dưới đây là danh sách trường bắt buộc và tùy chọn kèm kiểu dữ liệu, định dạng mẫu, và ví dụ giá trị.

Lưu ý: mọi trường provenance cần giữ liên kết tới bản nguyên (startts,endts,speakerid,sourcetype,asr_confidence).

1. session_id | string | required

• Mô tả: id duy nhất cho một buổi (file audio / entry).
• Ví dụ: “S-20260717-001”

1. participant_id | string | required

• Mô tả: id người tham gia (anonymized).
• Ví dụ: “P-045”

1. participant_profile | object | required

• fields:
• role | string | required | ex: “developer”
• personatags | array[string] | optional | ex: [“poweruser”,”mobile”]
• usage_frequency | string | optional enum {daily,weekly,monthly,rare} | ex: “weekly”
• tech_savviness | string | optional enum {low,medium,high} | ex: “high”

1. language | string | required (ISO 639-1)

• Ví dụ: “vi”

1. sourcetype | string | required enum {“audio”,”surveytext”,”diary”,”support_chat”}

• Ví dụ: “audio”

1. utterances | array[object] | required

• mỗi phần tử là một đoạn thoại hoặc một câu trả lời. Object fields:
• utterance_id | string | required | ex: “U-000123”
• start_ts | string | required ISO8601 | ex: “2026-07-01T10:12:34Z”
• end_ts | string | required ISO8601 | ex: “2026-07-01T10:12:58Z”
• speaker_id | string | required | ex: “P-045” or “INT-01”
• speaker_role | string | required enum {“participant”,”interviewer”,”system”}
• question_id | string | optional | ex: “Q-05”
• question_text | string | optional | ex: “Kể lần gần đây nhất…”
• utterance_raw | string | required (verbatim) | ex: “Ừm, lúc đang đi mình khó tìm tài liệu…”
• alt_transcripts | array[object] | optional (ASR n-best)
• text | string, confidence | number 0-1
• asr_confidence | number 0-1 | optional (avg for utterance) | ex: 0.78
• language | string | optional (per-utterance override)
• ingestion_checks | object | optional
• minlengthok | boolean, confidenceok | boolean, langdetect_confidence | number

1. annotation_tags | array[string] | optional

• Ví dụ: [“possible_trigger”,”emotion:frustration”]

1. mapped_fields | object | optional (preliminary human/auto mapping)

• job_id | string | optional
• job_text | string | optional
• segmentrole | string enum {“trigger”,”struggle”,”attempt”,”desiredoutcome”,”context”,”solution_hint”} | optional
• mappingstate | string enum {“MAPPED”,”INFERRED”,”MISSING”,”UNCERTAIN”} | required if mappedfields present
• mapping_confidence | number 0-1

1. provenance (top-level) | object | required

• recording_id | string | optional
• transcriptsource | string enum {“ASR”,”humantranscriber”,”hybrid”} | required
• transcriptgeneratedat | string ISO8601 | optional
• ingestion_version | string | optional

1. session_metadata | object | optional

• study_id | string | optional
• recruiter_notes | string | optional
• consent_flag | boolean | required

1. ingestion_id | string | required unique per record

• ex: “ing-20260717-xx”

1. ingestioncheckssummary | object | optional

• schemavalid | boolean, missingfields | array[string], warnings | array[string]

1. languagelocale | string | optional (e.g., “viVN”)

1. confidence_overall | number 0-1 | optional (aggregated)

Ví dụ JSON mẫu ngắn (minified readability):

{ “sessionid”:”S-20260717-001″, “participantid”:”P-045″, “participantprofile”:{“role”:”developer”,”personatags”:[“mobile”,”onthego”],”usagefrequency”:”weekly”,”techsavviness”:”high”}, “language”:”vi”, “sourcetype”:”audio”, “provenance”:{“recordingid”:”rec-0001″,”transcriptsource”:”ASR”,”transcriptgeneratedat”:”2026-07-17T10:00:00Z”,”ingestionversion”:”v1″}, “utterances”:[ {“utteranceid”:”U-000123″,”startts”:”2026-07-01T10:12:34Z”,”endts”:”2026-07-01T10:12:58Z”,”speakerid”:”P-045″,”speakerrole”:”participant”,”questionid”:”Q-05″,”questiontext”:”Kể lần gần đây nhất…”,”utteranceraw”:”Ừm, lúc đang đi mình rất khó tìm tài liệu kỹ thuật trên điện thoại.”,”alttranscripts”:[{“text”:”Lúc đang đi mình khó tìm tài liệu kỹ thuật trên điện thoại”,”confidence”:0.70}],”asrconfidence”:0.78,”ingestionchecks”:{“minlengthok”:true,”confidenceok”:false,”langdetectconfidence”:0.99},”annotationtags”:[“possibletrigger”]} ], “ingestionid”:”ing-20260717-001″, “ingestioncheckssummary”:{“schemavalid”:true,”missingfields”:[],”warnings”:[“utterance asrconfidence < 0.85 – review recommended”]} }

Gợi ý vận hành ngắn:

• Luôn đính kèm utteranceraw và alttranscripts để AI có nguồn chứng cứ.
• Giữ mapping_state và provenance để audit.
• Nếu field bắt buộc bị thiếu, reject record và queue cho human review.

Mình khuyến nghị bạn dùng schema trên làm JSON Schema validator trước khi feed mô hình để giảm lỗi mapping/tóm tắt/chunking.

Ví dụ JSON mẫu: interview long-form (phỏng vấn sâu)

{ “sessionid”: “S-20260717-001”, “participantid”: “P-045”, “participantprofile”: {“role”:”developer”,”personatags”:[“mobile”,”onthego”],”usagefrequency”:”weekly”}, “language”:”vi”, “sourcetype”:”audio”, “provenance”: {“recordingid”:”rec-0001″,”transcriptsource”:”ASR”,”transcriptgeneratedat”:”2026-07-17T10:00:00Z”}, “utterances”: [ { “utteranceid”:”U-000123″, “startts”:”2026-07-01T10:12:34Z”, “endts”:”2026-07-01T10:12:58Z”, “speakerrole”:”participant”, “questionid”:”Q-05″, “questiontext”:”Kể lần gần đây nhất bạn cần tìm tài liệu kỹ thuật trên điện thoại.”, “utteranceraw”:”Lúc đang đi tôi rất khó tìm tài liệu kỹ thuật trên điện thoại, hay mất mạng.”, “alttranscripts”:[{“text”:”Lúc đang đi tôi rất khó tìm tài liệu kỹ thuật trên điện thoại”,”confidence”:0.70}], “asrconfidence”:0.78, “annotationtags”:[“possibletrigger”] } ], “ingestionchecks”:{“schemavalid”:true,”warnings”:[“asrconfidence<0.85″]}, “ingestion_id”:”ing-20260717-001″ }

Giải thích ngắn: interview long-form cần session-level provenance, participantprofile để group theo persona, utteranceraw verbatim để LLM có bằng chứng. alttranscripts và asrconfidence giữ ambiguity; questionid/questiontext giúp phân biệt prompt dẫn dắt. ingestion_checks cho pipeline dừng nếu bất thường.

---

Ví dụ JSON mẫu: short survey free-text

{ “responseid”:”R-20260718-210″, “participantid”:”P-210″, “participantprofile”:{“role”:”manager”,”usagefrequency”:”monthly”}, “language”:”vi”, “sourcetype”:”surveytext”, “questionid”:”S-Q1″, “questiontext”:”Nêu một điều làm bạn thấy phiền khi dùng sản phẩm.”, “answerraw”:”Khó đặt lịch họp, giao diện rườm rà.”, “answerlength”:33, “timestamp”:”2026-07-18T21:10:00Z”, “ingestionchecks”:{“minlengthok”:true,”languageconfidence”:0.99} }

Giải thích ngắn: survey free-text thường ngắn, nên lưu answerraw nguyên văn và questiontext để ngăn LLM biến prompt thành participant voice. answerlength và ingestionchecks giúp lọc câu quá ngắn hoặc spam.

---

Ví dụ JSON mẫu: in-app event note (nhật ký sự kiện)

{ “eventid”:”E-20260719-77″, “userid”:”U-501″, “sessionid”:”S-501-07″, “timestamp”:”2026-07-19T08:45:22Z”, “sourcetype”:”inappevent”, “eventtype”:”checkoutfailed”, “eventprops”:{“errorcode”:”PAY-402″,”network”:”cellular”,”cartvalue”:49.99}, “userfeedbackraw”:”Thanh toán lỗi khi mạng yếu”, “language”:”vi”, “linkedutterance_refs”:[“U-000987”] }

Giải thích ngắn: event note phải gồm eventtype + eventprops để nối hành vi với lời phàn nàn. userfeedbackraw là nguồn text ngắn làm bằng chứng cho JTBD. linkedutterancerefs liên kết đến transcript nếu có, giúp provenance.

---

Ghi chú xử lý trường đặc biệt (tóm tắt)

• utteranceraw / answerraw / userfeedbackraw: giữ nguyên verbatim, không tự động tóm tắt trước khi đưa cho LLM; nếu cần summary, lưu song song (raw + summary).
• alttranscripts & asrconfidence: khi confidence thấp, feed cả alt_transcripts vào LLM với instruction “consider ambiguity”.
• questionid/questiontext: bắt buộc cho mọi phản hồi có source interview/survey để phân biệt interviewer prompt vs participant statement.
• participant_profile: dùng để phân cụm jobs theo persona; nếu missing nhiều, pipeline phải cảnh báo.
• provenance fields (recordingid, sessionid, linked refs): bắt buộc cho audit và để LLM trích dẫn bằng chứng khi sinh job/outcome.

Prompt để dán vào LLM (mục tiêu: chuyển raw text thành thành phần JTBD)

• System instruction (ngắn, đặt ở role system):

“You are an extraction assistant. From a raw user utterance, extract JTBD components precisely and only when supported by text. If evidence is insufficient, refuse with INSUFFICIENT_EVIDENCE. Output valid JSON exactly as specified.”

• Model settings (recommended):

temperature: 0.0 topp: 0.9 maxtokens: 512 deterministic / sampling: deterministic (no sampling, temp 0)

• Prompt body (paste as user content). Giữ nguyên format JSON mẫu cuối cùng:

1. Nhiệm vụ: cho một đoạn raw_text (verbatim), trả về JSON chứa các trường:

jobid (string unique), jobtext (string) – mô tả job in user-centric goal, không là solution, circumstance (string) – bối cảnh rút ra từ text, trigger (string) – tác nhân tức thời kích hoạt job, struggle (string) – khó khăn cụ thể user mô tả, desiredoutcomes (array of objects) – mỗi object {id, text, metricsuggestion (optional)}, evidencespans (array of objects) – mỗi object {startidx, endidx, quote, sourceid}.

1. Quy tắc quan trọng:

• Không suy diễn: nếu không có câu chữ hỗ trợ trực tiếp cho job/circumstance/trigger/struggle, trả JSON: {“refusal”:”INSUFFICIENT_EVIDENCE”} exactly.
• Nếu có bằng chứng nhưng không đủ để điền một trường, để giá trị đó là null.
• jobtext phải là mục tiêu người dùng, không là tính năng hay giải pháp. Nếu rawtext nêu giải pháp, map sang underlying goal.
• evidencespans must cite verbatim substrings from rawtext and provide start/end character indices relative to raw_text.
• jobid & outcome ids: use short stable ids like “job001″, “out_001”.

1. Output must be valid JSON only, nothing else.

• Few-shot examples (include 2 examples). Mỗi example gồm input_raw và expected JSON output.

Example 1 – brief Input_raw: “Tôi hay quên mật khẩu khi đăng nhập trên điện thoại, mất quá nhiều thời gian để reset.”

Expected JSON: { “jobid”:”job001″, “jobtext”:”Đăng nhập nhanh vào ứng dụng trên điện thoại”, “circumstance”:”khi đăng nhập trên thiết bị di động”, “trigger”:”quên mật khẩu lúc cần vào ứng dụng”, “struggle”:”phải reset mật khẩu tốn thời gian”, “desiredoutcomes”:[ {“id”:”out001″,”text”:”Hoàn tất đăng nhập trong dưới 30 giây”,”metricsuggestion”:”timetologinseconds”} ], “evidencespans”:[ {“startidx”:0,”endidx”:56,”quote”:”Tôi hay quên mật khẩu khi đăng nhập trên điện thoại, mất quá nhiều thời gian để reset.”} ] }

Example 2 – contains solution mention (must map to underlying job) Input_raw: “Thường thì mình bật chế độ ‘auto-fill’ trên trình duyệt, nhưng vẫn muốn có nút ‘one-click checkout’.”

Expected JSON: { “jobid”:”job002″, “jobtext”:”Hoàn tất giao dịch mua nhanh chóng với ít thao tác”, “circumstance”:”khi mua sắm qua trình duyệt trên điện thoại hoặc desktop”, “trigger”:”cần mua nhanh và không muốn nhập nhiều thông tin”, “struggle”:”quá nhiều bước để hoàn tất mua hàng”, “desiredoutcomes”:[ {“id”:”out002″,”text”:”Giảm số bước để hoàn thành mua hàng xuống tối đa 1-2 thao tác”,”metricsuggestion”:”checkoutsteps”} ], “evidencespans”:[ {“startidx”:24,”endidx”:67,”quote”:”vẫn muốn có nút ‘one-click checkout'”} ] }

• Template for single-run extraction (to paste with raw text inserted):

{ “rawtext”:”<PASTE THE VERBATIM UTTERANCE HERE>”, “sourceid”:”<SESSIONORRESPONSE_ID>” }

• Instruction to model to produce final JSON (copy exactly):

“Extract JTBD from the provided rawtext. Follow the rules above. Output a single JSON object with the fields: jobid, jobtext, circumstance, trigger, struggle, desiredoutcomes (array), evidencespans (array). If no sufficient evidence, output exactly: {\”refusal\”:\”INSUFFICIENTEVIDENCE\”}.”

• Notes vận hành:
• Khi xử lý nhiều utterances, call model per utterance for highest fidelity.
• Validate output JSON schema programmatically. If invalid, retry once with same settings.
• Keep rawtext and evidencespans in provenance store for audits.

Prompt mẫu: tổng hợp và phân loại jobs theo tần suất và mức đau | 360 | prompt để LLM aggregate outputs từ many utterances (list of JSON utterances) thành ranked jobs list với supportcount, painscore, personasaffected; yêu cầu cite top-3 evidence quotes và cung cấp confidencescore cùng justification ngắn; kèm cách parse và validation

Mục tiêu ngắn: cho một tập JSON utterances (mỗi utterance là một quote với provenance), prompt này yêu cầu LLM nhóm và xếp hạng các Jobs To Be Done theo tần suất và mức đau, trả về danh sách job có supportcount, painscore (0-10), personasaffected, top-3 evidence quotes, confidencescore (0-1) và justification ngắn. Kết quả phải có cấu trúc JSON hợp lệ để parse tự động.

System instruction (dùng làm role system): You are an evidence-grounded aggregator. Use only the provided utterances as evidence. Do not invent data. When grouping, prefer conservative merges. If insufficient evidence for a job, exclude it.

User prompt (chèn nguyên list): You will receive “utterances”, an array of objects with fields:

• utteranceid, participantid, persona, timestamp, rawtext, sourcetype, asr_confidence (0-1).

Task:

1. Extract candidate atomic jobs phrased as user goals (not solutions).
2. Cluster similar candidates into canonical jobs.
3. For each canonical job output: jobid, jobtext, supportcount (distinct participantids), personasaffected (list), painscore (0-10) estimated from text intensity and frequency, top3evidence (array of verbatim quotes with source refs), confidence_score (0-1) with one-sentence justification.
4. Rank output list by priorityscore, where priorityscore = normalize(supportcount) * 0.6 + normalize(painscore) * 0.4.

Rules:

• Evidence requirement: a job needs at least 2 distinct participants to be listed automatically. Otherwise mark as “candidatelowsupport” and include only if confidence_score >= 0.85.
• pain_score scale guidance: 0 no pain, 1-3 minor, 4-6 moderate, 7-8 severe, 9-10 critical. Base on explicit negative language, repeated mentions, and mentions of consequences.
• For each top evidence include participant_id and timestamp.

Output format: produce valid JSON array jobs with fields:

• job_id (string)
• job_text (string)
• support_count (int)
• personas_affected (array of strings)
• pain_score (int 0-10)
• top3evidence (array of {quote, participant_id, timestamp})
• confidence_score (float 0-1)
• justification (string, <=28 words)
• priority_score (float 0-1)

Parse and validation (to run after model response):

• Validate JSON schema; reject if any required field missing.
• supportcount must equal count of distinct participantids referenced in top evidence and in aggregated utterances for that job. If mismatch >1, flag for human review.
• confidencescore must correlate with number of supporting participants and phrase intensity. If confidencescore > 0.9 but supportcount < 2, set confidencescore := 0.6 automatically and flag.
• Ensure top3evidence quotes are verbatim substrings of some utterance.raw_text; otherwise reject job.
• Compute priority_score independently and compare to model value; if difference >0.05, prefer computed value and log discrepancy.

Ví dụ mẫu đầu vào nhỏ và mẫu output mong muốn phải được đặt trong unit test riêng trước chạy trên toàn corpus.

Prompt mẫu: sinh hypothesis opportunity space từ tập jobs & outcomes

Mục tiêu: từ một bộ canonical jobs và desired outcomes (với evidence), tạo danh sách hypothesis/opportunity statements dùng cho roadmap. Mỗi hypothesis là một câu khả thi, có bằng chứng, gợi ý experiment và ước lượng metric tác động; phân loại priority (low/med/high) kèm lý do ngắn. Dưới đây là mẫu prompt bạn dùng trực tiếp với LLM (system + user) và schema JSON đầu ra để parse tự động.

System instruction (role system): Bạn là một product strategist evidence-driven. Chỉ dùng thông tin trong input. Không thêm giả định ngoài bằng chứng. Mỗi hypothesis phải cite supportingjobs bằng jobid từ input. Trả về duy nhất JSON hợp lệ theo schema yêu cầu. Nếu bằng chứng không đủ, trả hypothesisstate: “insufficientevidence”.

User prompt (đưa kèm dữ liệu jobs & outcomes): Dưới đây là “jobslist” và “outcomeslist”. jobslist: mảng object {jobid, jobtext, personas[], supportcount, evidence: [{participantid, quote}]}. outcomeslist: mảng object {outcomeid, outcometext, metric_name, direction}. Nhiệm vụ của bạn:

1. Tạo tối đa 12 hypothesis có chất lượng cao.
2. Mỗi hypothesis phải gồm các trường dưới JSON schema: hypothesisid, statement, supportingjobs[] (jobid), expecteduservalue (1-2 câu), suggestedexperiments[] (mỗi experiment gồm type: “A/B”, “concierge”, “prototype”, description, minimalsampleorduration), estimatedimpactmetric (metricname, baselineoptional, expecteddeltaabsoluteorrelative), priority (“low”|”med”|”high”) và reasonforpriority (<=20 từ), confidencescore (0-1), hypothesisstate (“ready”|”insufficientevidence”).
3. Ưu tiên hypothesis có supportcount >= 3 hoặc supported by >=2 distinct personas. Nếu không, đặt hypothesisstate = “insufficient_evidence”.
4. Không nêu giải pháp kỹ thuật cụ thể trong statement; nếu input chứa solution-language, convert to underlying job/need.
5. Giới hạn mỗi statement <= 28 từ; reasonforpriority <= 20 từ.
6. For estimatedimpactmetric, nếu baseline không có trong input, set baselineoptional = null and mark confidencescore lower.
7. Sắp xếp output theo priority then confidence_score.

Output JSON schema (ví dụ mẫu một item): [ { “hypothesisid”: “h1”, “statement”: “Người dùng cần hoàn tất đặt hàng trên mobile trong <60s khi đang di chuyển”, “supportingjobs”: [“job12″,”job47″], “expecteduservalue”: “Giảm friction khi mua trong tình huống di chuyển, tăng conversion”, “suggestedexperiments”: [ {“type”:”A/B”,”description”:”One-page checkout vs baseline”,”sampleorduration”:”10k users / 4 weeks”} ], “estimatedimpactmetric”: {“metricname”:”conversionrate”,”baseline”:0.042,”expecteddeltarelative”:0.10}, “priority”:”high”, “reasonforpriority”:”tần suất cao, ảnh hưởng doanh thu”, “confidencescore”:0.78, “hypothesis_state”:”ready” } ]

Validation rules sau model:

• Mỗi supportingjobs[] item phải tồn tại trong input jobslist; nếu không, reject hypothesis.
• Nếu supportcount tổng < 3 và personascovered <2 then hypothesisstate = “insufficientevidence”.
• confidencescore phải tương ứng số evidence: nếu >=0.8 thì supportcount >=3 hoặc multi-source; nếu mismatch, giảm confidence_score tự động và thêm note.
• estimatedimpactmetric.expecteddelta phải là số hoặc null; nếu null, set confidencescore -=0.15.

Bạn cung cấp chỉ jobslist và outcomeslist; model chỉ sử dụng chúng để sinh hypotheses.

Quy trình thu thập dữ liệu JSON-ready (checklist)

Mục tiêu: thu dữ liệu phỏng vấn/nhật ký có thể nạp thẳng vào pipeline JSON để AI xử lý, đồng thời giữ provenance và giảm bias. Dưới đây là checklist cho bạn — phần dành cho phỏng vấn viên và phần dành cho engineer lưu trữ/ingest.

A. Trước cuộc phỏng vấn (chuẩn bị)

• Xin phép và ghi consent rõ ràng: purpose, lưu trữ, chia sẻ nội bộ, thời hạn lưu. Ghi consent_id trong metadata.
• Chuẩn câu hỏi theo dạng non-leading. Mỗi câu phải có questionid và questiontext.
• Chuẩn persona screen và capture participantid, recruitmenttags.
• Chuẩn bị thiết bị: test mic, bật speaker diarization nếu có, bật timestamping.

B. Khi thu âm / phỏng vấn (phỏng vấn viên)

• Bắt đầu bằng lời nhắc consent lồng vào ghi âm; lưu transcript consent trong metadata.
• Đọc aloud question_id trước mỗi block câu hỏi để ASR/ingest map dễ.
• Khuyến khích trả lời kiểu kể chuyện, ask-for-specifics: WHEN, WHERE, WHO, CONSEQUENCE.
• Tránh dẫn dắt: không gợi ý giải pháp; nếu người tham gia nêu giải pháp, tag là solution_mention.
• Nếu phỏng vấn qua call, bật speaker diarization; ghi rõ speaker labels (interviewer, participant).
• Ghi chú thủ công minimal: noiseevents, interruptions, emotionalcues (frustrated, excited).

C. Sau thu âm — immediate steps (phỏng vấn viên + engineer)

• Lưu raw audio file ngay: filename pattern {study}{session}{participant}_{timestamp}.wav
• Push audio vào secure storage với encryption at rest; log uploader_id and timestamp.
• Generate ASR transcript but keep raw audio and verbatim transcript. Save ASR confidence per segment.
• Save metadata file JSON kèm: {participantid, sessionid, questionids, consentid, language, locale, device, interviewer_id}.

D. Ingest / JSON mapping rules (engineer)

• For each utterance produce JSON record with required fields:
• respondentid, sessionid, utteranceid, questionid, questiontext, utteranceraw, speakerrole, startts, endts, language, asrconfidence, alttranscripts[], ingestionchecks.
• Attach provenance: sourcespan {file, start, end}, revieweroverride flag, mapping_state ∈ {MAPPED, INFERRED, UNCERTAIN, MISSING}.
• If any required field missing, set ingestion_checks.issue and route record to manual queue.

E. Security, access and retention (engineer)

• Enforce RBAC, audit logs for reads/exports, encrypt in transit and at rest, anonymize PII only after provenance preserved (store mapping table separately).
• Retention policy: record consent_expiry and auto-archive or delete accordingly.

F. Rules to avoid interviewer-bias and prompt-check

• Use neutral wording templates; require interviewer to confirm question phrasing pre-session.
• Do not ask “Would you like a button for X?” Instead ask “Describe last time you tried to X.”
• Preflight prompt-check: before exporting to AI, run short automated check on JSON to flag records where interviewer_text appears in participant fields or where >40% of participant quotes echo interviewer wording — mark for audit.
• Tag any record where participant gives solution language; add field solution_mention=true.

G. Quick operational gates (auto checks)

• Reject auto-ingest if utteranceraw length < 20 chars and utterancetype == “answer”.
• Flag for human review if asrconfidence < 0.80 or mappingstate == “INFERRED” with high impact tag.
• Sample 5% sessions weekly for provenance audit and interviewer compliance.

Thực hiện đúng checklist này giúp bạn đưa dữ liệu sạch, traceable, và ít bias vào bước tiếp theo: chuyển thành JSON input cho AI.

Hướng dẫn chunking & tóm tắt an toàn trước khi nạp model

Mục tiêu: bảo toàn ngữ cảnh quan trọng khi chia và tóm tắt transcript trước khi nạp LLM, giảm rủi ro mất trigger, conflation job-with-solution, và hallucination.

Nguyên tắc chung

• Luôn giữ nguyên văn bản nguyên gốc. Mỗi chunk hoặc summary phải kèm provenance tới đoạn raw (file, startts, endts, speaker_id).
• Ưu tiên extractive summary thay vì abstractive. Lưu cả summary và raw passage trong JSON input để mô hình có thể tham khảo nguyên văn khi cần chứng cứ.
• Đính kèm alt_transcripts: nếu ASR có nhiều đề xuất, include top-N alternatives với confidence để model giải quyết ambiguity.

Chunking: kích thước và chiến lược

• Utterance-level first: nếu bạn có speaker turns rõ ràng, chunk theo speaker turn trước. Một turn hoàn chỉnh giữ ranh giới ngữ nghĩa tốt nhất.
• Window size theo context:
• Với context lớn hơn 8k token: chunks 800–1400 token là vùng an toàn cho cuộc phỏng vấn dài.
• Với context 4k: chunks 500–900 token.
• Với context nhỏ (<2k): prefer chunk theo utterance/paragraph, không cắt mid-sentence.
• Overlap: tối thiểu 20–30% token overlap giữa chunks. Overlap bảo đảm trigger nằm trong ít nhất một chunk đầy đủ, giảm split-cue lỗi.
• Semantic segmentation ưu tiên over fixed token windows: phân đoạn theo đoạn hội thoại, thay vì cắt cứng theo n token. Dùng heuristics: break at speaker turn boundary, sentence boundary, or semantic boundary (topic change detected bằng embedding distance).

Tóm tắt an toàn

• Chọn extractive summarization làm mặc định: trích các câu nguyên văn chứa trigger, struggle, và desired outcome.
• Nếu bắt buộc abstractive summary, giới hạn paraphrase mức thấp và luôn giữ quoted utterance verbatim trong evidence.
• Yêu cầu summary có field evidence_spans: list các span offsets trích nguyên văn. Nếu summary không thể trích span thì gắn flag “UNCERTAIN”.

Metadata và fields nên kèm theo mỗi chunk

• sourceid, chunkid, startts, endts, speakerid, language, asrconfidence, alttranscripts[], rawtext, summaryextractive, ingestionchecks {minlengthok, confidenceok}, uncertaintyscore.
• Nếu chunk do preprocessor infer labels (ví dụ segmentrole), set labelsource = “AUTO” hoặc “HUMAN” và label_confidence.

Khuyến cáo về prompt và mô hình

• Khi nạp từng chunk vào model để extract JTBD components: sử dụng temperature thấp (0–0.2) cho extraction để giảm hallucination. Yêu cầu output phải cite evidence_spans.
• Với aggregation stage (cluster + synthesize), cho phép temperature cao hơn nhẹ để thêm ý tưởng nhưng bắt buộc model phải list supporting chunk_ids cho mỗi job.

Kiểm tra trước khi gửi

• Schema validation: required fields present.
• Length checks: raw_text length >= 20 chars trừ micro-utterances.
• ASR confidence: if asrconfidence < 0.85 then attach alttranscripts and mark for human review at extraction step.
• Overlap audit: ensure any token sequence containing question words or negations appears in at least one chunk fully.

Tóm tắt vận hành

• Preserve raw text and provenance. Chunk theo utterance/semantic boundary within 800–1400 token window, overlap 20–30%. Use extractive summaries and attach alt_transcripts. Enforce evidence spans and low-temperature deterministic extraction. Những quy tắc này giảm mất ngữ cảnh và bảo toàn trigger, struggle, và desired outcome khi nạp model.

Các lỗi tiền xử lý phổ biến và cách phát hiện tự động

Tóm tắt nhanh: tiền xử lý là nơi thường làm hỏng tín hiệu JTBD nhất. Những bước gây lỗi điển hình gồm truncation, stopword-removal, stemming/lemmatization, entity anonymization và sentence-split. Mỗi lỗi có cơ chế riêng và có thể phát hiện tự động bằng loạt kiểm tra schema, ngưỡng độ dài, đánh giá drift embedding, và so sánh n-gram. Dưới đây là danh sách lỗi, cơ chế gây hại, và các kiểm tra tự động bạn nên triển khai với ngưỡng khởi điểm.

1. Truncation (cắt/bỏ văn bản)

• Cơ chế gây lỗi: cắt giữa chừng làm mất trigger hoặc giải thích hoàn cảnh; mô tả trở nên vô nghĩa.
• Phát hiện tự động:
• Schema check: đảm bảo utterance_raw tồn tại và minLength >= 20 ký tự. Nếu < 20, flag để review.
• Token window check: nếu chunk chứa câu bị cắt (kết thúc không phải dấu chấm hoặc có ellipsis) => flag.
• Evidence loss test: so sánh n-gram overlap giữa raw transcript và mapped field; nếu overlap < 0.25 → cảnh báo.

1. Stopword-removal vô tội vạ

• Cơ chế: loại bỏ từ loại quan trọng như “không”, “khi”, “vì” làm mất polarity và temporal cues.
• Phát hiện tự động:
• Stopword audit: đếm tần suất các stopwords quan trọng trước/sau preprocessing; nếu giảm > 50% ở các từ negation/time → flag.
• Polarity check: chạy sentiment/negation detector trên raw và processed; nếu polarity đổi khác đáng kể → flag.

1. Stemming / lemmatization quá mức

• Cơ chế: làm mất sắc thái động từ và cụm động tác, làm mờ ranh giới giữa hành động và trạng thái.
• Phát hiện tự động:
• Lemma drift test: so sánh danh sách lemmas trước/sau; nếu nhiều lemma bị rút về cùng token (lossy merge) > threshold (ví dụ > 10% token diversity reduction) → cảnh báo.
• NER recall test: chạy NER trên raw vs processed; nếu recall giảm > 15% → flag.

1. Entity anonymization / normalization quá mức

• Cơ chế: thay tên riêng bằng generic token làm mất context (ví dụ nền tảng, đối tác).
• Phát hiện tự động:
• Entity retention metric: tỉ lệ entities được bảo toàn (entitypreservedrate). Nếu < 0.75 → review.
• Category-level vs token-level check: nếu anonymize tất cả entities thành same tag mà số lượng distinct entity giảm > 60% → cảnh báo.

1. Sentence-split / chunking sai

• Cơ chế: tách câu không theo chủ đề làm trigger và struggle nằm rời rạc trên các chunk khác nhau.
• Phát hiện tự động:
• Boundary-split test: xác định gold control phrases (ví dụ trigger keywords) bị chia qua chunk boundary; nếu > 5% trường hợp → điều chỉnh overlap.
• Overlap adequacy: nếu chunkoverlap < 20% và transcriptlength > 1500 tokens → flag.

Các kiểm tra tự động chung (automation-ready)

• Schema conformance: required fields present (utteranceraw, participantid, timestamp, language, source_type).
• Length thresholds: utteranceraw length < 20 -> flag; utterancetokens < 5 -> flag.
• ASR confidence: confidence_transcript < 0.85 -> queue for human review.
• Embedding drift: compute cosine(sim(rawembedding, processedembedding)). If < 0.85 -> flag potential lossy normalization.
• n-gram overlap: Jaccard(rawngrams, processedngrams) < 0.25 -> flag.
• Field auto-fill rate: if > 10% of critical fields auto-filled with defaults (e.g., “UNKNOWN”) -> pipeline stop.

Ngưỡng khởi điểm và cảnh báo (gợi ý)

• utterance_raw length < 20 chars -> warning
• asr_confidence < 0.85 -> review required
• chunk_overlap < 20% khi transcript > 1500 tokens -> increase overlap
• embedding cosine < 0.85 (raw vs processed) -> investigate normalization
• n-gram Jaccard < 0.25 -> possible truncation/summary loss
• NER recall drop > 15% -> problematic stemming/normalization

Cách vận hành: chạy các kiểm tra trên mỗi bản ghi khi ingest; gán ingestionchecks object vào JSON với flags và uncertaintyscore. Dùng sampling audits (2–5%) cho các bản flagged để cải thiện heuristics. Với những ngưỡng phát hiện, hãy treat as early-warning và routing tức thì tới human-in-the-loop để tránh lệch JTBD downstream.

Cơ chế mapping vào JSON: rules, provenance và trạng thái inferred

Mục tiêu: khi chuyển văn bản thô thành schema JSON để đưa vào LLM hoặc lưu kết quả JTBD, bạn phải bảo toàn nguyên văn evidence, gắn provenance rõ ràng, và đánh dấu rõ trạng thái mỗi trường để tránh model tự điền thông tin không có bằng chứng.

Nguyên tắc chính

• Giữ nguyên verbatim: luôn lưu utteranceraw nguyên gốc. Mọi trường tổng hợp phải refer lại đoạn verbatim via sourcespan.
• Không auto-fill job khi bằng chứng không đủ: nếu processor không tìm thấy evidence rõ ràng trong transcript thì để mapping_state = “MISSING” hoặc “UNCERTAIN” chứ không tự sinh job.
• Truy vết nguồn tới token/span: mỗi giá trị mapped kèm sourcerefs[] gồm {sourceid, speaker, startoffset, endoffset, excerpt}.
• Ghi confidence per-field: numeric confidence 0..1 cho từng field; dùng để lọc tự động downstream.
• Lưu audit log per-field: mỗi lần field được tạo hoặc sửa phải append một audit entry {actor, action, timestamp, reason, oldvalue, newvalue}.

Trạng thái mapping (mapping_state)

• MAPPED: giá trị trực tiếp trích từ văn bản (utterance_raw) hoặc do human annotator chỉ định.
• INFERRED: giá trị do processor/model suy diễn nhưng có evidence liên kết; bắt buộc kèm confidence >= threshold và source_refs.
• UNCERTAIN: model đề xuất nhưng evidence yếu; bắt buộc review người nếu trường này quan trọng.
• MISSING: không tìm thấy thông tin trong nguồn; không tự tạo.
• BLOCKED: field bị block do privacy/safety rule.

Cấu trúc provenance tối thiểu (ví dụ) { “jobtext”: “hoàn tất đặt hàng nhanh khi đang di chuyển”, “mappingstate”: “INFERRED”, “confidence”: 0.72, “sourcerefs”: [ {“sourceid”:”sess-123″,”speaker”:”P-45″,”start”:134,”end”:178,”excerpt”:”Tôi thường mua nhanh trên điện thoại khi đi xe buýt…”} ], “audit”: [ {“actor”:”automapperv2″,”action”:”create”,”timestamp”:”2026-07-17T10:01Z”,”reason”:”modelextract”,”oldvalue”:null,”new_value”:”…”} ] }

Policy sống còn

• Không auto-publish job->backlog nếu mapping_state != MAPPED và confidence < 0.9.
• Với mappingstate == INFERRED: yêu cầu ít nhất 2 sourcerefs độc lập hoặc human-approve trước khi dùng làm epic.
• Mọi record có mapping_state INFERRED/UNCERTAIN phải được đánh dấu trong dashboard QA để sampling review.

Ghi chú vận hành ngắn

• Thiết kế validator tự động: schema check, provenance present, confidence thresholds, audit log non-empty. Nếu bất kỳ rule vi phạm, route record vào queue human-review.

Kiểm tra chất lượng output AI: checklist và tiêu chí precision/recall thực dụng

Mục tiêu ngắn: trước khi chấp nhận output AI để đưa vào backlog hoặc báo cáo JTBD, bạn cần chạy một bộ kiểm tra tự động và một số kiểm tra ngẫu nhiên thủ công để bảo đảm output có bằng chứng, không bịa, và đủ đầy trường dữ liệu để gắn thành epic/experiment. Dưới đây là checklist nhanh, các chỉ số đo lường thực dụng và cách tính khoảng tin cậy bằng bootstrap.

1. Checklist tự động trước khi chấp nhận output (mỗi mục là yêu cầu pass/fail)

• JSON validity
• Lưu ý: parseable JSON và tuân schema (bắt buộc các trường: jobid, title, description, desiredoutcomes[], source_refs[]).
• Evidence presence
• Mỗi job phải có >= 1 sourcerefs; ưu tiên >= 2 distinct respondentids cho auto-accept.
• Mỗi sourceref phải bao gồm excerpt text + [sourceid, startoffset, endoffset].
• Field completeness
• Kiểm tra non-empty cho: title, description, desired_outcomes[]. Nếu missing critical field -> reject.
• Embedding similarity vs source
• Tính cosine(embedding(jobtext), embedding(concatenatedsource_excerpts)). Nếu similarity < 0.65 -> flag for review; nếu >= 0.8 và có multi-source support -> OK.
• Token-level confidence / model certainty
• Nếu model cung cấp token logprob or label confidence, compute avg token confidence over job_text; nếu < 0.80 -> require review.
• Nếu không có probs, use ensemble agreement proxy (multiple runs with temp=0 and temp=0.2; low agreement -> review).
• Duplicate / double-count detection
• Semantically similar jobs within batch: cluster by embedding; suppress exact duplicates, surface variants with support counts.
• Solution vs job guard
• If title/description contains solution-trigger words (button, widget, API, implement), tag as “solution_mention” and require reframe to underlying job.
• Privacy / PII check
• Source excerpts must be anonymized per policy; if PII present without consent -> block.
• Sanity checks (business rules)
• If desired_outcome proposes metric not instrumented and impact high -> block until instrumentation task created.

1. Các chỉ số nên track hàng ngày / tuần

• extractionprecision = TPextractedjobs / (TPextractedjobs + FPextracted_jobs)
• TP: AI job that human reviewer marks correct vs source.
• extractionrecall = TPextractedjobs / (TPextractedjobs + FNjobs)
• FN: gold job present in transcripts but AI missed.
• evidencecoverage = #jobs with >=1 high-quality excerpt / totaljobs
• high-quality = excerpt length >= 20 chars AND sourceasrconfidence >= threshold.
• hallucinationrate = #jobs flagged as no-support-by-source / totaljobs
• detector: substring + semantic match + NLI heuristics.
• average_confidence = mean per-job confidence score (0-1).
• reviewoverturnrate = fraction of auto-accepted jobs later reverted by humans.

1. Ngưỡng thực dụng gợi ý

• Auto-accept only if:
• evidencecoverage per job >= 2 distinct respondents OR evidencecoverage ==1 but avgconfidence >= 0.9 and embeddingsimilarity >= 0.8.
• extraction_precision (rolling 1k items) >= 0.85 for auto-publish.
• Semi-auto (draft): evidence 1 respondent AND avg_confidence 0.8-0.9 -> create draft epic for reviewer.
• Always require human review for novel jobs (embedding distance to corpus < 0.75) or high-impact changes.

1. Cách tính khoảng tin cậy (95% CI) bằng bootstrap

• Dữ liệu: N job outputs sampled with labels TP/FP (human-reviewed).
• Bootstrap procedure:
• Repeat B times (B = 1000): resample N items with replacement, compute metric (precision or recall) on resample.
• Obtain empirical distribution of metric; 2.5th and 97.5th percentiles => 95% CI.
• Báo cáo: precision ± CI; nếu CI dưới target threshold thì safe to automate; nếu upper/lower vượt target, điều chỉnh ngưỡng hoặc tăng sample size.

1. Quy trình hành động khi phát hiện vấn đề

• Nếu hallucinationrate weekly > 3% hoặc reviewoverturn_rate > 5% -> pause auto-publish, tăng human review, run root-cause (ASR vs preproc vs prompt).
• Nếu embeddingsimilarity drift downward hoặc avgconfidence giảm > 10% so với baseline -> trigger recalibration: re-label 200 samples, fine-tune prompt/schema.

Kết luận ngắn: dùng checklist để chặn lỗi cơ bản, track extractionprecision/extractionrecall/evidencecoverage/hallucinationrate liên tục, và dùng bootstrap CI cho quyết định tự động hóa. Luôn bắt nguồn output từ provenance rõ ràng; bất kỳ job nào thiếu bằng chứng hoặc low-confidence đều phải qua con người trước khi thành epic.

Cách đánh giá fidelity giữa raw transcript và extracted components

Mục tiêu: xác định xem một thành phần do AI trích xuất (job, trigger, outcome, quote) có thật sự được hỗ trợ bởi transcript nguyên gốc hay là paraphrase/hallucination. Mình trình bày ba phép kiểm chính, quy tắc kết hợp để phát hiện hallucination/paraphrase, ngưỡng gợi ý, và cách calibrate per-domain bằng labeled set.

1. Ba phép kiểm cơ bản

• Exact substring match
• Kiểm tra xem đoạn quote hoặc cụm từ trích xuất có xuất hiện nguyên văn trong rawtranscript hay alttranscripts. Nếu có, coi là evidence trực tiếp.
• SBERT embedding similarity
• Mã hóa câu trích xuất và từng câu trong transcript bằng SBERT hoặc sentence transformer tương đương. Lấy max cosine similarity giữa câu trích xuất và mọi câu nguồn để đánh giá paraphrase. Phù hợp khi ngôn ngữ thay đổi cách diễn đạt.
• NLI entailment test
• Dùng mô hình NLI (premise = đoạn transcript hoặc tập câu liên quan, hypothesis = câu trích xuất). Nếu entailment probability cao, output được coi là được suy luận từ source.

1. Quy tắc kết hợp để phân loại

• Supported (có bằng chứng trực tiếp)
• exactsubstring == true OR (sbertsim >= tsimstrong AND nlientailprob >= tnlistrong)
• Paraphrase-supported
• exactsubstring == false AND sbertsim ∈ [tsimweak, tsimstrong) AND nlientailprob >= tnlimedium
• Ghi nhãn là paraphrase, require evidence_span reference
• Hallucination (no support)
• exactsubstring == false AND sbertsim < tsimweak AND nlientailprob < tnlimedium
• Hoặc nli predicts contradiction
• Ambiguous
• Conflicting signals (sbert high but nli neutral) → mark UNCERTAIN, route human review

1. Ngưỡng gợi ý (khởi điểm)

• tsimstrong = 0.82, tsimweak = 0.68
• tnlistrong = 0.85, tnlimedium = 0.60
• exact_substring check là boolean không có ngưỡng

1. Cách calibrate per-domain với labeled set

• Chuẩn bị gold set: sample 300–1000 paired examples (extracted component, supporting transcript span) được annotator đánh nhãn: supported / paraphrase / hallucination.
• Sweep thresholds: grid search trên tsim and tnli, tính precision/recall/F1 cho từng nhãn trên validation fold.
• Chọn thresholds tối ưu theo mục tiêu:
• Nếu muốn giảm false positive hallucination (không chặn output đúng) ưu tiên precision: chọn ngưỡng cao hơn.
• Nếu muốn catch mọi hallucination, ưu tiên recall: hạ ngưỡng paraphrase.
• Kiểm tra robustness: bootstrap CI cho precision/recall; nếu CI rộng, tăng sample size hoặc thu thêm edge cases.
• Lưu cấu hình ngưỡng theo domain/lang code, log provenance: sourcespan, sbertscore, nliscore, exactmatch, reviewer_override.

1. Triaging và operational rules

• Auto-accept only if Supported.
• Paraphrase-supported → auto-draft with citation spans.
• Hallucination/UNCERTAIN → require human adjudication.
• Periodically sample adjudicated cases để retrain NLI/embedding thresholds.

Kết luận: kết hợp substring, SBERT và NLI cho phép phân biệt được paraphrase và hallucination. Calibrate ngưỡng trên gold set của domain để cân bằng precision/recall phù hợp với rủi ro sản phẩm.

Quy trình thử nghiệm phân bổ nguyên nhân lỗi (root-cause analysis)

Mục tiêu: đo tỉ lệ phần trăm lỗi JTBD qui ra từ từng bước pipeline: capture (ghi âm), transcription, preproc/mapping (normalization, chunking, tóm tắt, map vào JSON), và AI extraction/model. Kết quả báo cáo là phân bố % lỗi kèm khoảng tin cậy bootstrap và hướng sửa ưu tiên.

1. Chuẩn bị dataset và gold standard

• Chọn N transcripts = 300–1000, phân phối theo length, ngôn ngữ, channel. Mỗi transcript cần raw audio, verbatim transcript (human nếu có), timestamps, speaker labels.
• Tạo gold standard: 2–3 product researcher annotate và adjudicate thành các thành phần JTBD (jobs, triggers, circumstances, desired outcomes) với evidence spans và canonical job IDs. Đây là ground truth để so sánh.

1. Thiết kế pipeline biến thể (controlled variants)

• Baseline Auto: auto-ASR -> default preproc (standard normalization, summarization, chunking) -> auto-mapping JSON -> model extract.
• Variants để tách nguyên nhân:
• V_TxHuman: human-vetted transcript thay cho auto-ASR, giữ preproc/model auto.
• VPreprocConservative: auto-ASR, conservative preproc (no abstractive summary, larger overlap, NOFILL defaults), auto-mapping.
• V_MappingHuman: auto-ASR + preproc auto, nhưng human maps transcript -> JSON fields.
• V_ModelDifferent: giữ inputs, thay đổi model or prompt settings to measure model hallucination.
• Thêm Human-only ceiling: human transcription + human mapping + human extraction to estimate achievable ceiling and annotator variance.

1. Chạy thử và thu output

• Chạy mỗi transcript qua tất cả biến thể. Lưu provenance: which source spans were passed to model, mapping decisions, confidence scores.

1. Định nghĩa metrics và luật phân bổ lỗi

• Component-level matches: cho mỗi gold item (job/trigger/outcome) xác định:
• Matchedinoutput? bằng kết hợp exact match, fuzzy string match và embedding similarity threshold (tune trên nhỏ sample).
• Khi mismatch xảy ra, gán nguyên nhân bằng hàng bước kiểm tra tuần tự:
• Nếu gold evidence không xuất hiện trong auto-transcript (so sánh verbatim hoặc alt_transcripts), gán lỗi cho transcription.
• Nếu evidence có trong auto-transcript nhưng không có trong JSON field được gửi cho model (provenance kiểm tra bằng span mapping), gán lỗi cho preproc/mapping.
• Nếu evidence có trong JSON fields nhưng model output vẫn sai hoặc thêm nội dung không có evidence, gán lỗi cho model/extraction (hallucination).
• Nếu gold item không có evidence trong raw audio hoặc annotator không đạt IAA, mark as gold-issue and exclude from attribution or send to adjudication.
• Ghi chú: dùng earliest-fail attribution. Nếu nhiều nguyên nhân cùng tồn tại, tag multi-cause and apportion fractional blame (ví dụ 50/50) hoặc send to manual adjudication.

1. Thống kê và bootstrap CI

• Trên N transcripts, tính số lỗi attributed to each component and compute fraction pcomponent = errorscomponent / total_errors.
• Bootstrap procedure: resample transcripts with replacement 10,000 lần, recompute pcomponent each lần, lấy 95% CI percentile for pcomponent.
• Report: point estimate + 95% CI cho từng component; cũng report absolute counts and per-transcript error rate.

1. Kiểm tra so sánh giữa biến thể

• So sánh Baseline vs VTxHuman để ước lượng ảnh hưởng transcription: giảm errorrate tương đối là attribution to transcription.
• So sánh Baseline vs V_PreprocConservative để ước lượng ảnh hưởng preproc/mapping.
• So sánh Baseline vs V_ModelDifferent để ước lượng model-related errors.
• Dùng paired statistical test cho tỉ lệ (McNemar cho binary at transcript-level) hoặc bootstrap difference-in-difference để lấy CI.

1. Thực thi adjudication cho edge cases

• Lấy 5–10% lỗi phân bổ tự động ngẫu nhiên, cho panel review để kiểm tra attribution accuracy; đo attribution agreement. Nếu agreement thấp, refine attribution rules and re-run.

1. Kết luận hành động và threshold thực dụng

• Nếu preproc/mapping chiếm >30–40% lỗi với CI chắc, ưu tiên conservative preproc, provenance và human-in-the-loop mapping cho trường hợp nguy cơ cao.
• Nếu transcription lỗi chiếm nhiều, đầu tư ASR cải thiện hoặc human-vetted transcripts cho cohort quan trọng.
• Nếu model-extraction lỗi chiếm nhiều, chỉnh prompt, ensemble, hoặc thêm grounding/evidence-mandatory rules.

Ghi rõ provenance trong báo cáo và đính kèm sample lỗi tiêu biểu để đội kỹ thuật và nghiên cứu hành động.

Cách hiệu chỉnh ngưỡng tiền xử lý và prompt bằng experiment

Mục tiêu ngắn: thiết lập một protocol thực nghiệm để sweep và calibrate các tham số tiền xử lý và prompt (ASR confidence, min utterance length, label_conf thresholds, chunking, prompt temperature, v.v.) sao cho hệ thống extraction JTBD đạt yêu cầu precision/recall và trustworthiness trong từng cohort/ngôn ngữ; đồng thời cung cấp cơ chế dynamic thresholds và rules adaptive khi drift.

1. Chuẩn bị dataset hiệu chỉnh

• Tập calibration: chọn 300–1,000 transcripts representative theo chiều dài, ngôn ngữ, channel, persona. Ít nhất 200 cho bước khởi tạo; tăng tới 1,000 nếu đa dạng cao.
• Gold standard: mỗi transcript phải có annotation bởi 2 researcher cho các trường JTBD (job, trigger, circumstance, desired_outcome) kèm evidence spans; adjudicator quyết định final labels. Lưu provenance: raw audio, verbatim transcript, timestamps.
• Chia dữ liệu: calibration (60%), validation (20%), test holdout (20%) stratified theo cohort.

1. Xác định tham số cần sweep

• ASR confidence threshold t_asr (ví dụ 0.70, 0.80, 0.85, 0.90).
• Min utterance length L_min (chars hoặc tokens): ví dụ 10, 20, 40.
• Label acceptance threshold label_conf (0.5, 0.6, 0.7, 0.8) cho auto-labels/auto-mapping.
• Chunk size C (tokens) và overlap O (tokens or %): ví dụ C = 500, 1000, 1500; O = 0, 10%, 25%.
• Prompt/model params: temperature (0.0, 0.2, 0.5), maxoutputtokens, ensemble runs n.
• Post-processing dedupe thresholds: embedding cosine t_merge (0.7, 0.8, 0.88).

1. Thiết kế experiment grid và runs

• Tạo grid of configurations. Nếu combinatorial quá lớn, dùng factorial design hoặc Latin hypercube sampling để cover không gian.
• Với mỗi config chạy pipeline trên calibration set, lưu outputs cùng provenance và per-field confidences.
• Nếu dùng stochastic prompts, chạy n >= 3 seeds per config để đo variance.

1. Đo lường metric và attribution

• Metrics per config:
• Extraction precision/recall/F1 cho job/trigger/outcome so với gold.
• Evidence coverage: percent extracted items with >=1 supporting quote.
• Hallucination rate: percent generated items without supporting span in raw transcript (detect bằng substring + semantic similarity).
• JSON validity and parsing error rate.
• Operational metrics: percent records auto-accepted by rules; human-review workload.
• Đo CI: bootstrap transcripts 1,000 samples để trả 95% CI cho mỗi metric.

1. Quy trình chọn ngưỡng theo mục tiêu sản phẩm

• Xác định objective function: ví dụ maximize precision subject to human-review capacity constraint H (reviews/day). Có thể dùng cost function: Cost = cFP * FPcount + creview * reviewcount.
• Từ kết quả grid search, chọn config tối ưu theo objective. Nếu ưu tiên precision cho auto-publish, pick config có precision >= target (ví dụ 0.85) với recall chấp nhận được.
• Lưu config per-cohort/ngôn ngữ nếu performance khác biệt.

1. Cross-validation và holdout test

• Sau chọn config trên calibration, validate trên validation set; cuối cùng báo performance trên test holdout để ước lượng generalization.
• Nếu per-cohort performance lệch, maintain thresholds khác nhau cho từng cohort.

1. Dynamic thresholds per-language / per-cohort

• For each cohort maintain rolling windows metrics (weekly):
• mean ASRconfidence, extractionprecision, hallucinationrate, supportcount distribution.
• Adaptive rules:
• If mean ASRconfidence for cohort < asrthresholdbycohort -> raise human-review fraction or raise t_asr.
• If hallucinationrate rises > delta (e.g., +50% over baseline) -> automatically tighten labelconf and lower temperature, and queue recent items for review.
• If evidencesupportcount median < min_support -> disable auto-accept for that cohort.
• Store thresholds in config with versioning and meta: {cohortid, thresholds, effectivefrom, reason}.

1. Continuous monitoring and recalibration

• Monitor daily/weekly dashboards: precision, recall (sampling), hallucination_rate, auto-accept reversal rate (human undo).
• If auto-accept reversal rate > R_threshold (e.g., 5%) over rolling N items, trigger automatic recalibration: re-run the grid locally on recent 500 items and propose new thresholds.
• Use active learning: sample borderline items (score near threshold) for human labeling to improve training data and recalibration.

1. Practical heuristics and initial starting points

• ASR: auto-process if asrconfidenceavg >= 0.90; hybrid-review zone 0.80–0.90; require human transcript < 0.80.
• Lmin: narrative answers min 20 chars; for shorter micro-feedback allow 8–12 chars but require contextwindow.
• label_conf: accept auto-labels >= 0.75 for low-risk categories; require review 0.6–0.75.
• Chunking: prefer semantic segmentation, but common defaults: C = 1000 tokens, O = 20% for long transcripts.
• Prompt: extraction tasks run deterministic temp=0.0; synthesis tasks temp=0.3–0.5 with ensemble n=5 and accept items appearing in >=2 runs.

1. Reporting and governance

• For each recalibration produce audit report: dataset used, grid tried, selected thresholds, expected impact on review load, test holdout metrics and CI.
• Keep human-readable changelog and require product-research sign-off for threshold changes that affect auto-publishing or instrumentation.

1. Notes on sample sizes and power

• To estimate precision within ±0.05 with 95% CI for events around 0.8, need ~250–400 labeled items. Tailor labeling budget accordingly.
• For cohort-specific thresholds, ensure each cohort has at least 200 annotated items over time for stable estimates.

Kết luận ngắn

• Hiệu chỉnh ngưỡng là một vòng lặp experiment → select → validate → monitor. Thiết kế calibration dataset đa dạng, sweep có kiểm soát, chọn ngưỡng theo objective sản phẩm và human-review capacity, rồi duy trì dynamic thresholds per-cohort với giám sát drift và active learning. Mỗi thay đổi phải được versioned và auditable để tránh bake-in lỗi hệ thống.

Pha trộn AI và con người: quy trình review & feedback loop

Mục tiêu: thiết kế luồng làm việc rõ ràng để AI thực hiện phần lớn công việc lặp, trong khi con người giữ quyền đánh giá các trường hợp rủi ro, mới lạ, hoặc có tác động cao. Mô hình trust tiers L0-L3 và quy tắc triage dưới đây cho phép tự động hoá có kiểm soát và vòng feedback phục hồi chất lượng qua active learning.

1. Trust tiers (L0-L3)

• L0 auto-accept: output có confidence cao, evidence >= 3 respondents, trùng với canonical job, không novel, impact low. Hệ thống tự tạo draft ticket low-risk.
• L1 draft-only: confidence vừa phải hoặc evidence 2 respondents hoặc variant close to canonical. Tạo artifact draft, cần review nhanh 1 người trong vòng SLA ngắn.
• L2 require-human: novel OR impact high OR any contradiction OR supportcount ==1 OR modelconfidence < threshold. Human reviewer bắt buộc phê duyệt trước khi publish.
• L3 block: nội dung nhạy cảm, regulatory, hoặc phát hiện hallucination nặng. Block pipeline, gửi cho senior reviewer.

1. Quy tắc triage tự động

• Nếu novel == true AND impact_level >= high => route L2 mandatory human.
• Nếu solutionphrased == true => tag SOLUTIONMENTION, route L1 với yêu cầu rewrite thành job.
• Nếu provenancesupport < minsupport => route L2.
• Nếu any contradiction detected => route L3.

1. Sampling audit rates và cơ chế kiểm soát

• Baseline: sample random 5% của items auto-accepted (L0) mỗi tuần để audit thủ công.
• Adaptive sampling: tăng audit rate theo công thức auditrate = baserate * (1 + driftindex), trong đó driftindex dựa trên recent reversalrate và hallucinationrate.
• Target thresholds: nếu reversalrate > 5% trong 1 tuần, gấp đôi auditrate; nếu >10% thì tạm dừng auto-accept và chuyển các items tương tự sang L2.

1. Active learning cho retraining

• Ghi lại mọi item bị chỉnh sửa hoặc bị bác bởi reviewer. Tập hợp thành dataset huấn luyện có nhãn.
• Chọn các mẫu informative: disagreements, borderline-confidence, novel clusters, và gửi vào retraining pipeline định kỳ.
• Triển khai retrain cadence: nhỏ mỗi 2 tuần cho prompt/heuristics, lớn mỗi tháng cho fine-tune model nếu có.

1. SLA và vai trò reviewer

• SLA cho review theo tier:
• L1: review <= 48 giờ, turnaround trung bình target 24 giờ.
• L2: review <= 24 giờ, việc escalate tới senior reviewer trong 4 giờ nếu cần.
• L3: immediate within 4 giờ.
• Reviewer workload dashboard: hiển thị queue size, avg time per review, backlog age, reversalrate, %novelinqueue. Mục KPI: avg time <= SLA, reversalrate <= 5%, reviewer_utilization 60-80%.

1. Metrics dashboard và báo động

• Theo dõi: autoacceptrate, auditpassrate, reversalrate, hallucinationrate, avgsupportcount, novelrate, reviewerthroughput.
• Alert rules: reversalrate > 5% -> notify ops; novelrate spike > baseline + 3 sigma -> pause auto-publish for that cohort.

1. Audit trail và provenance

• Mỗi quyết định kèm provenance: sourcerefs, evidencespans, modelconfidence, tier, reviewerid, change_log. Dữ liệu này dùng để audit và cho active learning.

Kết luận tóm tắt: hệ thống vận hành theo L0-L3, audit sampling adaptively bảo đảm an toàn, active learning đóng vòng feedback để nâng chất lượng model, và SLA + dashboard giữ reviewer workload trong tầm kiểm soát.

Cách build meta-classifier chống hallucination (SBERT+NLI+meta)

Mục tiêu ngắn: thiết kế detector tự động đánh dấu output AI là grounded hay hallucinated bằng cách kết hợp kiểm tra trực tiếp vào nguồn, so sánh ngữ nghĩa, kiểm tra entailment, và dấu hiệu xác suất từ mô hình. Sau đó huấn luyện meta-classifier (logistic hoặc XGBoost) trên validation set, hiệu chỉnh threshold, và phân tầng cảnh báo người review theo severity.

1. Inputs và features chính (per candidate item)

• substring_match (binary): có quote nguyên văn trong source không.
• sbert_sim (float): max cosine giữa embedding candidate và mọi sentence trong source (dùng SBERT hoặc text-embedding-3).
• nli_entailment (float): entailment score từ NLI model giữa source concatenated và candidate statement (ví dụ P(entailment)).
• token_logprob (float): trung bình logprob token của candidate do LLM trả về, nếu có.
• evidence_count (int): số đoạn trích độc lập hỗ trợ candidate (distinct respondent/session).
• src_confidence (float): ASR/transcript confidence trung bình của các evidence spans.
• novelty_score (float): cosine similarity tới nearest canonical job trong corpus; thấp nghĩa mới lạ.
• length_ratio (float): tỉ lệ token candidate so với evidence quote length.

1. Nhãn và dữ liệu huấn luyện

• Tạo validation set annotated: N ≈ 1,000 candidate items, mỗi item do 2 reviewer domain label là TRUE_GROUNDED / HALLUCINATED; adjudicate tranh chấp.
• Ghi kèm severity labels: minor (thêm chi tiết không đúng), major (thay đổi ý nghĩa), critical (dẫn đến quyết định sản phẩm sai).

1. Huấn luyện meta-classifier

• Model: bắt đầu với logistic regression để dễ giải thích; nếu feature interactions quan trọng thì xài XGBoost.
• Loss: binary cross-entropy; thêm class-weighting nếu dữ liệu imbalance.
• Cross-validation: k-fold (k=5) và bootstrap để ước lượng CI cho metric.
• Metrics: AUC, precision@k, recall@k, F1; chú ý precision ở operating point.

1. Calibration threshold và stratification theo severity

• Chọn operating threshold theo mục tiêu sản phẩm. Ví dụ:
• Auto-pass (low risk): P(hallucination) < 0.05
• Flag for quick review (medium): 0.05 <= P < 0.25
• Block + senior review (high): P >= 0.25
• Calibrate bằng PR curve: fix precision target cho auto-pass (ví dụ precision >= 0.95) và chọn threshold với recall tối đa. Dùng bootstrap để lấy 95% CI.

1. Triaging và workflow vận hành

• Nếu classifier output low-risk: allow downstream processing but attach provenance and confidence.
• Medium: enqueue lightweight human check (1-2 phút) — cung cấp evidence spans và model signals.
• High: block publishing; assign to senior reviewer with full transcript and model rationale.
• Ghi log reversal: mọi case bị reviewer chỉnh sửa được trả vào training set cho lần retrain tiếp theo.

1. Giám sát và tái huấn luyện

• Monitor drift metrics: distribution của sbertsim, tokenlogprob, noveltyrate, falsepositive_rate trên audit sample.
• Retrain định kỳ hoặc khi audit false positive vượt ngưỡng.

Ghi chú triển khai ngắn

• Dùng SBERT cho semantic sim, một NLI model được fine-tuned cho entailment, và lấy token_logprob từ LLM nếu API hỗ trợ. Nếu không có logprob, dùng ensemble-agreement proxy.
• Bắt đầu với logistic để hiểu feature importance; chuyển sang XGBoost khi cần performance. Luôn kèm provenance và UI cho reviewer để giảm tải.

Kiểm soát solution-bias: prompt + post-filters

Mục tiêu ngắn: giảm việc LLM trả về “giải pháp” thay vì “job” bằng hai lớp: (1) prompt rõ ràng và few-shot examples chuyển solution -> underlying job; (2) post-filters tự động phát hiện từ/biểu thức giải pháp và ép LLM rephrase thành goal. Dưới đây là tập mẫu prompt, vài ví dụ few-shot, blacklist, patterns, và luật chuyển hoá.

1. Hướng dẫn prompt (core)

• System role: “You are a JTBD extractor. Always extract the user goal or desired outcome, not concrete implementations. If text names a solution, label it as SOLUTIONMENTION and convert to the underlying goal. Provide evidence span(s). If evidence is missing, return INSUFFICIENTEVIDENCE.”
• Temperature: 0.0 for extraction; max_tokens đủ cho JSON.
• Output: valid JSON with fields {type: “JOB”|”SOLUTIONMENTION”|”INSUFFICIENTEVIDENCE”, text: “…”, underlying_goal: “…”, evidence: […]}

1. Few-shot examples (copy-paste into prompt)

Example 1:

• Input utterance: “Tôi muốn một nút one-click để đăng ký nhanh.”
• Desired output JSON:

{ “type”: “SOLUTIONMENTION”, “text”: “nút one-click để đăng ký”, “underlyinggoal”: “giảm thời gian hoàn tất việc đăng ký khi đang vội”, “evidence”: [“Tôi muốn một nút one-click để đăng ký nhanh.”] }

Example 2:

• Input utterance: “Chúng tôi dùng Zapier để sync form vào spreadsheet.”
• Desired output JSON:

{ “type”: “SOLUTIONMENTION”, “text”: “dùng Zapier để sync form”, “underlyinggoal”: “tự động lưu trữ dữ liệu form để dễ phân tích và truy xuất”, “evidence”: [“Chúng tôi dùng Zapier để sync form vào spreadsheet.”] }

Example 3:

• Input utterance: “Muốn xem báo cáo mỗi sáng trên email.”
• Desired output JSON:

{ “type”: “JOB”, “text”: “xem báo cáo mỗi sáng”, “underlying_goal”: “nắm được tình trạng quan trọng vào đầu ngày để hành động kịp thời”, “evidence”: [“Muốn xem báo cáo mỗi sáng trên email.”] }

1. Blacklist giải pháp và detection rules

• Blacklist token sample: [“button”,”one-click”,”Zapier”,”plugin”,”API”,”integration”,”script”,”automate”,”cron”,”dashboard widget”,”shortcut”,”plugin”,”connector”,”CSV export”,”webhook”]
• Pattern heuristics:
• regex solution_verb: \b(use|install|connect|integrate|click|press|automate|sync|export|import|setup)\b
• regex tool_names: \b(Zapier|IFTTT|Slack|Stripe|Google Drive|Sheets|API|CRM)\b
• UI elements: \b(button|modal|dropdown|checkbox|form|widget|banner)\b
• If any blacklist token or pattern matched within candidate jobtext, mark as SOLUTIONMENTION.

1. Transformation rules (deterministic)

• If SOLUTION_MENTION:
• Step A: extract nouns/phrases that indicate action or tool as solution_text.
• Step B: ask LLM to answer prompt: “Given this solution: ‘<solutiontext>’ and the surrounding utterance, rewrite as underlying user goal starting with an action verb and including circumstance.” Provide one-line underlyinggoal.
• Require evidence quote(s) in output.
• If no explicit goal can be inferred from context, set type = INSUFFICIENT_EVIDENCE and include reason.

1. Post-filter workflow

• Run LLM extraction with few-shot prompt.
• Apply blacklist/pattern detector to LLM jobtext. If detector flags SOLUTIONMENTION but LLM returned type = JOB, override to SOLUTIONMENTION and call rephrase prompt to generate underlyinggoal.
• Validate resulting underlying_goal: ensure it does not contain tool/UI tokens. If it still contains solution tokens, escalate to human-review queue.

1. Short checklist cho bạn trước khi deploy

• Include few-shot examples that cover common local patterns and domain tools.
• Maintain and evolve blacklist from real data; log overrides to update patterns.
• Always store provenance: source utterance, start/end, and model responses.
• Auto-escalate ambiguous cases to human reviewer; do not let pipeline auto-accept SOLUTION_MENTION -> JOB without evidence.

Ứng dụng ngay: dán prompt + three examples vào system message; chạy extractor; bật post-filter blacklist; rephrase SOLUTIONMENTION bằng prompt mẫu và lưu underlyinggoal vào JSON.

Tổng hợp và phân cụm jobs: embedding + clustering + ngưỡng merge/split

Mục tiêu: từ tập các đoạn trích job/outcome/trigger đã được extractor tạo ra, sinh clusters hợp lý để đưa vào taxonomy JTBD, với ngưỡng tự động hợp nhất an toàn và quy tắc tách clusters khi quá đa dạng.

1. Chuẩn bị embedding

• Input cho embedding: canonical jobtext (concise job phrasing), aggregated desiredoutcomes (concatenate), trigger_text. Giữ provenance: list evidence quotes.
• Model embedding khởi điểm: model sentence-level mạnh (ví dụ OpenAI text-embedding-3-large hoặc SBERT đa ngôn ngữ). Chuẩn hóa: lowercasing optional, giữ dấu câu, no aggressive normalization that removes domain tokens.
• Tạo 3 vectors cho mỗi instance: embjob, emboutcome, emb_trigger. Lưu cùng ID instance.

1. ANN index và nearest neighbors

• Chỉ mục ANN: dùng FAISS hoặc similar; index IVF-PQ cho scale lớn. Kiểm tra recall với recall@k trên tập validation.
• Thực thi tìm k-nearest neighbors k=50 để xây đồ thị similarity nhanh.

1. Hai bước clustering (scalable then hierarchical)

• Step A – coarse clustering: chạy community detection or HDBSCAN on ANN graph to get initial candidate clusters. HDBSCAN helps label noise and outliers.
• Step B – merge clusters bằng hierarchical agglomerative clustering (HAC) dùng linkage = average and distance = 1 – S_text (định nghĩa bên dưới). HAC cho phép cắt cây theo ngưỡng có thể giải thích.
• Lý do: two-stage giúp scale và tránh merge toàn cục sai.

1. Scoring function cho pairwise similarity

• Định nghĩa score S(A,B) = w1 cos(emb_jobA, emb_jobB) + w2 cos(emboutcomeA, emboutcomeB) + w3 cos(emb_triggerA, emb_triggerB) + w4 personamatchscore.
• personamatchscore: 1 nếu persona tag identical, 0.5 nếu compatible, 0 if incompatible. Persona compatibility rulebook cần chuẩn trước.
• Gợi ý trọng số khởi điểm: w1=0.40, w2=0.25, w3=0.20, w4=0.15. Những giá trị này phải calibrate.

1. Ngưỡng merge / review / no-merge

• Dùng S_composite cho HAC cut:
• auto-merge nếu S >= 0.88 và clustersupport >= minsupport (min_support: 5 instances cho corpus trung bình; adjust theo scale).
• review-band nếu 0.75 <= S < 0.88: ghi flag review_required = true, xuất diff highlights giữa items để reviewer xem nhanh.
• no-merge nếu S < 0.75: keep separate.
• Lưu ý: ngưỡng là điểm khởi, phải calibrate theo dữ liệu bằng protocol dưới.

1. Quy tắc split cluster

• Tính intra-cluster pairwise distances: Dmean, Dmax = mean và max(1 – cos) trong cluster.
• Tính outcome entropy Houtcome: phân phối các desiredoutcome canonical IDs trong cluster, entropy cao biểu thị cluster đa modal.
• Split rules:
• nếu Dmax > 0.35 OR Dmean > 0.18, mark cluster cho splitting candidate.
• nếu Houtcome > threshold (ví dụ normalized entropy > 0.7) và có >=2 modes each with support >= minsupport, thì split theo outcome-modes.
• nếu cluster chứa >1 high-confidence persona groups with incompatible constraints, split by persona.

1. Calibration protocol bằng annotated pair set

• Tạo annotated dataset: sample N_pairs = 1,000-2,000 pairwise comparisons, humans label same-job? yes/no and reason (variant vs different).
• Dùng pairs để:
• calibrate weights w1..w4 via logistic regression mapping features to label;
• sweep thresholds for auto-merge/review/no-merge by precision/recall trade-off; pick auto-merge threshold achieving precision_target (ví dụ 0.90) on holdout.
• evaluate split thresholds by constructing synthetic heterogeneous clusters and measuring split recall.
• Bootstrap CI: compute 95% CI for precision at chosen threshold.

1. Post-processing and human-in-loop

• For each auto-merged cluster, generate:
• medoid instance, canonical phrasing candidate (LLM summarize with temp=0.0), support_count, persona distribution, top 3 evidence quotes.
• For review-band clusters, UI shows side-by-side examples, S score, and suggested merge reason; reviewer can accept/override merge or split.
• Logging: persist similarity matrices and provenance to allow undo and audits.

1. Metrics to monitor in production

• automergeprecision, reviewacceptrate, post-merge splitrate (reversions), clusterpurity (against gold), and novelty_rate (fraction new canonical jobs).
• Retrain calibration monthly or on model/version change.

Tóm tắt: pipeline thực thi embedding đa-vector, ANN neighbors, two-stage clustering, composite scoring S với weights có thể học từ annotated pairs; ngưỡng khởi điểm auto-merge >=0.88, review 0.75-0.88, no-merge <0.75; split khi intra-cluster variance hoặc outcome entropy cao; toàn bộ kịch bản phải được calibrate bằng bộ pair annotated và kèm human-in-loop cho review.

Mục tiêu ngắn: chuẩn hoá các nguồn tần suất rồi tính điểm đau (pain) tổng hợp từ ba thành phần chính, sau đó kết hợp thành priority_score để ưu tiên jobs trong backlog.

1. Chuẩn hoá frequency từ mixed sources

• Nguồn và cách chuẩn:
• Survey (ordinal): map trực tiếp sang tỷ lệ/month. Ví dụ: “daily”=20, “weekly”=4, “monthly”=1, “rarely”=0.25. Sau đó chuẩn hoá sang 0..1 bằng f_norm = min(1, value/20).
• Self-reported (free text): rule-based hoặc classifier extract tokens time-unit; chuyển sang giá trị tương tự và chuẩn hoá như trên.
• Inferred from logs: dùng event rate per user per 30 days r. Map f_norm = min(1, r / 20) để tương thích với survey scale.
• Aggregation across nguồn:
• Tính weighted average: frequency = (wsurvey * fsurvey + wself * fself + wlogs * flogs) / (wsurvey + wself + w_logs).
• Khuyến nghị trọng số mặc định: wsurvey=1, wself=0.8, wlogs=1.2. Nếu logs là nguồn tin cậy hơn, tăng wlogs.
• Thresholds đơn giản để gắn nhãn tần suất:
• low: frequency < 0.15
• medium: 0.15 <= frequency < 0.4
• high: frequency >= 0.4

1. Thành phần pain score (composite)

• Cấu trúc: painscore = α * frustrationsignal + β effort_cost + γ failure_rate
• Thành phần đo:
• frustration_signal (0..1): từ sentiment/specific keywords hoặc survey Likert về mức khó chịu. Map Likert 1..5 -> (0..1): (likert-1)/4.
• effort_cost (0..1): estimated time/steps to complete task normalized. Ví dụ time in seconds t -> effort = min(1, t/600) nếu >10 phút là 1.
• failure_rate (0..1): tỷ lệ thất bại hoặc lỗi từ logs; nếu không có logs, estimate từ self-report.
• Trọng số khuyến nghị: α=0.45, β=0.35, γ=0.20. Lý do: frustration thường phản ánh pain chủ quan mạnh nhất.
• Ví dụ: frustration 0.8, effort 0.6, failure 0.3 => pain = 0.450.8 + 0.350.6 + 0.2*0.3 = 0.36+0.21+0.06 = 0.63

1. Từ frequency + pain -> priority_score

• Công thức gợi ý: priorityscore = normalize( wF * frequency + wP * painscore )
• khởi điểm: wF = 0.4, wP = 0.6 để ưu tiên pain hơn tần suất
• normalize về 0..1: divide by (wF + wP) vì both in 0..1 so result already in 0..1
• Tiering (ngưỡng thực dụng):
• critical: priority_score >= 0.75
• high: 0.55 <= priority_score < 0.75
• medium: 0.35 <= priority_score < 0.55
• low: < 0.35
• Kiểm soát provenance và confidence:
• Kèm mỗi giá trị frequency, pain và priority một trường confidence (0..1) tính từ nguồn (logs higher confidence) và agreement giữa nguồn. Nếu confidence < 0.6, gắn tag “review_required” trước khi auto-prioritize.
• Ghi chú vận hành:
• Calibrate trọng số và thresholds trên gold set 200-500 items, dùng bootstrap CI.
• Nếu muốn ưu tầm ảnh hưởng kinh doanh hơn, tăng wP hoặc nếu muốn ưu tần suất, tăng wF.

Mục tiêu phần này: cung cấp template tiêu chuẩn để chuyển một job/insight JTBD thành một epic trong backlog, kèm cách tính success metrics, recommended experiments, assumptions, effort estimate, confidence, và policy rõ ràng để hệ thống có thể auto-create hoặc require review.

Template epic (trường bắt buộc)

• epic_title (string): tiêu đề ngắn gọn, noun-phrase, tránh nêu giải pháp.
• hypothesis_statement (string): câu “Nếu chúng ta… thì người dùng sẽ…” theo format hypothesis (cause → effect → metric).
• successmetrics (array): mỗi mục gồm {metricname, metrictype (time/percent/count), leadingor_lagging (leading|lagging), baseline, target, rationale}.
• recommendedexperiments (array ordered): mỗi experiment gồm {phase (discovery|MVP|scale), name, briefgoal, method (qual/quant/A-B/concierge), successcriteria (metric + threshold), estimatedduration}.
• assumptions (array of strings): giả thuyết cần kiểm chứng trước khi commit dev work.
• estimatedeffort (object): {discoverydays, mvpstorypoints, scalestorypoints, owner_squad}.
• confidence (float 0..1): tổng hợp provenance + modelconfidence + humanvotes.
• provenance (array): list of evidence entries {sourcetype (interview/survey/log), sourceid, excerpt, startts, endts, respondent_id}.
• tags (array): personas, channel, platform, priority_tags.
• riskflags (array): privacy | legal | regulatory | technicalunknown.
• createdby (string) và createdat (ISO8601).
• reviewrequired (boolean) và reviewreasons (array) nếu true.
• notesforreviewer (string): hướng dẫn review ngắn.

Ví dụ ngắn (nội dung minh họa)

• epic_title: “Hoàn tất đặt hàng nhanh khi di chuyển”
• hypothesisstatement: “Nếu giảm timetocompletecheckout xuống <=45s cho người dùng mobile onthego thì conversionrate sẽ tăng 10% trong cohort mobilehigh_frequency.”
• successmetrics: [{metricname: “timetocompletecheckout”, type:”time”, leadingor_lagging:”leading”, baseline:120, target:45}]
• recommendedexperiments: [{phase:”discovery”, name:”shadow checkout interview”, method:”concierge”, successcriteria:”identify 3 viable flows”} …]
• assumptions: [“Người dùng có ít nhất một phương thức thanh toán lưu sẵn”]
• estimatedeffort: {discoverydays:10, mvpstorypoints:20, scalestorypoints:60, owner_squad:”checkout”}
• confidence: 0.62
• provenance: [{sourcetype:”interview”, sourceid:”int-20260601-12″, excerpt:”Tôi đang đi xe bus và muốn mua gấp, không muốn nhập nhiều thông tin.”}]
• review_required: true
• review_reasons: [“confidence < 0.7”, “metric not found in analytics registry”]

Policy: khi auto-create epic vs require review

• Auto-create allowed only khi ALL điều kiện sau đúng:

1. confidence >= 0.85
2. provenance chứa >= 3 distinct respondent_ids OR >=2 sources with one quantitative support
3. successmetrics.map(metricname) exists in analytics_registry AND baseline is populated
4. risk_flags is empty
5. description does not contain obvious solution phrasing (detected by solution-word filter)

• Nếu bất kỳ điều kiện trên không thỏa, hệ thống sẽ:
• nếu confidence in [0.7,0.85) và provenance đủ (>=2 distinct respondents) thì auto-create draft epic with reviewrequired = true and assign to productresearcher.
• nếu confidence <0.7 OR provenance <2 distinct respondents OR any risk_flags present thì block auto-create; create candidate ticket in research queue for human triage.

Quy trình review ngắn

• Reviewer check 3 yếu tố: (1) evidence traceability (provenance excerpts), (2) metric validity (baseline + instrumentation), (3) assumption testability. Reviewer có thể chỉnh hypothesis_statement, adjust target, hoặc move to discovery task.

Gợi ý vận hành

• Gắn mỗi epic auto-created một auditlog entry kèm promptversion và model_version.
• Hàng tuần sample 5% auto-created epics để audit. Nếu false-positive rate >5% trong audit, giảm threshold auto-create confidence 0.05 và tăng review sampling.

Mẹo thực tế

• Luôn để field reviewrequired mặc định true cho jobs novel (nearestneighbor_similarity to corpus < 0.80).
• Khi auto-generate recommended_experiments, ưu tiên discovery experiments trước khi commit dev scope.

Tạo template báo cáo JTBD (cho stakeholders)

Mở đầu ngắn: mục tiêu báo cáo này là cung cấp một template sẵn để bạn dán vào tài liệu cho stakeholders. Mỗi trường có định nghĩa ngắn, ví dụ thực tế và snippet text-ready để paste thẳng vào doc.

1. executive_summary (30–60 từ)

• Mục: tóm tắt 2–3 câu: vấn đề chính, cơ hội lớn, đề xuất tiếp theo.
• Snippet paste-ready:
• “Executive summary: Người dùng gặp khó khăn khi [ngữ cảnh]. Chúng ta thấy cơ hội cải thiện [desired outcome] cho [persona] với ước tính tác động là [metric uplift]. Khuyến nghị: thực hiện 2 thí nghiệm discovery trước khi phát triển.”

1. topjobsranked (with evidence and scores)

• Mục: danh sách top 3–7 jobs, mỗi job gồm title, supportcount, painscore, top evidence quotes, confidence_score.
• Snippet format (paste-ready for each job):
• “1) Job: [job title]

Support: [N] respondents | Pain: [1–5] Confidence: [0.0–1.0] Evidence: “[verbatim quote]” — source: [interview_id/timestamp]”

1. opportunity_hypotheses

• Mục: từ mỗi top job sinh 1–2 hypotheses hành động, gồm assumption and expected outcome.
• Snippet example:
• “Hypothesis: Nếu chúng ta [solution-neutral intervention], then [measurable outcome] for [persona]. Key assumption: [assumption].”

1. recommended_experiments

• Mục: đề xuất prioritized experiments (discovery → prototype → A/B), với success_criteria và duration estimate.
• Snippet example:
• “- Experiment: Concierge test for quick-checkout

Goal: validate reduction in timetocheckout Success: reduce median time from Xs to Ys in pilot Duration: 2 weeks”

1. roadmapmapping (job -> epic -> successmetric)

• Mục: mapping rõ ràng từ job tới epic đề xuất và metric đo thành công, kèm baseline + target.
• Snippet example:
• “Job: Reduce time to complete checkout

Epic: One-tap mobile checkout MVP Success metric: timetocomplete_checkout (baseline: 120s → target: 45s)”

1. confidence & caveats

• Mục: tổng hợp confidence levels, nguồn rủi ro và caveats (bias, sample limitations).
• Snippet example:
• “Confidence: 0.62 — Evidence: 5 interviews, 2 survey responses. Caveats: sample skewed to power users; ASR confidence low in 2 sessions.”

1. appendix with provenance and raw quotes

• Mục: liệt kê tất cả source_refs, verbatim quotes, raw JSON paths để audit.
• Snippet format:
• “Appendix: sources
• int2026060112 | 00:03:21–00:03:42 | ‘Tôi đang đi xe bus…’
• survey20260605Q1 | respondent_045 | ‘Mất nhiều thời gian khi…'”

Gợi ý trình bày cho stakeholder doc

• Đặt executive_summary lên trang đầu
• Bôi đậm job titles và success metrics
• Đính kèm appendix cuối để reviewer mở evidence
• Nếu confidence < 0.7, thêm banner “Requires review” ở đầu báo cáo

Checklist nhanh trước khi gửi

• Mỗi job có ≥1 verbatim quote
• Mỗi suggested epic có baseline + target hoặc note “instrumentation required”
• Mỗi low-confidence item đánh flag review_required

Kết thúc: dùng các snippet ở trên để paste trực tiếp vào stakeholder doc; chỉnh thông tin trong [] cho khớp dữ liệu của bạn.

Cách gắn insights JTBD vào backlog

Mục tiêu: biến mỗi job được xác thực thành một epic có acceptance criteria đo được, sẵn sàng cho discovery hoặc development. Mình trình bày quy tắc mapping, cách đặt tên, cách viết acceptance criteria từ desiredoutcomes, kế hoạch instrumentation, cách xếp ưu tiên bằng priorityscore, và ví dụ phá vỡ thành sprint-level tasks.

1. Quy tắc chuyển job → epic

• Điều kiện khởi tạo epic: job có supportcount >= threshold và confidence >= thresholdconfidence, hoặc được human-approved.
• Nếu job là variant của canonical job đã có, ghi vào existing epic như sub-ticket; không tạo epic mới tự động.

1. Naming convention epic

• Mẫu: [JOB] — [Persona] — [Context]
• Ví dụ: “Hoàn tất đơn hàng nhanh — Mobile Buyer — On the go”
• Giữ ngắn, dùng goal-oriented phrasing, tránh nêu giải pháp trong tiêu đề.

1. Acceptance criteria từ desired_outcomes

• Mỗi desiredoutcome phải map thành một success metric cụ thể: metricname, baseline, target, direction, time_window.
• Acceptance criteria phải là câu kiểm tra được, ví dụ:
• “Giảm median timetocomplete_checkout từ 120s xuống <=45s trong 28 ngày sau release.”
• “Tăng tỷ lệ checkout_success trong mobile session từ 72% lên >=78% trong 30 ngày.”
• Nếu desired_outcome chưa có metric, add instrumentation task trước khi epic tiến vào development.

1. Kế hoạch instrumentation

• Step A: xác định metric_exist? query analytics registry.
• Nếu metric tồn tại, link query và baseline_value.
• Nếu không, tạo task “Create metric: <metric_name>” với acceptance: metric visible in analytics and dashboarded.
• Luôn attach analytics owner và query snippet vào epic.
• Nếu metric dựa trên proxy (ví dụ cảm xúc), ghi rõ proxy metric và plan thu thập (surveys, short in-app prompt).

1. Triage priority bằng priority_score

• Tính priorityscore = w1*frequencynorm + w2pain_score + w3impactestimate + w4*strategicfit.
• Gợi ý trọng số: w1 0.35, w2 0.30, w3 0.25, w4 0.10. Calibrate theo tổ chức.
• Tạo các bucket: P0 (blocker/high), P1 (high), P2 (medium), P3 (low).
• Trong backlog grooming, sắp theo priorityscore; kèm confidence và supportcount để quyết review.

1. Sprint-level breakdown example (epic: One-tap mobile checkout)

• Sprint 0 (Discovery, 2 wks)
• Task 1: Run 5 concierge tests to validate friction points.
• Task 2: Instrument timetocomplete_checkout event and dashboard baseline.
• Deliverable: hypothesis statement, sample size calc.
• Sprint 1 (MVP, 2 wks)
• Task 3: Implement tokenized payment flow behind feature flag.
• Task 4: Launch 5% canary, monitor metrics.
• Deliverable: telemetry showing change vs baseline.
• Sprint 2 (Iterate, 2 wks)
• Task 5: A/B test UI microcopy and prefill logic.
• Task 6: Evaluate results, decide scale or kill.
• Deliverable: decision and next steps.

Kiểm tra trước khi chuyển epic vào development

• Có evidence quotes kèm source_refs.
• Metric linked and baseline provided OR instrumentation task exists.
• Priorityscore và reviewowner ghi rõ.
• Review_required flag cleared nếu confidence cao.

Kết luận ngắn: luôn bắt đầu bằng job rõ ràng, derive acceptance criteria từ desired_outcomes, đảm bảo metric được instrumented, rồi chia nhỏ thành discovery → MVP → iterate. Mỗi epic cần provenance và confidence để tránh xây tính năng dựa trên giả thiết yếu.

Mình sẽ trình bày thiết kế nghiệm thu cho micro-experiments và 2-arm A/B test để kiểm chứng hypothesis JTBD do AI sinh ra so với hypothesis do con người sinh ra. Nội dung ngắn, thực dụng, đủ để bạn triển khai ngay.

1. Định nghĩa KPI (và cách chọn)

• Chọn 1 primary KPI liên quan trực tiếp tới job. Ví dụ: completionrate, conversionrate, timetocomplete, retention_7d.
• Chỉ chọn metric có thể đo được và có baseline rõ ràng trong analytics.
• Liệt kê 1–3 secondary KPIs (safety/UX/behaviour) để phát hiện tác dụng phụ.

1. Xác định MDE (minimum detectable effect) và sample size

• MDE là thay đổi tối thiểu bạn muốn phát hiện với ý nghĩa hành động. Chọn MDE dựa trên chi phí triển khai và kỳ vọng kinh doanh.
• Với binary KPI (conversion), dùng công thức xấp xỉ:
• zalpha = z(1 – alpha/2), zbeta = z(power)
• nperarm ≈ [ (zalpha*sqrt(2*p*(1-p)) + zbetasqrt(p1(1-p1)+p2*(1-p2)))^2 ] / (p2 – p1)^2
• đơn giản hơn với p1 = baseline p, p2 = p*(1+relative_MDE)
• Với continuous KPI (time), dùng công thức t-test: n = 2(z_alpha+z_beta)^2 sigma^2 / delta^2, với sigma là độ lệch chuẩn ước tính, delta MDE tuyệt đối.
• Thực hành: tính bằng công cụ sample-size calculator; nếu traffic thấp, tăng MDE chấp nhận được hoặc dùng proxy metric.

1. Testing window và power considerations

• Chạy test đủ lâu để thu số mẫu tính theo sample size, và vượt qua chu kỳ sản phẩm/seasonality. Thường tối thiểu 2–4 tuần để ổn định behavior.
• Đảm bảo mỗi user chỉ xuất hiện trong một điều kiện (independent units) hoặc dùng cluster-randomization nếu random user không khả thi.

1. Randomization plan

• Đơn vị ngẫu nhiên hóa: user_id (ưu tiên), session, hoặc account. Ghi rõ seed, hashing method, và lưu cohort assignment để reproducibility.
• Stratify theo các biến quan trọng (region, device, newvsexisting) nếu sample imbalance có thể ảnh hưởng KPI.
• Kiểm tra balance pre-launch: các covariates chính phải phân bố tương đồng.

1. Guardrails và stop rules

• Predefine safety metrics and abort thresholds (ví dụ tăng error_rate, giảm retention hơn X%).
• Không peek-and-stop: pre-register stopping rules. Nếu dùng sequential testing, áp dụng correction (alpha spending) hoặc dùng Bayesian monitoring.

1. Example: 2-arm A/B — AI-derived vs human-derived hypothesis

• Setup:
• Primary KPI: micro_conversion (binary).
• Baseline p = 0.05 (giả định để minh họa), desired relative MDE = 20% → p2 = 0.06.
• Alpha = 0.05, power = 0.8 → compute nperarm ≈ dùng calculator → ~? (thực tế bạn tính theo công thức hoặc tool).
• Randomize users 1:1, stratify by country.
• Testing window 4 weeks, collect events, ensure independent exposure.
• Guardrails: abort if negative lift > 10% with p < 0.01 on safety metric.

1. Pre-registration và analysis plan (phải có trước khi chạy)

• Record: hypothesis statement, primary KPI, baseline, MDE, alpha, power, nperarm, randomization seed/stratification, exclusion rules, primary analysis method (two-proportion z-test or logistic regression), covariate adjustments, handling of missing data, and stopping rules.
• Analysis:
• Primary: intention-to-treat (ITT) two-sided test; report point estimate, 95% CI, p-value.
• Secondary: per-protocol analysis, subgroup analysis (pre-specified), multiplicity correction for multiple comparisons.
• Robustness: bootstrap CI, Bayesian posterior intervals optional.
• Reporting: include effect size, N per arm, fidelity metrics (exposure rate), and evidence provenance linking back to JTBD sources.

Kết luận ngắn

• Thiết kế nghiệm thu phải link trực tiếp job → KPI → MDE → sample size → randomization → guardrails → pre-registration → analysis. Tránh chạy thử nửa vời: nếu traffic không đủ, tăng MDE hoặc làm pilot qualitative trước. Nếu bạn muốn, mình có thể gửi file checklist pre-registration và mẫu compute-sheet để bạn nhập baseline và MDE, thì sẽ cho ra sample size chính xác.

Các rủi ro và bias đặc thù khi dùng AI cho JTBD và cách giảm thiểu

Mình liệt kê các rủi ro chính khi dùng AI trong nghiên cứu Jobs To Be Done (JTBD), giải thích cơ chế gây lỗi, rồi nêu biện pháp giảm thiểu ở hai lớp: technical và operational. Cuối phần là gợi ý cho monitoring alerts và remediation playbook.

1. Hallucination (mô hình tạo thông tin không có bằng chứng)

• Cơ chế: model sinh ra job hoặc desired outcome không dựa trên trích đoạn transcript.
• Technical mitigations: yêu cầu evidence spans trong output; bắt buộc trích dẫn start/end token của transcript; dùng ensemble + NLI/SBERT để kiểm tra grounding; cho model chế độ deterministic (temperature thấp) ở bước extraction.
• Operational mitigations: mọi job mới phải có >= 2 respondent độc lập để auto-accept; jobs mới chỉ vào backlog dạng draft nếu chỉ có 1 nguồn.
• Alert/remediation: alert khi tỉ lệ outputs không có evidence > 2% trong batch; remediation: quarantine bộ job đó, tăng sampling human review cho batch.

1. Solution-bias (AI gán giải pháp thay vì job)

• Cơ chế: training data và prompt dẫn model ưu tiên biểu đạt giải pháp.
• Technical: thêm few-shot examples chuyển solution -> underlying job; blacklist các từ chỉ giải pháp trong field jobtitle và ép model trả “SOLUTIONMENTION” nếu phát hiện; post-filter để chuyển giải pháp thành job bằng template “Why does this solution matter?”.
• Operational: huấn luyện interviewer hỏi theo job-first phrasing; reviewer phải rewrite bất kỳ job chứa solution.
• Alert: tần suất job có token solution_words > threshold (ví dụ 30%) → trigger retrain prompt and sampling.

1. Sample bias (mẫu không đại diện)

• Cơ chế: dữ liệu phỏng vấn quá tập trung vào một persona hoặc kênh.
• Technical: attach participant_profile metadata và compute representativeness score; khi synthesize, weight theo population strata.
• Operational: thực hiện stratified sampling khi thu phỏng vấn; yêu cầu minimum respondents per segment trước khi generalize.
• Alert: nếu top-segment chiếm > 60% của batch, flag and pause auto-aggregation.
• Remediation: bổ sung target recruiting hoặc downweight overrepresented group.

1. Language drift và cultural misinterpretation

• Cơ chế: model yếu ở ngôn ngữ hay dialect, dẫn tới mất nuance hoặc mistranslation.
• Technical: dùng locale-specific models or translation with back-translation checks; preserve original verbatim and provide bilingual evidence to model.
• Operational: require bilingual reviewer for low-resource languages; add idiom lexicons into preprocessing.
• Alert: high mismatch between translated and original embedding similarity > threshold → route to human review.

1. Privacy / leak risk

• Cơ chế: transcript chứa PII, model lưu prompt history hoặc output chứa sensitive data.
• Technical: anonymize at ingestion with reversible tokenization that preserves role/context; strip PII by rule + model-assisted detection; ensure model provider contract prohibits data retention.
• Operational: only store provenance IDs, not full PII in outputs; enforce data access controls and audit logs.
• Alert: PII detected in output → immediate revoke publish and run secure scrub pipeline.

1. Over-reliance on model (automation bias)

• Cơ chế: team tin output AI mà bỏ qua review, dẫn tới roadmap sai.
• Technical: surface confidence, provenance, and source_counts with every insight; automatic gating rules based on confidence.
• Operational: define trust tiers – auto-accept, draft-with-review, require-review; mandatory human sign-off for high-impact epics.
• Alert: if auto-accepted epics reversed by humans > X% in rolling window → tighten gates and retrain prompts.

Monitoring alerts and remediation playbook – ngắn gọn

• Metrics to monitor: hallucinationrate, solutionwordrate, representativenessindex, languagemismatchrate, PIIleakevents, autoacceptreversal_rate.
• Alert thresholds: set conservative defaults (e.g., hallucinationrate > 2%, autoacceptreversalrate > 5%, top-segment > 60%).
• Remediation steps:

1. Quarantine affected outputs and tag provenance.
2. Run targeted human audit sample to measure scope.
3. Patch at nguồn: adjust prompt, increase chunk overlap, update anonymization, or re-balance sampling.
4. Re-process affected dataset after fix and publish audit log.
5. If severe (PII leak or regulatory risk), trigger incident response and notify stakeholders.

Tóm lại, kết hợp ràng buộc kỹ thuật (evidence-first, ensemble, locale-aware) với quy trình vận hành (gates, sampling review, recruitment balance) là cách thực dụng để giảm bias và hạn chế rủi ro khi dùng AI cho JTBD.

Kết luận

Sau khi áp dụng pipeline này, bạn sẽ có quy trình JSON-ready để chuyển dữ liệu phỏng vấn và survey thành Jobs, Desired Outcomes và hypotheses có provenance rõ ràng, đủ để ưu tiên roadmap hoặc khởi tạo experiments. Hệ thống cũng cho phép cân bằng tự động hóa và kiểm duyệt con người để giảm rủi ro khi đưa insight vào backlog.

Lưu ý thực tế quan trọng: luôn giữ provenance verbatim và threshold human-review nghiêm ngặt cho các mục low-support hoặc low-confidence để tránh auto-publish insight không có bằng chứng.