How LLMs Process Context: A Developer's Perspective

Muốn dùng AI hiệu quả như một kỹ sư senior, bạn phải hiểu LLM "nhìn thấy" gì trong đầu — không phải văn bản, mà là một chuỗi token được cân nhắc trọng số qua cơ chế attention (chú ý).

Token Là Gì — Và Tại Sao Kỹ Sư Cần Quan Tâm?

Khi bạn gõ một câu vào ChatGPT, Claude hay Copilot, câu đó không được xử lý như "chữ" hay "từ". Trước khi vào mô hình, văn bản được cắt nhỏ thành các token — đơn vị nhỏ nhất mà LLM thực sự "đọc" và "viết". Hầu hết các LLM hiện đại (GPT, Claude, Gemini, Llama...) dùng thuật toán tokenization kiểu BPE (Byte Pair Encoding) hoặc các biến thể tương tự (SentencePiece, tiktoken). Ý tưởng cốt lõi: bắt đầu từ ký tự (character) đơn lẻ, sau đó ghép dần các cặp ký tự/subword xuất hiện thường xuyên nhất trong dữ liệu huấn luyện thành một token mới, lặp lại hàng chục nghìn lần cho tới khi có một bộ từ vựng (vocabulary) cố định, thường từ 30.000 đến 200.000 token.

Hệ quả trực tiếp: 1 token không bằng 1 từ. Với tiếng Anh, tỷ lệ trung bình phổ biến là khoảng 1 token ≈ 0.75 từ, hay nói cách khác 100 token ≈ 75 từ tiếng Anh. Các từ thông dụng ("the", "is", "function") thường là 1 token trọn vẹn; từ hiếm, tên riêng, hoặc thuật ngữ kỹ thuật ("tokenization", "PostgreSQL", "kubectl") thường bị chẻ thành 2-4 token nhỏ. Với tiếng Việt, tình hình còn "tốn" hơn: do có dấu và cấu trúc âm tiết khác tiếng Anh, hầu hết tokenizer hiện tại (vốn được huấn luyện chủ yếu trên dữ liệu Latin không dấu) cắt tiếng Việt kém hiệu quả hơn — nhiều từ 1 âm tiết có dấu bị tách thành 2-3 token. Đây là lý do vì sao cùng một nội dung, prompt tiếng Việt thường "nặng" token hơn prompt tiếng Anh tương đương.

Với code thì sao? Token hóa code cũng theo cùng cơ chế nhưng có đặc thù riêng: khoảng trắng thụt lề (indentation), dấu ngoặc, ký tự đặc biệt ({}, =>, ::) đều tốn token. Một dòng code JSON lồng nhau sâu, hoặc một file có indentation 4 space thay vì tab, có thể tốn nhiều token hơn bạn tưởng.

Tại sao điều này quan trọng với kỹ sư?

Chi phí (cost): Hầu hết API tính phí theo token — cả token đầu vào (input) và đầu ra (output), thường với đơn giá khác nhau (output thường đắt hơn input 3-5 lần). Một prompt dán nguyên cả file log 500 dòng có thể tốn hàng nghìn token oan uổng.
Độ trễ (latency): Số token đầu vào ảnh hưởng thời gian xử lý (time-to-first-token), số token đầu ra ảnh hưởng tổng thời gian phản hồi vì mô hình sinh tuần tự từng token một (autoregressive).
Ngân sách context (context budget): Mọi context window đều có giới hạn cứng theo token, không theo ký tự hay từ. Nếu bạn không biết cách đếm/ước lượng token, bạn sẽ liên tục bị bất ngờ khi prompt "dài hơn tưởng tượng" và bị cắt hoặc từ chối.

Mẹo thực dụng: để ước lượng nhanh, dùng công cụ đếm token thực tế (như thư viện tiktoken cho các mô hình họ GPT, hoặc endpoint đếm token của Anthropic) thay vì đếm từ bằng mắt. Với văn bản tiếng Anh thông thường, quy tắc ước lượng nhanh là: số token ≈ số ký tự / 4.

Mẹo: Trước khi dán một đoạn code hoặc log dài vào prompt, chạy thử qua một tokenizer counter (ví dụ trang tiktokenizer.vercel.app hoặc lệnh anthropic.count_tokens trong SDK) để biết chính xác bạn đang "trả" bao nhiêu token, thay vì đoán mò.

Context Window — Bộ Nhớ Làm Việc Của LLM

