Bài 7: Context window — giới hạn input của LLM

Sau bài này, bạn cần trả lời được:

• Context window là gì, gồm những gì, đo bằng đơn vị nào.
• Vì sao LLM có giới hạn context — gốc rễ từ self-attention $O(n^2)$ và KV cache.
• Context size của các model phổ biến 2024-2026 và sự khác biệt giữa "có context lớn" và "thực sự dùng được context lớn".
• Lost-in-the-middle, prompt caching, và các chiến lược quản lý context khi build app.
• Khi nào nên dùng long context, khi nào nên dùng RAG.

Đây là bài cuối của Module 1 (Foundation LLM). Sáu bài trước đã giải quyết phần "đọc text → token → vector"; bài này khép lại với câu hỏi "model đọc được bao nhiêu cùng lúc?".

Context window (hay context length) là số token tối đa LLM xử lý trong một lượt forward pass. Cửa sổ này bao gồm cả input và output:

total_tokens = input_tokens + output_tokens   ≤   context_window

Ví dụ Claude 3.5 Sonnet có context window 200K token. Nếu gửi prompt 195K token, model chỉ còn 5K token để sinh output. Vượt giới hạn → API raise lỗi, hoặc input bị truncate trước khi vào model (tùy provider).

Khái niệm dễ nhầm:

• Context window = giới hạn cứng của model (do training và architecture).
• max_tokens = tham số API giới hạn output trong một call, do user đặt.
• Conversation history = phần input bạn gửi mỗi lượt — nếu chat dài, history này phình lên và "ăn" dần context window.

Model không có khái niệm "nhớ giữa các call". Mỗi lần gọi API là một forward pass độc lập. "Trí nhớ" của chatbot thực ra là phần history được client gửi kèm mỗi lượt — và history đó cũng nằm trong context window.

Bài 2-5 đã đi sâu vào tokenizer. Ở đây chỉ nhấn lại: context window đo bằng token, không phải từ hay ký tự.

Quy đổi rất thô cho tiếng Anh (tokenizer cl100k của GPT-3.5/4):

• 1 token ≈ 4 ký tự ≈ 0.75 từ.
• 100 token ≈ 75 từ ≈ 1 đoạn ngắn.
• 1 K token ≈ 750 từ ≈ 1.5 trang văn bản.
• 200 K token ≈ 150 K từ ≈ 300-500 trang sách.

Quy đổi này lệch nhiều giữa các tokenizer, ngôn ngữ và loại văn bản (code thường nén tốt hơn prose). Khi tính cost hoặc kiểm tra giới hạn, luôn đo bằng tokenizer của chính model đó (tiktoken cho GPT, transformers tokenizer cho Llama / Mistral) — không dự đoán bằng số ký tự.

Bảng tham chiếu nhanh (số liệu công bố chính thức của vendor tại thời điểm release):

Model                       Context window       Năm
─────────────────────────────────────────────────────────────
GPT-3.5 turbo (original)     4K                    2022
GPT-3.5 turbo 16K            16K                   2023
GPT-4 (original)             8K                    2023
GPT-4 32K                    32K                   2023
GPT-4 Turbo                  128K                  2023
GPT-4o                       128K                  2024
GPT-4.1                      1M                    2025
o1, o3                       128K - 200K           2024-2025
Claude 2                     100K                  2023
Claude 3 (Haiku/Sonnet/Opus) 200K                  2024
Claude 3.5 Sonnet            200K                  2024
Claude Opus 4 / 4.1          200K standard, 1M     2025-2026
Gemini 1.5 Pro               1M (2M experimental)  2024
Gemini 2.5 Pro               1M - 2M               2025
Llama 2                      4K                    2023
Llama 3                      8K                    2024
Llama 3.1 / 3.2 / 3.3        128K                  2024
Mistral Large                32K - 128K            2024
Qwen2.5                      128K                  2024

Xu hướng quan sát được: trong 3 năm từ GPT-3.5 4K đến GPT-4.1 1M, context window tăng 250×. Tuy nhiên kích thước công bố không trực tiếp phản ánh chất lượng — xem phần "Lost in the middle" phía dưới.

Transformer (Vaswani et al. 2017) dùng self-attention: mỗi token attend tới tất cả các token còn lại trong chuỗi. Với chuỗi dài $n$ token, attention matrix có kích thước $n \times n$ — tức $n^2$ cặp tương tác.

