Trả lời ngắn: Narrative là câu chuyện rộng giúp ta chú ý một chủ đề; research question là câu hỏi có phạm vi, biến số, thời gian và cách kiểm tra bằng evidence. Research không coi narrative là kết luận. Nó dùng narrative để đặt câu hỏi, ghi dữ liệu ủng hộ và dữ liệu có thể làm hypothesis sai.

Đọc xong, bạn sẽ hiểu:

  • Vì sao “AI on-chain sẽ bùng nổ” chưa phải câu hỏi nghiên cứu.
  • Cách tách narrative, claim, hypothesis và research question.
  • Cách ghi variable, proxy, source, data cut-off và invalidation.
  • Cách làm một research-question card trong 15 phút.

Lưu ý giáo dục: Bài chỉ phục vụ học tập, không phải lời khuyên mua bán và không cam kết kết quả. Ví dụ và bảng số là simulated; dữ liệu thật cần nguồn, thời điểm chốt và kiểm tra độc lập.

1. Narrative và research question là gì?

Narrative là một khung diễn giải rộng, thường gồm chủ đề, câu chuyện và kỳ vọng của cộng đồng. Ví dụ: “AI on-chain sẽ bùng nổ”, “RWA sẽ thay đổi tài chính” hoặc “unlock làm thanh khoản xấu đi”. Các câu này có thể hữu ích để biết nên đọc về đâu, nhưng chúng chưa nói rõ chủ thể nào, thời gian nào, biến nào và evidence nào sẽ làm ta đổi ý.

Research question là câu hỏi có thể kiểm tra bằng evidence. Nó thường có năm phần: chủ thể, hiện tượng cần quan sát, thời gian, nguồn và điều kiện sai. Câu “Token này có tốt không?” quá rộng. Câu “Trong 90 ngày, usage lặp lại của nhóm ứng dụng X có tăng so với baseline được định nghĩa trước không?” đã có phạm vi hơn, dù vẫn cần định nghĩa usage và baseline.

Hãy tưởng tượng narrative như tiêu đề báo về một khu phố mới. Nó giúp bạn đi tới đúng khu vực. Research question giống danh sách câu hỏi khi đến nơi: có giấy phép không, có người ở không, đường đi thế nào và dữ liệu được chụp ngày nào. Không thể dùng tiêu đề thay cho việc kiểm tra.

Hình 1 — Narrative chỉ là cửa vào; câu hỏi phải đi qua claim, evidence và invalidation trước khi thành research.

2. Phễu từ câu chuyện đến câu hỏi

Bắt đầu bằng claim, tức mệnh đề cần kiểm tra. Narrative “AI on-chain sẽ bùng nổ” có thể tách thành claim hẹp hơn: “Một nhóm ứng dụng AI on-chain có usage lặp lại tăng trong 90 ngày”. Claim này vẫn chưa phải hypothesis hoàn chỉnh nhưng đã có chủ thể và thời gian.

Tiếp theo là hypothesis, tức cách trả lời tạm thời có điều kiện: “Nếu nhu cầu sử dụng thật tăng, số lần dùng lặp lại và số người quay lại sẽ tăng, nhưng cần tách bot và multi-address”. Hypothesis không phải lời khẳng định chắc chắn. Nó là bản nháp để biết mình phải tìm gì.

Sau đó đặt scope, là ranh giới chủ thể, thời gian và biến. Chọn một nhóm ứng dụng, một chain, 90 ngày và một định nghĩa usage. Đừng nói “toàn bộ Crypto” nếu bạn chỉ có dữ liệu của một explorer. Scope nhỏ nhưng rõ thường tốt hơn câu hỏi lớn không thể kiểm tra.

Một variable là điều được quan sát hoặc so sánh, chẳng hạn số lần gọi contract, retention hoặc depth. Proxy là chỉ báo thay thế không hoàn toàn biến đích. Active address có thể là proxy cho activity, nhưng không đồng nghĩa với số người dùng thật. Phải viết rõ proxy đang thay thế cho điều gì và giới hạn ở đâu.

Hình 2 — Hypothesis card buộc người viết ghi biến, thời gian và nguồn trước khi đi tìm dữ liệu hợp ý.