Context window là tổng số token mà mô hình có thể "nhìn thấy" cùng lúc trong một lượt xử lý — bao gồm system prompt, lịch sử hội thoại, tài liệu đính kèm, code được dán vào, và cả phần output mà mô hình sắp sinh ra. Đây là toàn bộ "tầm nhìn" của mô hình tại thời điểm đó — không hơn, không kém.

Cách hình dung dễ nhất cho kỹ sư: context window giống như RAM (bộ nhớ working memory) của một chương trình, còn dữ liệu huấn luyện (training data) giống như ổ cứng đã ghi chết — kiến thức tổng quát được "nướng" (baked) vào trọng số mô hình, không thể cập nhật theo thời gian thực. Khi bạn đưa thông tin vào context (dán code, đính kèm tài liệu, prompt hệ thống), bạn đang "nạp" dữ liệu vào RAM tạm thời đó cho phiên làm việc hiện tại — nó biến mất hoàn toàn khi phiên kết thúc (trừ khi có cơ chế lưu trữ ngoài như RAG — retrieval-augmented generation, hay memory file).

Một vài con số tham chiếu thực tế (tại thời điểm viết, các con số này thay đổi liên tục nên hãy luôn kiểm tra tài liệu chính thức mới nhất):

Các mô hình GPT-3.5 thế hệ đầu: khoảng 4K-16K token.
GPT-4 / GPT-4 Turbo: 8K đến 128K token.
Claude (Anthropic), các bản Claude 3 trở lên: 200K token trở lên — tương đương khoảng 150.000 từ tiếng Anh, hoặc một cuốn tiểu thuyết cỡ trung.
Gemini 1.5/2.x của Google: một số bản công bố tới 1 triệu-2 triệu token.

Điều quan trọng cần nhớ: context window lớn không có nghĩa là "dùng hết bao nhiêu cũng được". Đây là lỗi phổ biến nhất của kỹ sư mới làm quen agentic engineering — nghĩ rằng cứ nhét toàn bộ codebase vào context vì "window đủ lớn" thì AI sẽ hiểu tốt hơn. Thực tế hoàn toàn ngược lại, sẽ được phân tích ở phần sau.

Ngoài ra, cần phân biệt rõ hai khái niệm hay bị nhầm: context window (giới hạn kỹ thuật của mô hình) và context engineering (nghệ thuật/kỹ thuật chọn lọc, sắp xếp những gì đưa vào context đó một cách có chủ đích). Một senior engineer giỏi context engineering không cố nhét đầy context window — mà cố đưa vào đúng thông tin cần thiết, theo đúng thứ tự, với lượng nhiễu (noise) tối thiểu.

Mẹo: Khi làm việc với các coding agent (Claude Code, Cursor, Copilot Workspace...), luôn theo dõi chỉ số "context used" nếu công cụ hiển thị — coi nó như một thanh RAM, và chủ động dọn dẹp (clear/compact) khi vượt quá 60-70% thay vì đợi đầy mới xử lý.

Attention Hoạt Động Thế Nào — Mô Hình Tư Duy Cho Kỹ Sư

Đây là phần dễ bị hiểu sai nhất. Nhiều người hình dung LLM "đọc" context giống người đọc sách — tuần tự, đều đặn, ghi nhớ như nhau mọi đoạn. Thực tế cơ chế attention (chú ý, nền tảng của kiến trúc Transformer) hoạt động khác hẳn: với mỗi token đang được sinh ra, mô hình tính toán một trọng số liên quan (relevance weight) giữa token đó và MỌI token khác đang có trong context — rồi "chú ý" nhiều hơn vào những token có trọng số cao, ít hơn vào token có trọng số thấp.

Mô hình tư duy đơn giản: hãy tưởng tượng bạn đang đọc lại một cuộc trò chuyện Slack dài 50 tin nhắn để trả lời câu hỏi "vậy deadline cuối cùng là ngày nào?". Bạn không đọc lại từng chữ với mức độ tập trung như nhau — mắt bạn "nhảy" tới những tin nhắn có từ "deadline", "ngày", bỏ qua phần chit-chat không liên quan. Attention làm điều tương tự nhưng ở quy mô toán học: mỗi token tạo ra ba vector — Query (câu hỏi nó đang tìm), Key (nhãn mà mỗi token khác "quảng cáo" mình), Value (nội dung thực sự mang theo). Độ tương đồng giữa Query và Key quyết định trọng số attention, và Value được cộng gộp theo trọng số đó để tạo ra "ngữ cảnh cô đọng" cho bước dự đoán tiếp theo.

