AI cho Backend Engineer: Hướng dẫn thực chiến

Đa số nội dung "AI cho developer" được viết cho người làm chatbot. Bài này dành cho số còn lại — những backend engineer đã vận hành Postgres, Redis và vài service trên production, giờ phải thêm tính năng AI mà không được làm cháy hệ thống đang chạy.

Tin vui: AI cho backend engineer chủ yếu là bài toán dữ liệu và hệ thống, không phải bài toán machine learning. Bạn không cần train model. Bạn chỉ cần đẩy text ra/vào vài API, lưu một ít vector, và để mắt tới chi phí cùng độ trễ — toàn những việc một backend engineer đã làm thành thạo. Bài này vẽ ra bản đồ tổng thể để các bài sau trong series đi sâu vào từng phần.

Vì sao backend engineer nên quan tâm AI ngay bây giờ

Kỹ năng để ship được tính năng AI năm 2026 không phải kỹ năng của ML researcher. Đó là kỹ năng của backend engineer: tích hợp API, thiết kế schema, caching, rate limiting, retry và observability.

Một "tính năng AI" điển hình — tìm kiếm hiểu ngữ nghĩa, trợ lý hỗ trợ dựa trên tài liệu của bạn, tự động gắn tag hay bóc tách thông tin — đều quy về công việc backend quen thuộc:

• Gọi một API bên ngoài và xử lý các tình huống lỗi của nó.
• Lưu và truy vấn một kiểu dữ liệu mới (vector).
• Cache lại các phản hồi đắt đỏ.
• Giới hạn và đặt ngân sách cho mức dùng để một vòng lặp không ngốn $400 qua đêm.
• Trace request để debug được.

Nếu bạn làm chủ backend, bạn đã làm chủ gần hết stack AI. Model chỉ là thêm một dependency nằm sau một lời gọi HTTP.

Bốn khối kiến thức nền tảng

Gần như mọi tính năng AI backend thực tế đều dựng từ bốn khối cơ bản. Nắm được chúng thì các thuật ngữ thời thượng hết đáng sợ.

• Embeddings — một hàm biến text (hoặc ảnh) thành một mảng số thực có độ dài cố định, mã hoá ngữ nghĩa. "Quán cà phê gần đây" và "coffee shop nearby" nằm sát nhau trong không gian vector này dù không chung từ nào.
• Vector search — tìm các bản ghi có embedding gần nhất với embedding của câu truy vấn. Đây là cách "tìm theo nghĩa" thay vì "tìm theo từ khoá".
• RAG (Retrieval-Augmented Generation) — dùng vector search lấy về các đoạn dữ liệu liên quan của chính bạn, rồi dán vào prompt để model trả lời dựa trên dữ kiện của bạn thay vì dữ liệu nó được train.
• Gọi LLM API — gửi một prompt tới large language model và nhận về text (hoặc JSON có cấu trúc). Đây là bước sinh nội dung, và là bước tốn chi phí thật.

Toàn bộ từ vựng chỉ có vậy. Embeddings + vector search cho bạn retrieval theo ngữ nghĩa; thêm một lời gọi LLM lên trên là bạn có RAG.

AI nằm ở đâu trong một backend điển hình

Kiến trúc của bạn không cần đổi gì. Tính năng AI lắp vừa vào luồng request/response bạn đang có. Một request RAG trông như sau:

client ──▶ API service
              │  1. embed câu hỏi của user (embedding/LLM API)
              │  2. vector search trong Postgres (pgvector) → top-k đoạn
              │  3. dựng prompt = system + các đoạn lấy về + câu hỏi
              │  4. gọi LLM API → câu trả lời (có thể stream)
              │  5. log token, chi phí, độ trễ
              ▼
            client

Bước 1 và 4 là gọi API bên ngoài. Bước 2 và 5 là thao tác database thuần. "AI" ở đây là hai lời gọi HTTP bọc quanh một câu SELECT. Mọi thứ bạn biết về timeout, connection pool, idempotency vẫn đúng — và còn quan trọng hơn, vì API model bên ngoài chậm và hay lỗi hơn service của bạn.

Stack tối giản: Postgres + pgvector + một LLM API

Bạn không cần một nền tảng mới để bắt đầu. Stack nhỏ nhất ship được tính năng thật là chính cái database bạn đang chạy, cộng thêm một extension và một API key.

Thêm pgvector vào Postgres là bạn có thể lưu embedding ngay cạnh dữ liệu quan hệ và truy vấn bằng SQL:

CREATE EXTENSION IF NOT EXISTS vector;

ALTER TABLE documents ADD COLUMN embedding vector(1536);

-- Lấy 5 đoạn gần nhất với embedding của câu truy vấn (cosine distance)
SELECT id, content
FROM documents
ORDER BY embedding <=> $1   -- $1 = embedding của câu hỏi
LIMIT 5;

Toán tử <=> chính là cosine distance. Một cột, một toán tử, và Postgres sẵn có của bạn giờ là một vector database. Việc sinh embedding chỉ là một lời gọi API từ tầng service — đúng cái pattern tích hợp bên thứ ba mà bạn vẫn đang duy trì.

Vì sao bạn chưa cần vector DB riêng vội

Rất dễ bị cám dỗ dùng Pinecone, Qdrant hay Weaviate ngay từ ngày đầu. Với đa số sản phẩm, đó là quá sớm. Một vector database riêng là thêm một service phải deploy, bảo mật, backup và giữ đồng bộ với nguồn dữ liệu gốc.

pgvector gom mọi thứ về một chỗ: vector nằm trong cùng transaction với bản ghi của bạn, nên không có vấn đề dual-write và không lệch dữ liệu. Ở mức vài triệu vector với index hợp lý, nó đủ nhanh — và khi nào thật sự vượt ngưỡng, bạn sẽ biết chính xác vì sao. Cứ bắt đầu với pgvector; nâng cấp sau khi các con số buộc bạn phải làm vậy. (Một bài sau trong series sẽ benchmark điểm giao này.)

Chi phí và độ trễ: những con số phải theo dõi từ ngày đầu

Đây là chỗ bản năng backend phát huy. LLM call tính tiền theo token và chậm hơn truy vấn database cả một bậc. Nếu không đo, cả hoá đơn lẫn p95 latency đều sẽ làm bạn bất ngờ.

Theo dõi những chỉ số này từ lần deploy đầu tiên:

| Chỉ số | Vì sao quan trọng | Mức độ tham khảo | | --- | --- | --- | | Token mỗi request (vào + ra) | Token là tiền; đây là đơn giá | vài trăm tới vài nghìn | | Chi phí mỗi request | token × đơn giá; nhân với traffic | từ phần nhỏ cent tới vài cent | | Độ trễ embedding | Chạy trên mọi câu tìm kiếm | hàng chục ms | | Độ trễ sinh LLM (p95) | Chiếm phần lớn tổng thời gian phản hồi | hàng trăm ms tới vài giây | | Tỷ lệ cache hit | Mỗi hit là một request không tốn tiền | nhắm càng cao càng tốt |

Kết luận thực tế suy ra ngay từ đó: cache mạnh tay (prompt giống hệt và gần giống), stream câu trả lời dài để user thấy nội dung sớm hơn, dùng model nhỏ/rẻ cho tác vụ đơn giản, và đặt hạn mức ngân sách cứng cùng rate limit theo user trước mọi LLM call — đúng kỷ luật bạn vẫn áp cho mọi dependency bên ngoài đắt đỏ, như trong bài Redis Lua Script & SETNX: Rate Limiting & cảnh báo quota hiệu năng cao cho API. Và vì mỗi lời gọi đều phát ra token, chi phí, độ trễ, các sự kiện đó rất hợp với kiểu pipeline phân tích mô tả trong Phân tích usage & billing API real-time với ClickHouse và Redis Streams.

Series này sẽ đi qua những gì

Đây là bài trụ (pillar) của một series thực chiến về AI cho backend engineer — field notes, không phải lý thuyết. Mỗi bài sắp tới lấy một khối nền tảng phía trên và đi sâu với code thật, số liệu thật và các cạm bẫy production, chia thành bốn nhánh:

• RAG & semantic search — pgvector vs vector DB riêng, chunking, hybrid search (từ khoá + vector), reranking và đánh giá.
• LLM trong backend — gọi API model gọn gàng, streaming, structured output, kiểm soát chi phí, caching, retry và observability.
• AI trên dữ liệu & hạ tầng thật — embeddings trong Postgres, tìm địa điểm theo ngữ nghĩa, khử trùng địa chỉ, và phân tích usage LLM bằng ClickHouse.
• Đưa AI lên production — self-host hay dùng API, deploy bằng Docker, phòng prompt injection, guardrails và tối ưu latency.

Một số bài nối thẳng với các field notes đã có — semantic search mở rộng phần keyword trong PostgreSQL Full-Text Search: Tối ưu autocomplete địa chỉ tiếng Việt, và tìm địa điểm theo ngữ nghĩa áp dụng nó vào stack geocoding đằng sau GoGoDuk: Vietnam Map API cho Developer.

Hãy bookmark bài này như tấm bản đồ. Đích đến vẫn giống mọi hệ thống backend khác bạn từng xây: một thứ đúng đắn, quan sát được, và đủ rẻ để chạy ở quy mô lớn.