3. Ví dụ: Narrative về hạ tầng AI on-chain

Giả sử headline mô phỏng là: “AI on-chain sẽ mở ra lớp ứng dụng mới”. Chưa nên kết luận đúng/sai. Hãy hỏi headline đang ngụ ý điều gì. Có thể là số ứng dụng tăng, số lần sử dụng tăng, phí trả cho protocol tăng, hay chỉ là lượng bài đăng tăng. Mỗi diễn giải cần research question khác.

Ta chọn câu hỏi: “Trong 90 ngày, nhóm ứng dụng AI on-chain được chọn có usage lặp lại tăng so với baseline hay không?”

  • Chủ thể: nhóm ứng dụng được định nghĩa trước.
  • Variable: số lần gọi contract và tỷ lệ address quay lại theo tuần.
  • Proxy: active address chỉ là chỉ báo activity, không là identity.
  • Nguồn: docs, contract records và explorer read-only.
  • Data cut-off: 2026-07-31 ICT.
  • Unknown: bot, multi-address, thay đổi incentive và cách explorer tính.
  • Invalidation: nếu usage chỉ tăng một lần quanh incentive rồi không quay lại, claim về usage lặp lại phải viết lại.

Đây vẫn là thiết kế nghiên cứu mô phỏng. Nó không chứng minh AI on-chain có demand. Điểm quan trọng là câu hỏi đã cho ta biết cần định nghĩa population, mốc so sánh và evidence nào trước khi viết kết luận.

4. Sai lầm, giới hạn và rủi ro

Sai lầm 1: dùng narrative như answer key. Nếu tin “RWA chắc chắn lớn”, bạn sẽ chỉ tìm số liệu hợp ý. Cách sửa là viết trước một evidence có thể ủng hộ và một evidence có thể làm claim yếu đi.

Sai lầm 2: câu hỏi quá rộng. “Protocol này có tốt không?” trộn cơ chế, product, team, tokenomics và risk. Tách thành nhiều câu hỏi nhỏ: flow có hoạt động như docs không, usage có lặp lại không, supply có lịch gì, và điều kiện nào làm thesis sai.

Sai lầm 3: chọn proxy rồi gọi đó là biến đích. Active address không tự là user count; volume không tự là demand; số bài đăng không tự là usage. Proxy có thể hữu ích, nhưng phải ghi phần không đo được.

Sai lầm 4: hindsight. Khi đã thấy kết quả, mọi dấu hiệu đều trông như đã báo trước. Giữ data cut-off và hypothesis trước khi đọc kết quả giúp tách thiết kế nghiên cứu khỏi câu chuyện kể lại.

Giới hạn lớn nhất là chất lượng dữ liệu và định nghĩa. Một câu hỏi rất đẹp vẫn yếu nếu population bị chọn theo cảm tính, nguồn không truy cập lại được hoặc thời gian quá ngắn. Không tìm thấy evidence cũng chưa đồng nghĩa evidence phủ định; có thể câu hỏi chưa có nguồn phù hợp.

Một câu hỏi cũng có thể thất bại vì đơn vị quan sát không nhất quán. Nếu tuần đầu đếm transaction, tuần sau đếm address, xu hướng nhìn thấy chỉ là đổi cách đo. Nếu một protocol đổi contract hoặc incentive giữa kỳ, dữ liệu trước và sau không còn là một nhóm so sánh đơn giản. Ghi các thay đổi này trong research log giúp người đọc biết đâu là kết quả, đâu là giới hạn thiết kế.

5. Checklist viết câu hỏi

  1. Viết narrative trong một câu, rồi khoanh một claim cụ thể.
  2. Chọn chủ thể, variable, proxy và time window; bỏ những phần chưa thể đo.
  3. Viết hypothesis ở dạng có điều kiện, không dùng ngôn ngữ chắc chắn.
  4. Ghi source, data cut-off, unknown và cách tránh confirmation bias.
  5. Viết invalidation trước khi xem dữ liệu: điều gì sẽ làm câu hỏi hoặc hypothesis phải viết lại?