Điểm mấu chốt kỹ sư cần khắc cốt ghi tâm: attention là một cơ chế trọng số liên quan (weighted relevance), không phải bộ nhớ lưu trữ hoàn hảo (perfect recall). Mô hình không "nhớ" theo nghĩa con người ghi nhớ một sự kiện — nó tính toán xác suất một token nào đó quan trọng cho việc dự đoán token tiếp theo, dựa trên pattern học được từ hàng tỷ ví dụ huấn luyện. Điều này giải thích tại sao:

Một chi tiết bị "chôn" giữa hàng nghìn dòng code không liên quan có trọng số attention thấp hơn — dễ bị bỏ qua khi trả lời.
Một chỉ dẫn được lặp lại nhiều lần, hoặc đặt ở vị trí "chiến lược" (đầu/cuối), có xu hướng được attend mạnh hơn.
Attention cũng có chi phí tính toán tăng theo bậc hai (quadratic) với độ dài context trong kiến trúc Transformer gốc — đây là một lý do kỹ thuật (bên cạnh lý do chất lượng) khiến context càng dài, xử lý càng chậm và tốn kém, dù các kiến trúc mới (sliding window attention, các cơ chế attention thưa — sparse) đã cải thiện phần nào.

Mẹo: Khi viết system prompt hay CLAUDE.md, đừng viết một đoạn văn dài lê thê hy vọng mô hình "đọc hết và nhớ hết" — hãy dùng heading, bullet, từ khóa in đậm để tạo các "điểm neo" (anchor) có mật độ thông tin cao, giúp attention dễ tính trọng số relevance chính xác hơn.

Vị Trí Trong Context Ảnh Hưởng Chất Lượng — Recency Bias và Vấn Đề "Lost in the Middle"

Một trong những phát hiện nghiên cứu quan trọng nhất cho context engineering thực chiến là hiện tượng "lost in the middle" (lạc mất ở giữa) — được mô tả rõ trong nghiên cứu "Lost in the Middle: How Language Models Use Long Contexts" (Liu et al., 2023). Nhóm nghiên cứu đặt một thông tin quan trọng (câu trả lời đúng cho câu hỏi) ở các vị trí khác nhau trong một context dài, rồi đo độ chính xác khi mô hình phải tìm lại thông tin đó. Kết quả nhất quán qua nhiều mô hình: độ chính xác cao nhất khi thông tin nằm ở đầu hoặc cuối context, và tụt giảm rõ rệt khi thông tin nằm ở giữa — tạo thành đường cong hình chữ U (U-shaped performance curve).

Hai xu hướng liên quan cần phân biệt:

Primacy bias: xu hướng chú ý mạnh vào phần đầu context — thường là nơi đặt system prompt, hướng dẫn tổng quát, định nghĩa vai trò (role).
Recency bias: xu hướng chú ý mạnh vào phần cuối context — gần nhất với vị trí mô hình chuẩn bị sinh token, nên tự nhiên có ảnh hưởng lớn tới output ngay lập tức.

Với kỹ sư, hệ quả thực tiễn cực kỳ cụ thể:

Nếu bạn dán một file config dài 2000 dòng rồi hỏi "dòng nào set timeout database?" — nếu dòng đó nằm ở giữa file, xác suất mô hình bỏ sót hoặc trả lời sai cao hơn đáng kể so với khi nó nằm ở đầu/cuối.
Trong một phiên làm việc dài với coding agent, các chỉ dẫn quan trọng được đưa ra ở tin nhắn đầu tiên (ví dụ trong CLAUDE.md hay system prompt) có nguy cơ bị "loãng" dần khi hội thoại kéo dài hàng chục lượt — trừ khi công cụ có cơ chế ghim (pinning) system prompt riêng biệt khỏi context động.
Few-shot example (ví dụ minh họa) đặt ở giữa một prompt dài thường có ảnh hưởng yếu hơn ví dụ đặt gần cuối, ngay trước câu hỏi thực tế.

Cần lưu ý: đây không phải quy luật tuyệt đối bất biến cho mọi mô hình và mọi phiên bản — các nhà cung cấp mô hình liên tục cải thiện khả năng "needle in a haystack" (tìm kim trong đống rơm) qua các thế hệ mới, và một số kiến trúc/kỹ thuật huấn luyện gần đây giảm đáng kể hiệu ứng này. Nhưng nguyên lý nền tảng — vị trí ảnh hưởng tới trọng số attention — vẫn là bản chất toán học của cơ chế, nên hiệu ứng dù giảm cũng khó biến mất hoàn toàn.

Mẹo: Với bất kỳ thông tin nào bạn coi là "không được phép bỏ sót" (một ràng buộc nghiệp vụ, một con số quan trọng), hãy chủ động đặt nó ở CẢ đầu VÀ cuối prompt — lặp lại có chủ đích để tận dụng cả primacy và recency bias.

Vì Sao Context Dài Làm Giảm Chất Lượng — Và Bạn Có Thể Làm Gì

Ngoài hiệu ứng vị trí, có ba cơ chế riêng biệt khiến context càng dài, chất lượng phản hồi càng có xu hướng đi xuống — kỹ sư cần phân biệt rõ để chọn đúng giải pháp:

1. Dilution (pha loãng tín hiệu). Khi context chứa nhiều thông tin không liên quan, trọng số attention bị "chia sẻ" cho nhiều token hơn — thông tin thực sự quan trọng nhận được tỷ trọng attention nhỏ hơn tương đối. Giống như tìm một câu trong một cuộc họp 3 tiếng thay vì một cuộc gọi 5 phút đã được tóm tắt sẵn.

2. Distraction (nhiễu gây lạc hướng). Nghiên cứu cho thấy nếu context chứa thông tin có vẻ liên quan nhưng thực chất sai lệch hoặc mâu thuẫn (ví dụ hai đoạn code cũ-mới của cùng một hàm còn sót lại trong lịch sử hội thoại), mô hình có xu hướng bị "phân tâm", đôi khi trộn lẫn thông tin cũ và mới, hoặc ưu tiên nhầm thông tin sai vì nó xuất hiện gần vị trí sinh output hơn.

3. Chi phí và độ trễ. Đơn giản nhưng thực tế: context càng dài, chi phí API càng cao, thời gian xử lý càng lâu — với hầu hết coding agent hiện đại (Claude Code, Cursor, Windsurf...), một phiên làm việc dài không được dọn dẹp sẽ ngày càng chậm và tốn kém, chưa kể tăng rủi ro chạm giới hạn context window và bị cắt mất phần đầu hội thoại một cách "thô bạo" (nhiều hệ thống tự động cắt bớt phần cũ nhất khi đầy, không đảm bảo cắt đúng chỗ ít quan trọng).

Giải pháp thực chiến cho từng vấn đề:

Summarization (tóm tắt): định kỳ yêu cầu agent tự tóm tắt lại trạng thái công việc hiện tại (đã làm gì, quyết định gì, còn gì cần làm) thành một đoạn ngắn, rồi bắt đầu phiên mới với bản tóm tắt đó thay vì toàn bộ lịch sử. Nhiều coding agent có lệnh /compact hoặc tương đương cho việc này.
Trimming (cắt tỉa) chủ động: chỉ đính kèm phần file/log thực sự liên quan (ví dụ dùng grep/sed trích đúng đoạn, thay vì cat nguyên file hàng nghìn dòng).
Restructuring (tái cấu trúc): chuyển thông tin dạng văn xuôi lê thê thành bảng, danh sách, hoặc JSON có cấu trúc rõ ràng — giúp cả con người và mô hình quét nhanh hơn, giảm token, tăng "mật độ tín hiệu".
Đặt chỉ dẫn tối quan trọng ở đầu và/hoặc cuối prompt, như đã nói ở phần trước — tận dụng primacy/recency bias thay vì chống lại nó.
Tách phiên làm việc (session splitting): với task lớn, chủ động chia thành nhiều phiên nhỏ theo từng milestone rõ ràng, thay vì cố gắng "một session làm hết" khiến context phình to không kiểm soát.

Mẹo: Coi việc quản lý context như quản lý bộ nhớ trong lập trình hệ thống — bạn không "cấp phát" (allocate) bừa bãi rồi hy vọng garbage collector (rác tự động dọn) lo hết; bạn chủ động dọn dẹp (free) những gì không còn cần, đúng lúc.

Thực Hành: Chẩn Đoán và Cải Thiện Một Prompt Bị "Phình"

