LangSmith BYOC mở rộng sang AWS, Azure và Google Cloud
LangSmith BYOC nay hỗ trợ AWS ở mức sẵn sàng chính thức, còn Azure và Google Cloud ở beta. Mô hình này giữ trace, prompt, dataset và secret workspace trong tài khoản cloud của khách hàng, trong khi LangChain vận hành nền tảng.
Một agent có thể đọc ticket, tra cứu chính sách, gọi CRM rồi tạo bản nháp phản hồi. Nhưng khi cần trả lời câu hỏi “agent đã dùng prompt nào, gọi công cụ gì và vì sao ra kết quả này?”, trace không còn là log phụ.
LangChain vừa mở rộng LangSmith Bring Your Own Cloud (BYOC) sang cả ba nền tảng đám mây lớn:
AWS: đã sẵn sàng sử dụng chính thức (GA);
Azure: beta;
Google Cloud: beta.
Điểm chính của BYOC là các dữ liệu nhạy cảm phục vụ vận hành agent có thể nằm trong tài khoản cloud và region do doanh nghiệp lựa chọn, trong khi LangChain vẫn vận hành phần nền tảng LangSmith.
BYOC tách LangSmith thành hai phần
Theo LangChain, BYOC chia LangSmith thành control plane và data plane.
Control plane do LangChain vận hành, gồm xác thực, cấu hình tổ chức và workspace, metadata thanh toán, API key đã băm và tài sản giao diện tĩnh.
Data plane nằm trong hạ tầng cloud của khách hàng, chứa trace, prompt, dataset, evaluation, experiment, agent deployment và workspace secret.
Cách tách này hướng đến các đội cần giữ dữ liệu vận hành agent trong ranh giới hạ tầng của mình, nhưng không muốn tự vận hành toàn bộ LangSmith theo mô hình self-hosted.
Với một quy trình hỗ trợ khách hàng, trace có thể phản ánh chuỗi xử lý như:
> Ticket mới → AI đọc nội dung → agent tra cứu chính sách → tạo bản nháp phản hồi → người duyệt → gửi email
Nếu ticket, prompt hoặc thông tin cấu hình có dữ liệu nhạy cảm, vị trí lưu trữ trace và dữ liệu liên quan là điểm cần đội IT, bảo mật và compliance xem xét.
Có thể tách data plane theo môi trường, khu vực hoặc đơn vị
Một tổ chức có thể sử dụng nhiều data plane, với từng data plane đặt trong tài khoản và region riêng. LangChain nêu các trường hợp tách theo:
môi trường production và staging;
region;
đơn vị kinh doanh.
Ví dụ, một đội có thể dùng data plane riêng cho môi trường thử nghiệm và một data plane khác cho hệ thống đang vận hành. Mỗi đội sẽ có trace nằm trong tài khoản cloud mà đội đó sở hữu.
Với người xây workflow bằng n8n, Zapier, Make hay Power Automate, BYOC không thay thế các công cụ tự động hóa này. Nó đáng chú ý khi workflow đã có lớp agent hoặc bước AI cần quan sát, đánh giá và quản lý prompt kỹ hơn.
Khi nào cần agent thay vì workflow cố định?
Không phải mọi quy trình đều cần agent.
Workflow cố định thường phù hợp khi các bước đã rõ ràng: nhận form rồi tạo contact CRM, nhận hóa đơn rồi chuyển dữ liệu sang hệ thống kế toán, hoặc đồng bộ dữ liệu giữa hai ứng dụng.
Agent phù hợp hơn khi cần xử lý ngữ cảnh và lựa chọn bước tiếp theo, chẳng hạn:
đọc email tự do để xác định loại yêu cầu;
quyết định cần gọi công cụ nào để tra cứu thông tin;
tổng hợp nhiều nguồn trước khi tạo đề xuất;
xử lý yêu cầu không theo biểu mẫu cố định.
Với các hành động có tác động lớn như gửi email quan trọng, thanh toán, xóa dữ liệu hoặc thay đổi trạng thái khách hàng, đội vận hành nên cân nhắc đặt bước phê duyệt của con người. Một cách triển khai thận trọng là để agent trả về đề xuất có cấu trúc, còn workflow cố định thực hiện hành động sau khi đã kiểm tra.
Ví dụ, một nút AI có thể được yêu cầu chỉ tạo kết quả dạng JSON:
text
Bạn là trợ lý phân loại yêu cầu vận hành.
Yêu cầu khách hàng:
<noidungticket>
Thông tin tra cứu:
<dulieunoibo>
Hãy chỉ trả về JSON hợp lệ:
{
"category": "<nhomyeucau>",
"priority": "<low|medium|high>",
"recommendedaction": "<draftreply|createcase|requesthumanreview>",
"reason": "<lydongangon>",
"draftreply": "<bannhaptraloineuphuhop>"
}
Không tự thực hiện hành động bên ngoài.
Workflow phía sau có thể kiểm tra kết quả này và đưa các trường hợp cần xem xét vào hàng chờ phê duyệt.
BYOC giảm phần việc của mô hình self-hosted
LangChain cho biết các đội có yêu cầu nghiêm ngặt về ranh giới dữ liệu trước đây thường phải tự triển khai LangSmith. Cách đó giữ dữ liệu trong hạ tầng của doanh nghiệp, nhưng đòi hỏi vận hành các dịch vụ có trạng thái, cơ sở dữ liệu và migration schema.
Với BYOC, LangChain cho biết họ đảm nhiệm orchestration, scaling, cập nhật nền tảng, schema và runtime dependency cho data plane trong môi trường của khách hàng.
Điều này đặc biệt liên quan khi đội đang vận hành agent ở nhiều môi trường. Thay vì tự phối hợp nâng cấp thành phần thực thi hoặc triển khai Helm riêng ở từng nơi, BYOC hướng tới việc để LangChain vận hành các cập nhật nền tảng.
Khác biệt theo từng nền tảng cloud
BYOC sử dụng các thành phần hạ tầng riêng của từng cloud.
AWS
Trên AWS, data plane chạy trong VPC hiện có của khách hàng. Cơ sở dữ liệu có thể đặt trong các subnet do khách hàng lựa chọn.
Đội bảo mật có thể gắn security group riêng cho từng application role, để phù hợp với chính sách kiểm tra lưu lượng vào và ra đang áp dụng.
Azure
Trên Azure, data plane chạy trong một virtual network chuyên dụng với private AKS API endpoint. LangChain triển khai Istio và KEDA bằng Helm cho định tuyến ingress và autoscaling theo sự kiện; telemetry hệ thống được đưa tới Azure Monitor.
LangChain cho biết hỗ trợ LangSmith Sandboxes trên Azure sẽ được bổ sung trong tương lai.
Google Cloud
Khi ra mắt, data plane trên Google Cloud có thể chạy ở bất kỳ region nào. Tuy nhiên, chúng được quản lý từ control plane của LangSmith tại Mỹ.
Đây là chi tiết cần được kiểm tra trong yêu cầu về compliance, đặc biệt nếu doanh nghiệp có quy định cụ thể về vị trí quản trị hoặc luồng dữ liệu.
Di chuyển từ LangSmith self-hosted
LangChain cung cấp một công cụ migration mã nguồn mở để chuyển các tài nguyên workspace từ LangSmith self-hosted. Theo bài viết, công cụ này đọc dữ liệu từ hệ thống hiện có mà không làm hệ thống đó ngừng hoạt động trong lúc chuyển.
Các tài nguyên được nêu gồm:
users và roles;
datasets;
experiments;
prompts;
cấu hình annotation queue;
automation rules;
dashboards;
Fleet resources.
Trace, runs và feedback được chuyển ở bước riêng bằng công cụ nội bộ do LangChain thực hiện. Hiện tại, bài viết chỉ nêu khả năng chuyển trace trên AWS.
Những điểm cần kiểm tra trước khi dùng
Bài viết công bố không nêu giá BYOC. Trước khi triển khai, đội kỹ thuật nên làm rõ mô hình trách nhiệm chung, quyền truy cập và yêu cầu mạng với LangChain.
Một số câu hỏi nên đưa vào checklist:
[ ] Trace, prompt hoặc dataset có cần nằm trong tài khoản cloud của doanh nghiệp không?
[ ] Có cần tách production, staging, region hoặc đơn vị kinh doanh thành các data plane khác nhau không?
[ ] Ai quản lý IAM, network policy, quyền xem trace và vòng đời secret?
[ ] Có yêu cầu compliance liên quan đến region hoặc control plane không?
[ ] Nếu đang self-hosted, những dữ liệu nào chuyển được bằng migration tool và những dữ liệu nào cần LangChain hỗ trợ?
[ ] Các hành động rủi ro trong workflow đã có bước kiểm tra phù hợp chưa?
LangChain cũng cho biết LLM Gateway trong data plane hỗ trợ sẵn 11 nhà cung cấp model, cùng các endpoint tương thích OpenAI hoặc Anthropic. Điều này đem lại thêm lựa chọn model, nhưng việc đánh giá chính sách dữ liệu, giới hạn sử dụng và điều kiện vận hành của từng nhà cung cấp vẫn là phần doanh nghiệp cần tự thực hiện.
BYOC phù hợp nhất khi agent đã tham gia thực sự vào quy trình vận hành và dữ liệu như trace, prompt hay evaluation cần được quản lý trong hạ tầng cloud của chính doanh nghiệp. Với workflow đơn giản, cố định, giữ thiết kế gọn nhẹ vẫn thường là lựa chọn tốt hơn.