Cụ thể, attention chuẩn tính:

\[ \text{Attention}(Q, K, V) = \text{softmax}\!\left(\frac{Q K^\top}{\sqrt{d_k}}\right) V \]

Trong đó $Q, K, V \in \mathbb{R}^{n \times d}$. Tích $Q K^\top$ ra ma trận $n \times n$ — compute và memory đều $O(n^2 \cdot d)$ cho mỗi attention head, mỗi layer.

Con số thô: với $n = 100{,}000$ token, một attention layer cần $10^{10} = 10$ tỷ phép tính cho riêng phần $QK^\top$. Model 32-64 layer → hàng trăm tỷ phép tính chỉ cho attention. Đây là rào cản chính khiến context window không tăng vô hạn.

Bài 8 (Trước Transformer) và Module 2 sẽ giải thích chi tiết self-attention; ở đây chỉ cần nhớ: gốc rễ giới hạn nằm ở đặc tính bậc hai của attention.

Khi sinh text từng token một (autoregressive decoding), model lưu lại $K$ và $V$ của các token đã xử lý để không phải tính lại — gọi là KV cache. Kích thước cache cho 1 sequence:

\[ \text{KV size} = 2 \times n \times L \times h \times d_{\text{head}} \times \text{bytes} \]

Trong đó $n$ là độ dài chuỗi, $L$ số layer, $h$ số head, $d_{\text{head}}$ chiều mỗi head, hệ số 2 là cho K và V.

Ví dụ Llama 3 70B (80 layer, 64 head, $d_{\text{head}} = 128$) ở float16 với $n = 128{,}000$:

2 × 128_000 × 80 × 64 × 128 × 2 bytes
≈ 335 GB

Một con số quá lớn so với VRAM một GPU H100 (80 GB). Để giảm, các kỹ thuật như Grouped Query Attention (GQA, Llama 3 dùng 8 KV head thay vì 64 → giảm 8×), Multi-Query Attention (MQA), KV cache quantization (INT8, INT4) được áp dụng. Module 2 sẽ đi vào chi tiết.

Bài học thực tế: context dài không chỉ tốn compute mà còn ép VRAM tăng tuyến tính theo $n$. Vì vậy với cùng GPU, batch size phải giảm khi tăng context.

Self-attention thuần không có khái niệm vị trí — hoán đổi token không thay đổi output. Để model biết thứ tự, mỗi token được cộng / nhân thêm một position embedding.

Position embedding cổ điển:

• Sinusoidal (Vaswani 2017, GPT-2 original): hàm sin/cos với tần số cố định. Lý thuyết có thể extrapolate, thực tế kém với độ dài vượt training.
• Learned absolute (BERT, GPT-3): mỗi vị trí có một vector học được. Bị giới hạn cứng ở độ dài tối đa khi train — không có embedding cho vị trí ngoài range.

Hai cách trên đều khiến model gặp giới hạn cứng. Một model train với context 2K không thể chỉ "thử cho ăn" 100K token — embedding cho vị trí 50K không tồn tại hoặc behavior bất thường.

Đây là lý do GPT-3 (2K), Llama 2 (4K), BERT (512) đều có context nhỏ; chỉ khi position embedding hiện đại ra đời thì context mới mở rộng được.

Ba phương pháp position embedding được dùng phổ biến trong model 2023-2026:

RoPE (Rotary Position Embedding, Su et al. 2021 — arXiv:2104.09864): mã hóa vị trí bằng phép quay vector $Q$ và $K$ trong không gian phức. Ưu điểm: tính chất relative — attention giữa token $i$ và $j$ chỉ phụ thuộc $i - j$. Llama 1/2/3, Mistral, Qwen đều dùng RoPE.

ALiBi (Attention with Linear Biases, Press et al. 2022 — arXiv:2108.12409): không cộng embedding mà thêm linear bias vào attention score, bias âm tỉ lệ với khoảng cách. Tăng dần độ phạt khi token cách xa. MPT, BLOOM dùng ALiBi.

YaRN (Yet another RoPE extensioN, Peng et al. 2023 — arXiv:2309.00071): kỹ thuật interpolate frequency của RoPE để model train trên context ngắn có thể chạy ở context dài hơn (4× - 32×) với fine-tune ngắn. Llama 3.1 dùng YaRN-style scaling từ 8K lên 128K.

Một bảng so sánh ngắn:

Phương pháp     Tính chất relative    Extrapolate ngoài train length
─────────────────────────────────────────────────────────────────────
Sinusoidal      Có (xấp xỉ)           Kém
Learned abs.    Không                 Không thể
RoPE            Có                    Khá (~ 1.5×), tốt với YaRN scaling
ALiBi           Có                    Tốt (linear bias áp dụng tùy ý)
YaRN            Có (mở rộng của RoPE) Rất tốt (đến hàng chục lần)

Một hướng khác là thay đổi chính cấu trúc attention để bỏ chi phí $O(n^2)$:

Sliding window attention (Mistral 7B): mỗi token chỉ attend tới $w$ token gần nhất ($w = 4096$ với Mistral). Compute trở thành $O(n \cdot w)$ — linear. Token xa được "kéo theo" qua các layer (mỗi layer cho phép thông tin di chuyển $w$ vị trí). Đánh đổi: thông tin xa truyền chậm.

Sparse attention (Longformer, BigBird, Sparse Transformer của OpenAI): thay vì full $n \times n$, chỉ tính một subset có cấu trúc (block sparse, dilated, random). Đạt context vài chục K trên hardware vừa phải.

Mamba (Gu & Dao 2023 — arXiv:2312.00752) và RWKV (Peng et al. 2023 — arXiv:2305.13048): không dùng attention, dùng state-space model / RNN-style với complexity $O(n)$. Mamba-2 (2024) và các hybrid Mamba-Transformer (Jamba, AI21 2024) đạt context hàng triệu token với chi phí tuyến tính.

Trade-off chung: bỏ full attention → tiết kiệm compute, đôi khi mất chất lượng ở task cần liên kết xa. Hiện tại model frontier vẫn ưu tiên full attention (kèm RoPE/YaRN scaling và GQA), nhưng hướng Mamba đang được nghiên cứu mạnh.

Có context window 200K hay 1M không có nghĩa là model dùng đều thông tin trên toàn bộ phạm vi đó. Hai test phổ biến để đo:

Needle in a Haystack (Kamradt 2023): nhét một câu fact ngẫu nhiên vào giữa văn bản dài (vd: "The best thing to do in San Francisco is eat a sandwich and sit in Dolores Park"). Sau đó hỏi model về fact đó. Đo accuracy theo vị trí của "needle" và độ dài "haystack".

Lost in the Middle (Liu et al. 2023 — arXiv:2307.03172): model thường recall thông tin ở đầu và cuối context tốt; thông tin nằm ở giữa bị nhớ kém hơn rõ rệt. Hiện tượng đúng với GPT-3.5, GPT-4, Claude, kể cả khi context không gần giới hạn.

Hệ quả khi build app:

• Đặt thông tin quan trọng nhất ở đầu hoặc cuối prompt, không phải giữa.
• Đừng giả định "nhồi cả 200K vào là xong" — kiểm tra bằng eval trên use case thật.
• Khi cho retrieval, sắp xếp passage theo relevance (top relevance ở đầu hoặc cuối).

Các model 2024-2026 (Claude 3, GPT-4o, Gemini 1.5) đã giảm đáng kể vấn đề này nhưng chưa loại bỏ hoàn toàn.

Đa số API tính phí theo số token input và output, tỉ lệ tuyến tính. Một số tier 2025-2026 (tham khảo, có thể thay đổi):

Model                  Input ($/1M token)   Output ($/1M token)
──────────────────────────────────────────────────────────────────
GPT-4o                       2.50                10.00
GPT-4.1                      2.00                 8.00
Claude 3.5 Sonnet            3.00                15.00
Claude Opus 4                15.00               75.00
Gemini 1.5 Pro               1.25 (≤128K)        5.00
Gemini 1.5 Pro (>128K)       2.50               10.00

Với Claude Opus 4 ở giá $15/1M input, một call dùng full 200K context tốn $3 chỉ riêng phần input. Nếu app gọi 1000 lần/ngày như vậy → $3000/ngày. Long context không phải "miễn phí mở rộng" — chi phí tuyến tính tích lũy nhanh.