Hãy cùng phân tích một prompt thực tế mà nhiều kỹ sư mắc lỗi — dán nguyên toàn bộ ngữ cảnh vì "sợ thiếu thông tin".

Prompt "trước" (bloated — bị phình, phản mẫu):

Đây là toàn bộ file server.js của tôi (2400 dòng, dán nguyên văn bên dưới),
toàn bộ file config.json, toàn bộ log từ production trong 3 ngày qua
(khoảng 8000 dòng), và đây là package.json. Tôi nghĩ có lỗi memory leak
ở đâu đó nhưng không chắc. Bạn xem giúp tôi lỗi ở đâu và sửa luôn nhé.

[... 2400 dòng server.js ...]
[... toàn bộ config.json ...]
[... 8000 dòng log ...]
[... package.json ...]

Vấn đề: thông tin thực sự cần thiết (nếu có, ví dụ đoạn code xử lý event listener không được gỡ bỏ) bị chôn giữa hàng nghìn dòng không liên quan — rơi đúng vào vùng "lost in the middle". Chi phí token cực lớn (ước tính riêng phần dán có thể đã 15.000-20.000 token), độ trễ cao, và mô hình phải "đoán" xem phần nào trong núi dữ liệu này thực sự liên quan tới memory leak — dễ dẫn tới trả lời chung chung hoặc chỉ ra sai chỗ.

Prompt "sau" (đã cải thiện):

Context: Node.js API server, production, đang nghi memory leak (RSS tăng
dần không giảm sau 6-8h chạy, xem heap snapshot đính kèm bên dưới).

Đã thu hẹp nghi vấn về 2 khu vực sau (trích từ server.js):

--- server.js, dòng 340-410 (event listener setup) ---
[dán đúng 70 dòng liên quan]

--- server.js, dòng 812-850 (cache layer, dùng Map không có TTL) ---
[dán đúng 38 dòng liên quan]

Log lỗi liên quan (đã grep theo "OOM|heap|leak", 3 dòng gần nhất):
[dán 3 dòng log đã lọc]

Câu hỏi: Trong 2 đoạn code trên, đoạn nào có khả năng là nguồn leak cao
hơn, và đề xuất fix cụ thể (kèm code diff) cho đoạn đó trước.

Khác biệt: đã trimming (chỉ giữ đoạn liên quan, dùng grep lọc log), restructuring (chia rõ khu vực với heading), và đặt câu hỏi cụ thể ở cuối (tận dụng recency bias). Token giảm từ ~18.000 xuống dưới 1.000 — nhanh hơn, rẻ hơn, và độ chính xác cao hơn hẳn vì mọi token còn lại đều mang tín hiệu liên quan.

Bước thực hành bạn nên tự làm ngay: chọn một prompt bạn từng gửi AI gần đây mà cảm thấy "AI trả lời hơi lạc đề". Đếm số token bằng tokenizer counter. Xác định phần nào trong đó thực sự cần thiết cho câu hỏi. Viết lại theo công thức: Context ngắn gọn → Dữ liệu đã lọc, có cấu trúc → Câu hỏi cụ thể ở cuối. So sánh chất lượng câu trả lời trước/sau.

Mẹo: Tập thói quen tự hỏi trước khi dán bất cứ thứ gì vào prompt: "Nếu một đồng nghiệp senior chỉ có 30 giây để đọc phần này, tôi có nên dán nguyên văn không, hay nên tóm tắt/trích đoạn?" — LLM cũng "đọc" hiệu quả hơn với cùng nguyên tắc đó.

Thực Hành: Kiểm Tra Hiệu Ứng Vị Trí Trong Chính Prompt Của Bạn

Đây là một thí nghiệm bạn có thể tự chạy trong 15 phút để "nhìn tận mắt" hiệu ứng lost-in-the-middle, thay vì chỉ tin vào lý thuyết.

Bước 1 — Chuẩn bị một context dài "giả lập". Lấy khoảng 3000-5000 từ nội dung trung tính, không liên quan (ví dụ ghép nhiều đoạn documentation kỹ thuật ngẫu nhiên, hoặc dùng một file README dài có sẵn). Đây sẽ đóng vai trò "haystack" (đống rơm).

Bước 2 — Chèn một "cây kim" (needle) — một fact cụ thể, dễ kiểm tra. Ví dụ chèn câu:

GHI CHÚ QUAN TRỌNG: Mã cấu hình bí mật cho môi trường staging là XJ-4471-QT.

