No-code AI: chọn món hay chọn bếp?

No-code AI không chỉ là giao diện kéo-thả. Với builder, câu hỏi thật là lớp nào được che đi, lớp nào vẫn phải tự kiểm soát.

Bạn sẽ giao production AI cho một màn hình kéo-thả chứ?

Câu hỏi nghe hơi khiêu khích, nhưng mấy tuần nay mình thấy nó xuất hiện dưới nhiều dạng: một team muốn dựng RAG nội bộ thật nhanh, một tech lead bị hỏi “sao không dùng no-code cho đỡ tốn dev?”, một founder nhìn danh sách open-source no-code AI platform rồi tưởng cuối cùng cũng có cách né orchestration code.

Mình không chê no-code. Ngược lại, lớp công cụ mới này đáng chú ý vì nó đang biến việc dựng LLM app, RAG system và AI agent thành trải nghiệm gần giống gọi set menu: có khai vị là UI, phần chính là workflow, tráng miệng là deploy nhanh. Nhưng nếu bạn là builder, đừng chỉ nhìn menu. Hãy hỏi: bếp phía sau đang vận hành kiểu gì?

Luận điểm của mình: no-code AI không thay thế kiến trúc; nó chỉ chuyển quyết định kiến trúc sang một giao diện dễ bấm hơn. Ai quên điều này sẽ prototype rất nhanh, rồi debug rất lâu.

Sơ đồ tóm tắt ý chính của bài viết.

Tranh luận thật: kéo-thả hay viết code?

Phe ủng hộ no-code có lý. Những platform open-source như AnythingLLM, AutoAgent và nhóm công cụ tương tự đang làm một việc có ích: gom retrieval, agent flow, document chat, model provider, tool integration vào một UI dễ dùng hơn. Với team nhỏ, chuyện này giảm đáng kể thời gian đi từ ý tưởng đến demo.

Phe code-first cũng không sai. Khi app bắt đầu có dữ liệu nhạy cảm, user thật, quyền truy cập phức tạp, cost cần kiểm soát, SLA cần giữ, bạn sẽ muốn biết từng bước trong pipeline đang làm gì.

Dịch sang tiếng người: no-code giống gọi món theo set. Nhanh, tiện, ít phải nghĩ lúc đói. Nhưng nếu khách dị ứng, ngân sách bếp thay đổi, hoặc món chính ra chậm, bạn vẫn cần biết món đó nấu bằng gì.

Với builder, câu hỏi không phải “no-code có đủ tốt không?”. Câu hỏi đúng hơn là:

No-code đang che đi lớp nào, và team mình có chịu được việc không kiểm soát lớp đó không?

Lớp 1: Canvas đẹp không đồng nghĩa workflow chắc

Visual canvas — giao diện kéo-thả để nối các bước xử lý — là phần dễ gây thiện cảm nhất. Bạn thấy node “Load document”, “Retrieve”, “Call model”, “Send answer”, rồi não tự thưởng dopamine: hệ thống nhìn có vẻ rõ ràng.

Nhưng workflow AI không chỉ là đường nối giữa các hộp. Nó còn có retry, timeout, idempotency, versioning prompt, kiểm soát quyền gọi tool, log đầu vào/đầu ra, và cách xử lý khi model trả lời nửa vời.

Ví dụ cụ thể: team bạn dựng agent xử lý ticket hỗ trợ khách hàng. Canvas có 5 bước:

1. đọc ticket,
2. tìm policy liên quan,
3. gọi model viết câu trả lời,
4. kiểm tra giọng văn,
5. gửi draft cho nhân viên duyệt.

Demo chạy ổn. Nhưng production hỏi thêm:

• Nếu retrieval không tìm được policy thì agent có được đoán không?
• Nếu tool gọi CRM timeout thì retry mấy lần?
• Nếu prompt được sửa, các ticket cũ có tái chạy được không?
• Nếu user hỏi về hoàn tiền, agent có cần escalated approval không?