Bài 34 (Module 4) sẽ đi sâu hơn về tối ưu chi phí. Ở đây chỉ cần ý thức: context dài là một quyết định ngân sách, không chỉ kỹ thuật.

Anthropic (08/2024) và OpenAI (10/2024) đều ra mắt prompt caching: phần đầu prompt cố định (system prompt, tài liệu reference) được cache phía server. Lần gọi sau, phần cached chỉ tính phí ở mức rất thấp.

Số liệu công bố:

• Anthropic: cache write tốn 1.25× giá input thường; cache read chỉ 0.1× → tiết kiệm 90% cho phần cached. TTL mặc định 5 phút, gia hạn mỗi lần truy cập.
• OpenAI: cache read 50% giá input thường, áp dụng tự động cho prompt ≥ 1024 token.

Use case phù hợp:

• System prompt dài (vài K - vài chục K token) lặp lại nhiều lượt chat.
• Tài liệu reference (PDF, codebase) cần hỏi nhiều câu khác nhau.
• Few-shot example cố định.

Cách dùng với Anthropic Messages API (Python):

import anthropic

client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-opus-4",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": LONG_SYSTEM_PROMPT,          # nhiều K token
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[{"role": "user", "content": "Câu hỏi cụ thể của user"}],
)
print(resp.usage)
# cache_creation_input_tokens, cache_read_input_tokens, input_tokens, output_tokens

Quy tắc: phần cache phải nằm trước phần thay đổi; chỉ cần thay đổi 1 token ở giữa phần cache, toàn bộ cache phía sau đó sẽ bị invalidate.

Khi history hoặc tài liệu dài hơn context window, có bốn chiến lược chính:

• Truncation: cắt bỏ phần xa (cũ nhất hoặc đầu prompt). Đơn giản nhất, nhưng mất thông tin.
• Summarization: tóm tắt phần cũ bằng model phụ rồi thay thế bằng bản tóm tắt. Giữ ý chính, mất chi tiết. Có thể tóm tắt nhiều cấp (sliding summary).
• Sliding window history: chỉ giữ $N$ message gần nhất + system prompt cố định. Dùng cho chatbot dài.
• RAG (Retrieval-Augmented Generation): index tài liệu vào vector DB, mỗi câu hỏi chỉ retrieve top-K passage liên quan và inject vào prompt. Cho phép "kiến thức" lớn hơn context window nhiều lần. Module 5-6 (B35+) sẽ đi sâu.

Pseudo-code truncation đầu cũ:

def truncate_messages(messages, max_tokens, count_tokens):
    total = sum(count_tokens(m["content"]) for m in messages)
    while total > max_tokens and len(messages) > 1:
        # bỏ message cũ nhất (giữ system prompt ở index 0)
        removed = messages.pop(1)
        total -= count_tokens(removed["content"])
    return messages

Lựa chọn chiến lược phụ thuộc nature của data: chat thường dùng sliding window + summarization; Q&A trên tài liệu lớn dùng RAG; coding agent thường truncation theo file-level relevance.

Model multimodal (GPT-4o, Claude 3, Gemini, Llama 3.2 Vision) biểu diễn ảnh, audio, video dưới dạng token tương đương — nằm chung context window với text.

Số token cho ảnh ở các provider (tham khảo policy 2024-2026):

• OpenAI GPT-4o: ảnh được chia thành tile 512×512. 1 tile = 170 token (high detail) + 85 token base. Ảnh 1024×1024 = 4 tile + base ≈ 765 token.
• Anthropic Claude 3: công thức xấp xỉ tokens ≈ (width × height) / 750. Ảnh 1024×1024 ≈ 1400 token.
• Gemini 1.5: 258 token cho 1 ảnh ≤ 384×384; ảnh lớn hơn chia tile, mỗi tile thêm 258 token.

Video còn tốn nhiều hơn vì là chuỗi frame. Gemini 1.5 tính 263 token/giây video (sampling 1 frame/s). Một video 10 phút ≈ 158K token — đã chiếm phần lớn context window 200K.

Hệ quả: app vision/video không thể đối xử với input như "free" — phải estimate token trước, có thể downsample resolution hoặc giảm frame rate để fit ngân sách.

Output cũng nằm trong context window. Mặt khác, mỗi provider có giới hạn riêng cho output:

• Claude 3.5 Sonnet / Opus 4: max_tokens phải đặt rõ, tối đa 8192 token (hoặc 64K với header beta).
• GPT-4o, GPT-4.1: max_completion_tokens mặc định không hạn (chỉ giới hạn bởi context window).
• Gemini 1.5: max_output_tokens 8192.

Đặt max_tokens hợp lý có hai lợi ích:

• Tránh bill phình to do model "lảm nhảm" không dừng.
• Đảm bảo input_tokens + max_tokens ≤ context_window — provider sẽ raise lỗi context_length_exceeded nếu vượt.

Ví dụ Anthropic Python SDK:

resp = client.messages.create(
    model="claude-opus-4",
    max_tokens=1024,           # bắt buộc, không có default an toàn
    messages=[{"role": "user", "content": "Viết tóm tắt 200 từ về context window."}],
)

Lưu ý max_tokens trong Anthropic SDK luôn bắt buộc, khác với một số provider khác có default.

Bài 2 đã nói: dấu tiếng Việt (UTF-8 multi-byte) khiến tokenizer general nén tiếng Việt kém hơn tiếng Anh. Hệ quả lên context window:

• cl100k (GPT-3.5/4): 100 từ tiếng Việt ≈ 150-200 token. Cùng văn bản tiếng Anh ≈ 130 token.
• o200k (GPT-4o): cải thiện, 100 từ tiếng Việt ≈ 120-150 token nhờ vocab lớn hơn và token tiếng Việt phổ biến được gộp.
• Llama 3.1 (128k vocab): tương đương o200k với tiếng Việt.
• Gemma (256k vocab): tốt nhất, nhiều token tiếng Việt phổ biến được gộp.

Khi tính ngân sách context cho ứng dụng tiếng Việt, nhân số từ với hệ số ≈ 1.5-2 (tùy tokenizer) để ước lượng token. Một bài viết 5000 từ tiếng Việt có thể tốn 7500-10000 token với cl100k.

Ước lượng token cho một đoạn text bằng tiktoken:

import tiktoken

def count_tokens(text: str, model: str = "gpt-4o") -> int:
    enc = tiktoken.encoding_for_model(model)
    return len(enc.encode(text))

text = open("article.txt", encoding="utf-8").read()
print("cl100k :", count_tokens(text, "gpt-4"))
print("o200k  :", count_tokens(text, "gpt-4o"))

So sánh context limit GPT-4o vs Claude vs Llama 3:

from transformers import AutoTokenizer
import tiktoken

text = open("article.txt", encoding="utf-8").read()

n_gpt4o  = len(tiktoken.encoding_for_model("gpt-4o").encode(text))
n_llama  = len(AutoTokenizer.from_pretrained("meta-llama/Meta-Llama-3.1-8B")
               .encode(text, add_special_tokens=False))

CONTEXT_LIMITS = {
    "GPT-4o":      128_000,
    "GPT-4.1":     1_000_000,
    "Claude Opus 4": 200_000,
    "Llama 3.1":   128_000,
}

for name, limit in CONTEXT_LIMITS.items():
    n = n_gpt4o if "GPT" in name else (n_llama if "Llama" in name else n_gpt4o)
    print(f"{name:20s} {n:>8d} / {limit:>9d}   fit = {n <= limit}")

Truncation đơn giản giữ phần cuối (phù hợp chat history):

def truncate_tail(text: str, max_tokens: int, model: str = "gpt-4o") -> str:
    enc = tiktoken.encoding_for_model(model)
    ids = enc.encode(text)
    if len(ids) <= max_tokens:
        return text
    return enc.decode(ids[-max_tokens:])

short = truncate_tail(long_text, 8000)

Sliding window cho list message:

def sliding_window(messages: list[dict], n_keep: int = 10) -> list[dict]:
    system = [m for m in messages if m["role"] == "system"]
    others = [m for m in messages if m["role"] != "system"]
    return system + others[-n_keep:]

Khi dữ liệu vượt vài chục K token, hai hướng chính:

Long context: nhồi toàn bộ tài liệu vào prompt, để model tự "đọc".