Bước 3 — Chạy 3 lần thử, mỗi lần đặt câu trên ở một vị trí khác:

Lần 1: đặt ở dòng đầu tiên của context (vị trí ~0%).
Lần 2: đặt ở chính giữa context (vị trí ~50%).
Lần 3: đặt ở dòng cuối cùng, ngay trước câu hỏi (vị trí ~100%).

Với mỗi lần, dùng prompt kết thúc giống nhau:

[... toàn bộ context dài kèm needle ở vị trí tương ứng ...]

Dựa trên toàn bộ nội dung trên, mã cấu hình bí mật cho môi trường staging
là gì? Chỉ trả lời đúng mã, không giải thích thêm.

Bước 4 — Ghi lại kết quả: mô hình có trả lời đúng "XJ-4471-QT" không, có tự tin không (hay kèm câu "tôi không chắc, có thể là..."), thời gian phản hồi có khác biệt không.

Bước 5 — Mở rộng thí nghiệm (tùy chọn nâng cao): thử lại với context dài hơn nữa (10.000+ từ) để xem hiệu ứng có rõ rệt hơn không; thử đặt HAI needle mâu thuẫn nhau (một ở đầu, một ở giữa, nội dung khác nhau) để quan sát distraction — xem mô hình chọn thông tin nào, có báo hiệu mâu thuẫn không hay chỉ chọn bừa một cái.

Kết quả điển hình khi chạy thí nghiệm này trên hầu hết mô hình hiện tại: vị trí đầu và cuối cho độ chính xác gần như tuyệt đối; vị trí giữa có tỷ lệ trả lời sai hoặc trả lời "không tìm thấy thông tin" cao hơn rõ rệt, đặc biệt khi context vượt quá vài nghìn token.

Bài học rút ra để áp dụng ngay vào công việc: khi bạn xây dựng bất kỳ hệ thống nào có context dài (RAG pipeline, coding agent với lịch sử hội thoại dài, tool trả về kết quả search lớn) — đừng coi việc "nhét được nhiều context hơn" là thắng lợi. Hãy chủ động thiết kế thứ tự đưa thông tin vào, ưu tiên đặt thông tin quan trọng nhất gần đầu hoặc gần cuối, và luôn đo lường (evaluate) thực tế thay vì giả định.

Mẹo: Khi xây RAG hoặc bất kỳ pipeline nào tự động ghép nhiều đoạn tài liệu vào context, đừng sắp xếp theo thứ tự "điểm relevance giảm dần đơn giản" — hãy cân nhắc đặt đoạn có điểm cao nhất ở CUỐI (gần câu hỏi nhất) thay vì đầu, vì recency bias trong nhiều mô hình có ảnh hưởng mạnh hơn primacy bias.

Những điểm chính

Token ≠ từ: LLM xử lý văn bản qua tokenization kiểu BPE; tiếng Anh trung bình 1 token ≈ 0.75 từ, tiếng Việt thường tốn token hơn do dấu và cấu trúc âm tiết.
Context window là bộ nhớ làm việc tạm thời, giống RAM chứ không phải kiến thức vĩnh viễn — có giới hạn cứng theo token (từ vài nghìn đến hàng trăm nghìn, tùy mô hình).
Attention là cơ chế trọng số liên quan (weighted relevance), không phải bộ nhớ hoàn hảo — mô hình "chú ý" khác nhau tới từng phần context, không đọc đều như con người.
Hiệu ứng "lost in the middle": thông tin ở đầu và cuối context được nhớ/dùng chính xác hơn thông tin ở giữa — nguyên lý U-shaped curve đã được nghiên cứu xác nhận.
Context dài không đồng nghĩa chất lượng tốt hơn: ba cơ chế suy giảm là dilution (pha loãng), distraction (nhiễu/mâu thuẫn), và chi phí/độ trễ tăng.
Giải pháp thực chiến: summarization định kỳ, trimming chủ động (grep thay vì cat), restructuring dữ liệu thành bảng/list, và cố ý đặt thông tin/chỉ dẫn tối quan trọng ở đầu và cuối prompt.
Luôn thực nghiệm, đừng chỉ tin lý thuyết: tự chạy thí nghiệm needle-in-haystack với chính hệ thống/mô hình bạn đang dùng để biết hiệu ứng vị trí ảnh hưởng ra sao trong trường hợp cụ thể của bạn.