Một canvas tốt phải cho bạn trả lời các câu đó. Nếu chỉ cho nối node và bấm Run, nó hợp làm prototype hơn là làm nền production.

Lớp 2: Retrieval mới là phần chính của RAG

RAG — retrieval augmented generation, tức cho model tra tài liệu trước khi trả lời — thường bị no-code hóa thành vài nút: upload file, chọn embedding, bật chat. Tiện thật. Nhưng với builder, retrieval là phần chính, không phải món phụ.

Ở đây có ba biến số phải nhìn:

| Biến số | Câu hỏi cần hỏi | Nếu bỏ qua thì sao |
|---|---|---|
| Chunking | Tài liệu được cắt theo đoạn, heading, hay token? | Model lấy nhầm mảnh, trả lời lệch ngữ cảnh |
| Ranking | Kết quả tìm kiếm có được xếp hạng lại không? | Câu đúng nằm đâu đó nhưng không vào context |
| Storage | Vector index chạy memory, disk, hay hybrid? | Latency và chi phí vỡ khi dữ liệu tăng |

Vụ Qdrant phản biện benchmark của Elastic là lời nhắc khá đáng tiền: cùng một bài toán vector search, chỉ cần cấu hình retrieval khác — như two-stage retrieval, tức lấy ứng viên trước rồi chấm lại kỹ hơn, và async disk scoring, tức chấm điểm trên disk theo cách không chặn luồng xử lý — kết quả vận hành có thể khác rất nhiều. Qdrant nói họ đạt throughput cao hơn, latency thấp hơn và dùng ít compute hơn trong cấu hình họ cho là đúng workload. Mình không xem đây là “ai thắng ai thua”, mà là tín hiệu: benchmark retrieval mà sai cấu hình thì giống chấm món chính khi bếp chưa bật lửa.

Vậy khi chọn no-code RAG platform, đừng chỉ hỏi “có hỗ trợ vector database nào?”. Hỏi tiếp:

• Có cho chỉnh chunking không?
• Có hỗ trợ reranking không? Reranking là bước xếp hạng lại kết quả tìm kiếm trước khi đưa vào model.
• Có log query, retrieved chunks và final answer cạnh nhau không?
• Có cách đánh giá recall theo bộ câu hỏi thật của team không?

Nếu không có những chỗ bám này, bạn đang mua tốc độ demo bằng nợ debug.

Lớp 3: Agent cần sandbox, không chỉ cần tool

Agent — hệ thống để model tự gọi tool và thực hiện nhiều bước — là phần dễ bị phấn khích nhất trong nhóm no-code AI. AutoAgent cho thấy hướng thú vị: mô tả mục tiêu bằng natural language, hệ thống dựng tool, agent và multi-agent workflow. AnythingLLM cũng đi theo hướng cho người dùng dựng Agent Flows mà không phải script nhiều.

Nhưng agent càng dễ dựng, rủi ro càng cần được đóng khung.

Nhìn sang llm-coding-agent của Simon Willison, điểm đáng học không phải là “coding agent tự viết code”. Điểm đáng học là bộ tool rất cụ thể: đọc file, sửa file bằng old_string phải khớp chính xác, chạy command có timeout, trả diff để kiểm tra. Đây là thiết kế có ranh giới.

Datasette Apps cũng gợi ý một lớp bảo vệ khác: custom HTML app chạy trong sandbox iframe, bị hạn chế cookie, localStorage và request ra ngoài. Với AI agent, tư duy sandbox — vùng chạy bị giới hạn quyền — quan trọng không kém model.

Hình dung thế này: bạn cho agent quyền đọc tài liệu nội bộ, gọi CRM, sửa file cấu hình và gửi email. Nếu mọi tool đều nằm chung một giỏ quyền, agent không khác gì người được đưa cả thực đơn lẫn chìa khóa kho. Builder nên tách quyền theo việc:

• tool chỉ đọc,
• tool ghi nhưng cần approval,
• tool nguy hiểm phải chạy trong môi trường tạm,
• tool gọi external API phải có allowlist.

