8 bài viết được gắn thẻ "Technical"

RAG (Retrieval-Augmented Generation) đã đi được một chặng đường dài từ những ngày đầu "nhét context vào prompt". Năm 2025-2026 chứng kiến sự bùng nổ của các hệ thống RAG chuyên biệt hóa theo từng domain — nơi retrieval không còn là bài toán "tìm document giống nhất", mà là bài toán "tìm thông tin hữu ích nhất cho một ngữ cảnh chuyên môn cụ thể".

Bài viết này khảo sát 22 paper mới nhất về domain-aware RAG trên 8 lĩnh vực, rút ra những insight chung và bài học thực tiễn cho ai đang xây dựng hệ thống RAG trong doanh nghiệp.

Cuối tháng 5/2026, một con số gây chấn động làng công nghệ bị rò rỉ: Anthropic đang trả 1,25 tỷ USD mỗi tháng cho SpaceX — chỉ riêng tiền compute. Nhưng câu chuyện lớn hơn không nằm ở Anthropic. Nó nằm ở hàng nghìn doanh nghiệp đang lặng lẽ đốt ngân sách vào AI token mỗi tháng — mà không ai dám chắc khoản đầu tư ấy có thực sự sinh lời.

Bài viết này không bàn về cuộc đua của các ông lớn. Nó bàn về bạn: một doanh nghiệp đang trả tiền token hàng tháng, và câu hỏi khó chịu nhất — liệu số tiền đó có đáng không?

Có một câu hỏi tôi gặp ngày càng nhiều trong các cuộc trò chuyện với đồng nghiệp: "AI code giỏi thế rồi, kiến trúc sư phần mềm còn cần không?"

Câu trả lời ngắn: Cần. Hơn bao giờ hết.

Nhưng câu trả lời dài thì thú vị hơn nhiều.

Tôi nghĩ Agent Skills đang ở đúng một điểm rất thú vị của lịch sử AI ứng dụng. Chúng vừa giống một cái nạng tạm thời, vừa giống một lớp hạ tầng lâu dài. Tạm thời, vì model ngày càng giỏi hơn và sẽ hấp thụ dần nhiều thứ hôm nay còn phải viết ra ngoài. Lâu dài, vì có một nhóm tri thức vận hành mà tôi không tin nên bị nhét hết vào base model.

Nếu đang dựng một stack RAG hoặc semantic search, câu hỏi thực tế không còn là “có chạy được embedding không”, mà là: nếu embedding và rerank là workload chuyên biệt, cái nào cho profile performance hợp lý hơn để đưa vào production. Hai cái tên thường được đưa lên bàn cân là vLLM và Hugging Face Text Embeddings Inference (TEI).

Điểm quan trọng là cả hai đều đã hỗ trợ embedding và rerank. Nhưng nếu đọc kỹ docs chính thức, có thể thấy chúng không tối ưu cho cùng một mục tiêu. TEI được định vị theo hướng service chuyên cho embedding/rerank, còn vLLM được định vị theo hướng inference runtime hợp nhất. Chính khác biệt đó là thứ đáng dùng để ra quyết định kiến trúc.

Đây không phải một bài so benchmark giữa Claude và Codex. Đây là một bài học vận hành. Sau khi bị khóa 2 tài khoản Claude — một Pro và một Max X20 — vì dùng OpenClaw để delegate task cho Claude Code, tôi phải đọc lại chính sách, điều khoản và cách mỗi bên đang productize coding agent của họ. Kết luận rút ra khá rõ: Claude vẫn rất mạnh, nhưng không còn là lựa chọn tôi muốn đặt sau một lớp harness. Nếu muốn làm việc theo kiểu agent runtime, tôi tin OpenClaw + Codex/OpenCode thực dụng hơn ở thời điểm hiện tại.

Nhìn bề ngoài, Claude Code, Model Spec, OpenAI-style API, S3 tooling, tranh luận về coding agent hay các repo mới nổi trên GitHub có vẻ là những mẩu tin rời rạc. Nhưng nếu nhìn ở góc chiến lược sản phẩm, chúng đang ghép thành một bức tranh rõ ràng hơn nhiều.

Context cache (còn gọi là prefix cache hoặc KV cache) là kỹ thuật tối ưu quan trọng trong các LLM API hiện đại, giúp giảm latency và cost khi xử lý các request có phần context lặp lại. Bài viết này phân tích sâu kiến trúc cache của 4 model LLM hàng đầu (Claude, Gemini, GPT, Qwen3.5), so sánh implicit vs explicit cache, và đặc biệt tập trung vào trade-off giữa TTFT (Time-To-First-Token) và TTLT (Time-To-Last-Token) - vấn đề then chốt trong optimization thực tế.