• Ưu: 1 call, hạ tầng đơn giản, không cần vector DB.
• Nhược: cost cao tuyến tính, lost-in-the-middle, không scale khi dữ liệu > 1M token.
• Phù hợp: tài liệu 1 lần (phân tích 1 hợp đồng, đọc 1 codebase nhỏ).

RAG: index dữ liệu, mỗi truy vấn chỉ retrieve top-K passage liên quan.

• Ưu: cost thấp (mỗi call chỉ gửi K passage), scale lên hàng triệu document, retrieval có thể audit.
• Nhược: cần infrastructure (embedding model, vector DB), retrieval không hoàn hảo (recall hữu hạn), thêm latency.
• Phù hợp: knowledge base dùng nhiều lần, dữ liệu cập nhật thường xuyên.

Một benchmark từ Anthropic (2024) cho thấy RAG thường outperform long context khi corpus > 200K token, kể cả với model context 1M. Lý do: retrieval đưa thông tin liên quan lên đầu, giảm noise.

Module 8 (Fine-tuning & RAG, B47+) sẽ so sánh chi tiết hơn kèm benchmark. Trong thực tế, nhiều hệ thống kết hợp cả hai: RAG để lọc, rồi đưa kết quả vào long context.

1. Lấy một paper PDF khoảng 5000 từ (chuyển sang .txt). Dùng tiktoken đếm số token với cl100k và o200k. Paper có fit GPT-4o (128K) không? Claude 3 (200K)? Llama 3.1 (128K)?
2. So sánh số token cho cùng một đoạn 500 từ ở: tiếng Anh, tiếng Việt có dấu, tiếng Việt không dấu. Dùng cl100k và o200k. Vẽ bảng so sánh.
3. Implement sliding_window(messages, n_keep) giữ N message gần nhất + system prompt. Test với một danh sách 30 message giả lập, kiểm tra system luôn ở đầu, các message còn lại đúng N.
4. Tính chi phí gọi GPT-4o với input 1K, 10K, 100K token (output cố định 1K). Lập bảng. Tính tỉ số tăng so với 1K.
5. (Tùy chọn) Dùng Anthropic SDK với cache_control trên một system prompt 5K token. Gọi 5 lượt, in usage.cache_creation_input_tokens và cache_read_input_tokens mỗi lượt. Quan sát sự khác biệt giữa lượt 1 và các lượt sau.

Điểm chính của bài 7:

• Context window = số token tối đa (input + output) trong một forward pass. Đo bằng token, không phải từ.
• Giới hạn đến từ self-attention $O(n^2)$, KV cache linear theo $n$, và position embedding cần extrapolate.
• Kỹ thuật mở rộng: RoPE, ALiBi, YaRN, sliding window, sparse attention, Mamba / RWKV (non-attention).
• Context lớn không bằng nhớ tốt — lost-in-the-middle vẫn xảy ra. Đặt thông tin quan trọng ở đầu / cuối.
• Chi phí linear theo token. Prompt caching giảm 50-90% cho phần lặp lại.
• Chiến lược quản lý: truncation, summarization, sliding window, RAG.
• Multimodal token chia chung context. Output cũng count, đặt max_tokens hợp lý.

Tổng kết Module 1 — Foundation LLM (Bài 1-7):

• Bài 1: LLM là gì — định nghĩa, generative vs discriminative, đặc trưng model 2024-2026.
• Bài 2: Tokenization — vì sao chia token, các phương pháp word / char / subword.
• Bài 3: BPE — thuật toán merge cặp byte tần suất cao, tiktoken cl100k/o200k.
• Bài 4: SentencePiece & WordPiece — alternative cho BPE, dùng trong BERT / Llama / Gemma.
• Bài 5: Vocabulary & token ID — bảng ánh xạ, embedding table, LM head, tied weight.
• Bài 6: Text Embedding — ý nghĩa hình học của vector, similarity, training objective.
• Bài 7: Context window — giới hạn input/output, kỹ thuật mở rộng, chiến lược quản lý.

Sau Module 1, bạn nắm được cách LLM "đọc" text (token → ID → embedding) và bao nhiêu text model có thể đọc cùng lúc. Module 2 (Bài 8+) đi vào architecture nội tại của Transformer — self-attention, multi-head, feed-forward, layer norm — giải thích vì sao một mô hình lại tạo ra hành vi như chúng ta thấy.