Đứng ngoài khi bạn không xác định được chủ thể, nguồn chỉ là bài đăng không kiểm tra được hoặc proxy bị gọi nhầm là biến đích. Dừng và review khi câu hỏi chứa “tốt”, “xấu”, “bùng nổ”, “chắc chắn” nhưng không có tiêu chí. Câu hỏi chưa hoàn hảo vẫn dùng được nếu phạm vi rõ và có gap log.

Hình 3 — Câu hỏi tốt mở cửa cho cả evidence ủng hộ và evidence phản biện, không chỉ dữ liệu hợp narrative.

6. Practice Bridge 15 phút

Chọn một headline mô phỏng. Đặt đồng hồ 15 phút, mở docs và explorer ở chế độ read-only, rồi điền bảng. Không truy cập ví, không dùng tiền thật và không ghi live price.

Mẫu đối chiếu đã điền

Narrative Research question Evidence Unknown Invalidation
AI on-chain sẽ bùng nổ Ứng dụng nào có usage lặp lại trong 90 ngày? simulated docs/records Identity, retention Usage không lặp lại
Unlock làm liquidity đổi Unlock có trùng thay đổi depth trong venue nào? simulated schedule/depth Recipient/venue Depth không đổi
Protocol có user thật Active address có retention khác 0 không? simulated read-only records Multi-address Retention không vượt baseline

Hình 4 — Ledger giữ narrative trong phạm vi câu hỏi có thể kiểm tra và có điều kiện viết lại.

Kết quả mong đợi là một câu hỏi không cần dùng từ “tốt/xấu”, có thời gian, biến và nguồn. Nếu chưa có source, ghi unknown thay vì bịa. Nếu proxy không đủ gần biến đích, ghi giới hạn. Gap tiếp theo có thể là đọc docs, kiểm tra contract record hoặc tìm baseline; đó là tiến bộ nghiên cứu, không phải thất bại.

Hãy lưu bản câu hỏi đầu tiên cùng ngày viết và người đã review nếu có. Khi sửa câu hỏi, ghi lý do sửa: đổi scope, đổi proxy hay phát hiện nguồn không đủ. Nhật ký nhỏ này giúp bạn phân biệt học được điều mới với việc sửa câu chữ cho hợp một kết quả đã biết.

7. Tổng kết: câu hỏi tốt mở đường cho evidence

a. Năm ý chính

  • Narrative giúp chọn chủ đề; research question mới định nghĩa điều cần kiểm tra.
  • Claim và hypothesis cần scope, variable, source và điều kiện sai.
  • Proxy như active address hữu ích nhưng không tự là identity hay demand.
  • Confirmation bias, câu hỏi quá rộng và hindsight làm research lệch.
  • Data cut-off, gap log và invalidation giữ câu hỏi trung thực.

b. Câu hỏi tự kiểm tra

  • Vì sao “AI on-chain sẽ bùng nổ” chưa phải research question?
  • Active address có thể làm proxy cho điều gì và không đo được điều gì?
  • Evidence nào sẽ làm hypothesis về usage lặp lại phải viết lại?

Gợi ý đáp án

Xem gợi ý câu 1

Narrative thiếu chủ thể, biến, thời gian, source và điều kiện sai. Xem lại mục 1.

Xem gợi ý câu 2

Active address có thể làm proxy cho activity, nhưng không tự đo identity hoặc user count. Xem lại mục 2 và mục 4.

Xem gợi ý câu 3

Usage tăng một lần quanh incentive nhưng không có retention là evidence làm hypothesis yếu đi. Xem lại mục 3 và mục 6.

Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Narrative Câu chuyện hoặc khung diễn giải rộng.
Claim Mệnh đề cần kiểm tra.
Hypothesis Cách trả lời tạm thời có điều kiện.
Scope Ranh giới chủ thể, thời gian và biến.
Variable Điều được quan sát hoặc so sánh.
Proxy Chỉ báo thay thế không hoàn toàn biến đích.
Data cut-off Thời điểm chốt dữ liệu.
Invalidation Điều kiện làm hypothesis không còn đứng vững.

Nguồn tham khảo

Lưu ý giáo dục: Narrative không phải kết luận và research question không phải tín hiệu mua bán. Giữ source, data cut-off, unknown và invalidation trước khi biến evidence thành inference. Bài tiếp theo sẽ kết hợp on-chain, tokenomics và market data trong một khung nghiên cứu.