Thật sự rất thú vị, nhưng nghĩ đến việc bên làm ra thứ này lại không phải chính phủ hay một công ty như Google thì cũng hơi đáng sợ
Mình cảm nhận được rằng dữ liệu trên đời này thật sự đang tràn ngập
"CTO của Amplitude, Wade Chambers, đã thử cho một số đồng nghiệp xem công cụ AI do nội bộ tự xây dựng"
Bài viết trên Naver được nhắc trong tài liệu thuyết trình của Ha Yong-ho cũng vậy, có vẻ như để AI Transformation lan tỏa tốt trên toàn công ty thì cần có quyết tâm hoặc mục tiêu từ cấp C-level.
Nếu là lãnh đạo tổ chức có sự hiểu biết sâu sắc và tầm nhìn thì còn ổn, nhưng với những lãnh đạo sa vào kiểu coi AI là vạn năng chỉ để chơi trò con số vì chi phí??? Tôi như nghe thấy tiếng con người đang bị vắt kiệt hu hu
Ồ, tôi cũng đã thử làm một thứ tương tự!
Đó là dịch vụ dùng AI để dịch và tóm tắt các bài đăng trên Hacker News sang tiếng Hàn rồi gửi lên kênh Telegram.
Nếu biết đã có cái này thì tôi đã không làm rồi.. haha, tôi đăng ký rồi!
Nghe nói áp dụng AI thì năng suất tăng gấp đôi, rồi công việc cũng bị giao gấp đôi luôn.. lương vẫn y nguyên, thậm chí còn không hỗ trợ cả chi phí AI nữa..
Cảm ơn bạn đã chia sẻ ý kiến rất hay. Như bạn đã nói, đây không phù hợp cho trường hợp sử dụng RDB và có thể xem là phù hợp cho vị trí của công cụ tìm kiếm (Elasticsearch), vector DB (Pinecone). Nội bộ chúng tôi cũng đang tận dụng Lucene, đã được kiểm chứng trong thời gian dài, để hỗ trợ các chức năng như lập chỉ mục, sắp xếp, tổng hợp, v.v. Cảm ơn bạn :)
Như bạn nói, tôi nghĩ đây sẽ là một giải pháp có thể được sử dụng theo kiểu "serverless" thực sự trong các trường hợp cụ thể, thay vì một cơ sở dữ liệu dùng cho mọi mục đích.
Không ngờ sẽ có người trả lời bằng tiếng Hàn! (Mình đã viết hơi châm biếm quá...)
Ban đầu tôi cũng nghĩ đây là một ý tưởng đột phá. Thật ra, điểm yếu lớn nhất của các cơ sở dữ liệu serverless nằm ở chỗ vẫn có server thực chạy ẩn dưới bề mặt, nơi mà vấn đề này không hề rõ ràng. Vì vậy khi lưu lượng truy cập tăng đột ngột, có thể xảy ra tình trạng treo cho đến khi server đó được cấp phát (khoảng 5 phút). Vì thế các DB serverless của các nhà cung cấp cloud hiện có (như AWS, v.v.) rất khó dùng ở cấp độ production.
Tôi từng nghĩ 'thử xem sao?', nhưng lo ngại khi nghĩ rằng nếu phải tự triển khai lại các logic nhị phân cho các chức năng như index, sort đã có sẵn ở MySQL, PostgreSQL, thì việc xây dựng lại một dự án cơ sở dữ liệu mã nguồn mở đáng tin cậy trên Lambda sẽ khó đến mức nào.
Vì đây là sản phẩm các bạn đang tự làm, nên tôi mong chờ nó sẽ tiến bộ nhiều hơn nữa~!
Cảm ơn ý kiến đóng góp rất hay của bạn. Điểm bạn nêu về việc cần có state để giảm độ trễ đã chạm đúng vào trade-off cốt lõi của kiến trúc của chúng tôi.
Trước tiên, về độ trễ truy vấn, trong benchmark của chúng tôi p99 (99th percentile) vào khoảng 130–210ms. Có lẽ phần bạn nói về chênh lệch 100 lần là đang dựa trên trường hợp xấu nhất trong bài viết là "có thể mất vài giây khi cold start". Như bạn đã chỉ ra, phần này chắc chắn là một nhược điểm của kiến trúc chúng tôi, và như đã đề cập trong bài, trong môi trường production nó xảy ra ở mức dưới 0,01% (P99.99). Ngoài ra, hầu hết các truy vấn còn lại đều được thiết kế để sử dụng bộ nhớ và ổ đĩa cục bộ của từng Lambda làm cache nhằm duy trì hiệu năng ổn định.
Do đó, như bạn đã nói, kiến trúc này có thể không phù hợp cho các hệ thống giao dịch tài chính siêu thấp trễ, nơi mọi truy vấn đều phải đảm bảo dưới 10ms. Tuy nhiên, đối với phần lớn ứng dụng tìm kiếm và gợi ý dựa trên AI, mức độ trễ 100–200ms theo chuẩn P99 đã là hiệu năng rất tốt, và tôi cho rằng lợi thế giảm hơn 90% chi phí hạ tầng và gánh nặng vận hành là lớn hơn nhiều.
Một lần nữa, xin cảm ơn những ý kiến sâu sắc của bạn.
Thật sự rất thú vị, nhưng nghĩ đến việc bên làm ra thứ này lại không phải chính phủ hay một công ty như Google thì cũng hơi đáng sợ
Mình cảm nhận được rằng dữ liệu trên đời này thật sự đang tràn ngập
Vì mã nguồn đã được công khai nên có lẽ bạn xem thử sẽ hữu ích đấy!
"CTO của Amplitude, Wade Chambers, đã thử cho một số đồng nghiệp xem công cụ AI do nội bộ tự xây dựng"
Bài viết trên Naver được nhắc trong tài liệu thuyết trình của Ha Yong-ho cũng vậy, có vẻ như để AI Transformation lan tỏa tốt trên toàn công ty thì cần có quyết tâm hoặc mục tiêu từ cấp C-level.
Nếu là lãnh đạo tổ chức có sự hiểu biết sâu sắc và tầm nhìn thì còn ổn, nhưng với những lãnh đạo sa vào kiểu coi AI là vạn năng chỉ để chơi trò con số vì chi phí??? Tôi như nghe thấy tiếng con người đang bị vắt kiệt hu hu
Có vẻ ở dòng đầu tiên của bài viết có một liên kết hình ảnh được sắp xếp gọn gàng để dễ nhìn tổng quan.
Tôi không thấy quá đồng cảm, vì có vẻ đây là một mẹo chỉ hiệu quả trong những tình huống rất cụ thể.
Ồ, tôi cũng đã thử làm một thứ tương tự!
Đó là dịch vụ dùng AI để dịch và tóm tắt các bài đăng trên Hacker News sang tiếng Hàn rồi gửi lên kênh Telegram.
Nếu biết đã có cái này thì tôi đã không làm rồi.. haha, tôi đăng ký rồi!
https://t.me/hnaisummarykr
Có ai biết đây là nói về chuyện gì không?
Tôi muốn hỏi là bạn đã xác minh việc chạy cục bộ như thế nào?
Bên Hacker News cũng vậy, và trên diễn đàn LocalLLaMA của Reddit cũng có đánh giá rằng GLM khá tốt. GLM 4.5 AIR IS SO FKING GOODDD
Ôi..
Nghe nói áp dụng AI thì năng suất tăng gấp đôi, rồi công việc cũng bị giao gấp đôi luôn.. lương vẫn y nguyên, thậm chí còn không hỗ trợ cả chi phí AI nữa..
Cảm ơn bạn đã chia sẻ ý kiến rất hay. Như bạn đã nói, đây không phù hợp cho trường hợp sử dụng RDB và có thể xem là phù hợp cho vị trí của công cụ tìm kiếm (Elasticsearch), vector DB (Pinecone). Nội bộ chúng tôi cũng đang tận dụng Lucene, đã được kiểm chứng trong thời gian dài, để hỗ trợ các chức năng như lập chỉ mục, sắp xếp, tổng hợp, v.v. Cảm ơn bạn :)
Như bạn nói, tôi nghĩ đây sẽ là một giải pháp có thể được sử dụng theo kiểu "serverless" thực sự trong các trường hợp cụ thể, thay vì một cơ sở dữ liệu dùng cho mọi mục đích.
Không ngờ sẽ có người trả lời bằng tiếng Hàn! (Mình đã viết hơi châm biếm quá...)
Ban đầu tôi cũng nghĩ đây là một ý tưởng đột phá. Thật ra, điểm yếu lớn nhất của các cơ sở dữ liệu serverless nằm ở chỗ vẫn có server thực chạy ẩn dưới bề mặt, nơi mà vấn đề này không hề rõ ràng. Vì vậy khi lưu lượng truy cập tăng đột ngột, có thể xảy ra tình trạng treo cho đến khi server đó được cấp phát (khoảng 5 phút). Vì thế các DB serverless của các nhà cung cấp cloud hiện có (như AWS, v.v.) rất khó dùng ở cấp độ production.
Tôi từng nghĩ 'thử xem sao?', nhưng lo ngại khi nghĩ rằng nếu phải tự triển khai lại các logic nhị phân cho các chức năng như index, sort đã có sẵn ở MySQL, PostgreSQL, thì việc xây dựng lại một dự án cơ sở dữ liệu mã nguồn mở đáng tin cậy trên Lambda sẽ khó đến mức nào.
Vì đây là sản phẩm các bạn đang tự làm, nên tôi mong chờ nó sẽ tiến bộ nhiều hơn nữa~!
Cảm ơn, chắc chắn sẽ rất hữu ích ✌️
Ban đầu mình cấu hình bằng n8n, nhưng sau đó đã chuyển sang AWS Lambda + @ 🙇♂️
Mình đang quản lý theo cách này đó haha
Mình khuyên bạn thử tự làm một lần, vui lắm 👍
Cảm ơn ý kiến đóng góp rất hay của bạn. Điểm bạn nêu về việc cần có state để giảm độ trễ đã chạm đúng vào trade-off cốt lõi của kiến trúc của chúng tôi.
Trước tiên, về độ trễ truy vấn, trong benchmark của chúng tôi p99 (99th percentile) vào khoảng 130–210ms. Có lẽ phần bạn nói về chênh lệch 100 lần là đang dựa trên trường hợp xấu nhất trong bài viết là "có thể mất vài giây khi cold start". Như bạn đã chỉ ra, phần này chắc chắn là một nhược điểm của kiến trúc chúng tôi, và như đã đề cập trong bài, trong môi trường production nó xảy ra ở mức dưới 0,01% (P99.99). Ngoài ra, hầu hết các truy vấn còn lại đều được thiết kế để sử dụng bộ nhớ và ổ đĩa cục bộ của từng Lambda làm cache nhằm duy trì hiệu năng ổn định.
Do đó, như bạn đã nói, kiến trúc này có thể không phù hợp cho các hệ thống giao dịch tài chính siêu thấp trễ, nơi mọi truy vấn đều phải đảm bảo dưới 10ms. Tuy nhiên, đối với phần lớn ứng dụng tìm kiếm và gợi ý dựa trên AI, mức độ trễ 100–200ms theo chuẩn P99 đã là hiệu năng rất tốt, và tôi cho rằng lợi thế giảm hơn 90% chi phí hạ tầng và gánh nặng vận hành là lớn hơn nhiều.
Một lần nữa, xin cảm ơn những ý kiến sâu sắc của bạn.
Vì tận 65GB nên... tiếc thật T_T
Đây cũng là một dịch vụ mà tôi từng định thử làm nhưng rồi không làm được.. haha
Không biết có được dựng bằng n8n không??