No-code agent platform đáng dùng là platform giúp bạn nhìn và khóa các quyền này, không phải platform làm agent trông thông minh trong demo 5 phút.

Lớp 4: Inference không biến mất chỉ vì có UI

AWS SageMaker AI thêm UI cho generative AI inference recommendations là một tín hiệu khác: ngay cả cloud lớn cũng đang đưa phần tối ưu inference vào giao diện low-code/no-code. Inference ở đây là giai đoạn chạy model để trả lời request; nó ảnh hưởng trực tiếp đến latency, throughput và chi phí.

Điểm hay của UI kiểu này là giúp team không chuyên infra vẫn so sánh cấu hình, workload profile và deploy endpoint từ khuyến nghị có dữ liệu. Nhưng builder vẫn phải hiểu tradeoff:

• Latency thấp có thể tốn instance đắt hơn.
• Throughput cao có thể cần batching, nhưng batching làm request đơn lẻ chờ lâu hơn.
• Model lớn hơn chưa chắc tốt hơn nếu bottleneck nằm ở retrieval hoặc tool latency.

Vì vậy, no-code ở lớp inference nên được xem như bảng gợi ý gọi món, không phải quyết định thay bạn khẩu vị, ngân sách và giờ cao điểm.

Khi nào chọn no-code, khi nào quay về code?

Mình sẽ dùng khung 4 câu hỏi này trước khi chọn platform:

1. Việc này đang ở giai đoạn nào?

Nếu bạn cần prototype để kiểm tra nhu cầu, no-code open-source rất hợp. Dựng nhanh, self-host được, đủ để đưa cho 5-10 người dùng nội bộ phản hồi.

Nếu bạn đã có traffic thật, dữ liệu nhạy cảm, audit requirement, hãy yêu cầu export config, version workflow, log đầy đủ và khả năng viết extension bằng code.

2. Lớp nào là lợi thế riêng của team?

Nếu lợi thế của bạn nằm ở dữ liệu, retrieval và policy xử lý, đừng để platform khóa cứng các phần đó. Nếu lợi thế chỉ là UX và quy trình nghiệp vụ, dùng no-code cho orchestration ban đầu có thể tiết kiệm sức.

3. Có đường thoát không?

Một platform tốt nên cho bạn:

• self-host,
• backup dữ liệu,
• xuất workflow hoặc config,
• thay model provider,
• gắn observability bên ngoài,
• viết custom tool khi UI không đủ.

Không có đường thoát thì prototype hôm nay có thể thành bẫy vận hành quý sau.

4. Ai chịu trách nhiệm khi agent làm sai?

Nếu câu trả lời là “chắc platform xử lý”, bạn chưa sẵn sàng. Builder cần định nghĩa owner cho prompt, retrieval, tool permission, monitoring và incident response. UI không ký tên chịu trách nhiệm thay team.

Nếu là mình, mình sẽ chọn theo “menu kỹ thuật”

Với team Việt Nam quy mô nhỏ đến vừa, mình sẽ không chọn tool ồn ào nhất. Mình sẽ chọn theo menu kỹ thuật ba phần:

Khai vị: no-code canvas để dựng demo nhanh, validate luồng nghiệp vụ, cho stakeholder chạm được.

Phần chính: các lớp có thể kiểm soát bằng code hoặc config rõ ràng: retrieval, tool permission, workflow versioning, logging.

Tráng miệng: UI deploy hoặc inference recommendation nếu nó giúp giảm vòng lặp benchmark, nhưng không thay cho kiểm thử workload thật.

Sau bài này, điều mình muốn bạn nghĩ khác là: no-code AI không phải đối thủ của engineering. Nó là một lớp giao diện mới đặt lên engineering. Chọn đúng thì team đi nhanh hơn. Chọn nhầm thì bạn chỉ đang bọc một hệ thống khó debug trong lớp áo dễ bấm.

Kết lại gọn: gọi món nhanh thì vui, nhưng production vẫn cần người biết món nào dễ cháy nồi.

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