AI cũng cần "ý kiến thứ hai

AI cũng cần "ý kiến thứ hai

GitHub Copilot CLI giờ dùng nhiều model cùng lúc. vLLM và Ollama cũng đã sẵn sàng. Đây không phải trend — đây là cách làm đúng.

AI cũng cần "ý kiến thứ hai"

GitHub vừa thừa nhận điều mà nhiều người ngại nói

GitHub Copilot CLI vừa cập nhật một tính năng tưởng nhỏ mà không nhỏ: kết hợp nhiều model family để cho bạn một "second opinion" — ý kiến thứ hai. Ngay cả GitHub — với hàng triệu developer dùng Copilot mỗi ngày — cũng không tin một model duy nhất đủ sức đưa ra câu trả lời đáng tin cậy.

Mấu chốt ở đây: nếu họ còn cần cơ chế "hỏi thêm người khác", thì team 5-10 người của bạn càng nên nghĩ lại cách mình đang dùng AI.

Khoan — chuyện phức tạp hơn "thêm model" nhiều

Thử nghĩ thế này: bạn xây nhà. Bạn thuê một ông thợ giỏi — ông ấy vừa đổ móng, vừa đi dây điện, vừa sơn tường. Được không? Được — nhưng nhà sẽ ở mức "tạm ổn." Muốn chắc chắn, bạn cần thợ chuyên cho từng phần.

AI inference stack bây giờ cũng vậy. Không phải cứ chọn một tool rồi dùng cho tất cả.

Như mình đã chia sẻ trong các bài trước về vLLM và Ollama — hai công cụ này giải quyết hai bài toán hoàn toàn khác nhau:

Tóm gọn lại: mỗi tầng trong workflow cần một công cụ riêng. Dùng Ollama để serve production là đang bắt thợ mộc đi đổ bê tông.

Hai kịch bản thật mà team bạn có thể gặp

Kịch bản 1 — Startup fintech, team 6 dev:

Giả sử team bạn đang build chatbot hỗ trợ khách hàng. Lúc dev, mỗi người chạy Ollama trên laptop với Llama hoặc Mistral để test prompt locally — không tốn API cost, không cần internet ổn định. Khi merge code, CI/CD pipeline gọi vLLM server nội bộ để chạy evaluation trên model production. Và khi viết code, Copilot CLI cho bạn suggestion từ nhiều model family — bạn thấy hai gợi ý khác nhau, chọn cái nào make sense hơn.

Kết quả: prompt được test trên nhiều model trước khi lên production. Bug do hallucination giảm đáng kể vì đã có lớp cross-check tự nhiên trong workflow.

Kịch bản 2 — Agency làm outsource cho enterprise:

Mỗi dự án mỗi yêu cầu model khác nhau. Khách A muốn dùng model nội bộ vì compliance. Khách B chấp nhận cloud API nhưng cần response nhanh. Với vLLM, bạn serve nhiều model trên cùng một infrastructure, chuyển đổi linh hoạt. Ollama thì dùng cho team presales — demo nhanh cho khách xem mà không cần dựng cả hệ thống.

Nếu chỉ chọn một tool duy nhất, bạn buộc phải đánh đổi: hoặc linh hoạt mà chậm, hoặc nhanh mà cứng nhắc.

Cái bẫy "chọn model một lần, tin cả đời"

Có một thói quen nguy hiểm mà mình thấy không ít team mắc phải: chọn một model, setup xong, rồi không bao giờ đánh giá lại.

Hình dung thế này: bạn thuê thợ sơn nhà năm ngoái — giá tốt, làm đẹp. Năm nay cần sơn lại, bạn gọi lại ông ấy mà không hỏi giá mới, không tìm hiểu loại sơn mới. Bạn hài lòng vì "lần trước ổn mà" — cho đến khi sơn bong tróc sau ba tháng vì dùng sai loại cho thời tiết năm nay.

Với AI model cũng vậy. Cả vLLM lẫn Ollama đều release liên tục — mỗi bản cải thiện throughput, hỗ trợ thêm model architecture mới, tối ưu memory usage. Nếu bạn đang chạy version từ 6 tháng trước mà không review, bạn có thể đang bỏ lỡ cải thiện đáng kể mà chỉ cần một lần upgrade là có.

Quy tắc mình tự đặt cho team: review inference stack mỗi quý — giống như bạn review dependency trong package.json vậy. Không glamorous, nhưng tránh được những cú sốc không đáng.

Thử ngay chiều nay — 2 tiếng là đủ

Bạn chưa cần kiến trúc phức tạp để bắt đầu cross-check bằng nhiều model. Thử setup đơn giản này:

Bước 1 — Cài Ollama (nếu chưa có) và pull 2 model khác nhau:

ollama pull llama3
ollama pull mistral

Bước 2 — Chạy cùng một prompt trên cả hai, so sánh output:

ollama run llama3 "Giải thích API rate limiting trong 3 câu"
ollama run mistral "Giải thích API rate limiting trong 3 câu"

Bước 3 — Ghi lại sự khác biệt. Bạn sẽ ngạc nhiên khi thấy cùng một câu hỏi mà hai model đưa ra cách giải thích và mức độ chi tiết khác nhau rõ rệt.

Bước 4 — Nếu team đang dùng GitHub Copilot CLI, bật multi-model và để ý xem suggestion có đa dạng hơn không.

Mục tiêu không phải "dùng nhiều model cho oai" — mà là xây thói quen cross-check. Giống code review: không ai merge code mà không có người review, thì tại sao lại tin AI output mà không có ý kiến thứ hai?

Khi nào thì MỘT model là đủ?

Công bằng mà nói: không phải lúc nào cũng cần dàn nhạc giao hưởng.

Side project một mình? Ollama với một model tốt là quá đủ. Summarize tài liệu nội bộ, không ảnh hưởng đến khách hàng? Một model ổn định đã đáp ứng. Đừng over-engineer.

Multi-model approach tỏa sáng khi:

Xây nhà thì cần cả chục thợ chuyên môn, nhưng treo bức tranh lên tường thì chỉ cần một cái đinh — quan trọng là bạn biết mình đang làm gì.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo