- antirez, người sáng lập Redis, thường xuyên sử dụng AI và LLM, nhưng cho rằng ở thời điểm hiện tại, năng lực giải quyết vấn đề của con người vẫn vượt xa LLM
- Ông đã trực tiếp trải nghiệm giới hạn của LLM trong quá trình sửa một lỗi phức tạp phát sinh ở Redis Vector Sets
- Các thuật toán mà LLM đề xuất chỉ dừng lại ở những lời giải tiêu chuẩn hoặc đơn giản
- Cách tiếp cận sáng tạo của lập trình viên con người có lợi thế trong việc đưa ra những lời giải đổi mới mà LLM khó chạm tới
- LLM rất hữu ích cho việc kiểm chứng ý tưởng hoặc làm đối tác đối thoại, nhưng sự sáng tạo cuối cùng vẫn thuộc về con người
Mở đầu: So sánh giữa con người và LLM
- Tôi hoàn toàn không có ác cảm gì với AI và LLM
- Tôi đã sử dụng LLM hằng ngày trong thời gian dài, theo nhiều cách như thử nghiệm ý tưởng, review code, tìm phương án thay thế
- Trình độ hiện tại của AI rõ ràng là thực dụng và có nhiều điểm xuất sắc, nhưng tôi nhấn mạnh rằng khoảng cách với trí tuệ con người vẫn còn rất lớn
- Gần đây tôi cảm thấy cần phải viết bài này vì việc thảo luận cân bằng về AI ngày càng trở nên khó khăn
Trường hợp lỗi Redis Vector Sets
- Gần đây tôi đang sửa một lỗi liên quan đến Vector Sets trong Redis
- Khi các đồng nghiệp Redis vắng mặt, tôi đã đưa vào một cơ chế bảo vệ bổ sung chống hỏng dữ liệu tệp (RDB/RESTORE)
- Tính năng này mặc định bị tắt, và là một lớp an toàn bổ sung nhằm ngăn hỏng dữ liệu ngay cả khi checksum vẫn vượt qua
- Vấn đề phát sinh trong quá trình tối ưu tốc độ tuần tự hóa biểu diễn đồ thị của cấu trúc HNSW vào RDB
- Danh sách kết nối giữa các node được lưu dưới dạng số nguyên, rồi được khôi phục lại thành con trỏ khi giải tuần tự hóa
- Do đặc điểm của cách hiện thực HNSW (đảm bảo liên kết hai chiều), nếu đồ thị hoặc bộ nhớ bị hỏng thì có thể xảy ra các vấn đề sau
- Dữ liệu có thể ghi rằng A kết nối với B, nhưng B lại không kết nối với A (do lỗi đánh số chẳng hạn)
- Khi node B bị xóa, vi phạm liên kết hai chiều có thể khiến liên kết A→B vẫn còn, từ đó về sau khi duyệt B->A sẽ phát sinh lỗi use-after-free
- Sau khi nạp dữ liệu, cần xác minh rằng mọi liên kết đều thỏa điều kiện 'liên kết hai chiều'
- Nếu áp dụng thuật toán thuần túy thì độ phức tạp là O(N^2). Với dữ liệu lớn (~20 triệu vector), tốc độ nạp đã bị tăng gấp đôi từ 45 giây lên 90 giây
Áp dụng LLM và các giới hạn
- Tôi đã trò chuyện với Gemini 2.5 PRO để hỏi về phương pháp hiệu quả hơn và xem xét các đề xuất của LLM
- Đề xuất đầu tiên của LLM: sắp xếp danh sách node lân cận rồi áp dụng tìm kiếm nhị phân (binary search) (một cách làm đã quá quen thuộc)
- Tôi nói rằng nó không cải thiện nhiều và yêu cầu thêm ý tưởng, nhưng không nhận được câu trả lời tốt hơn
- Phương án thay thế do tôi đề xuất: dùng bảng băm để đăng ký và loại bỏ các cặp liên kết (A:B:X, đã sắp xếp và bỏ phân biệt hai chiều)
- LLM cũng đánh giá đây là ý tưởng tốt, nhưng chỉ ra nhược điểm như hiệu năng tạo khóa và hiệu năng băm
- Tôi còn đề xuất tăng hiệu quả bằng cách xử lý khóa có độ dài cố định bằng
memcpy thay vì snprintf
Sự sáng tạo của con người vs giới hạn của LLM
- Tôi đã đề xuất một ý tưởng không cần bảng băm, dùng kỹ thuật XOR trên bộ tích lũy (accumulator)
- Các cặp con trỏ (và thông tin level) được XOR vào bộ tích lũy; nếu liên kết hai chiều đầy đủ thì chúng triệt tiêu nhau (0), còn nếu thiếu sẽ để lại dấu vết mẫu
- Tuy vậy, cũng có thể chỉ ra khả năng va chạm và tính dễ dự đoán của con trỏ (LLM cũng đồng ý ở điểm này)
- Cải tiến thêm: kết hợp seed ngẫu nhiên/băm (
murmur-128 và seed từ urandom), rồi áp dụng XOR lên bộ tích lũy 128-bit
- Cuối cùng, chỉ cần kiểm tra giá trị bộ tích lũy có bằng 0 hay không để xác định liên kết hai chiều có được thỏa mãn hay không
- LLM đánh giá cách này vừa hiệu quả vừa có độ bền vững cao trước lỗi thông thường và cả tác nhân tấn công bên ngoài
Kết luận
- Cuối cùng tôi khép lại phần phân tích để quyết định có nên đưa cách làm này vào hay không sau khi đánh giá độ tin cậy
- Trường hợp này cho thấy cách tiếp cận sáng tạo, phi tiêu chuẩn của lập trình viên con người vượt trội hơn những câu trả lời bị giới hạn mà LLM đưa ra
- LLM cực kỳ hữu ích cho việc kiểm chứng ý tưởng và làm đối tác đối thoại trí tuệ ('con vịt thông minh')
- Tuy nhiên, ở khả năng tạo ra lời giải sáng tạo sau cùng, ưu thế của con người vẫn rất rõ ràng
7 bình luận
redis sắp tụt lại phía sau rồi
Cảm giác như đang cho xe đạp đua với chạy bộ vậy.
antirez là kiểu lập trình viên thuộc top 1%. Tôi nghĩ những lập trình viên top 1% vẫn sẽ tiếp tục vượt trội hơn LLM. Nhưng 99% còn lại thì tôi không chắc.
Tôi đã nhiều lần cố troubleshooting bằng AI nhưng đều thất bại hoàn toàn, cuối cùng vẫn phải tự mình giải quyết vấn đề.
Tôi nghĩ việc LLM có vẻ ở trình độ cao và sáng tạo là vì chúng đã học từ những bài viết như vậy, và để nâng cao chất lượng kết quả đó, vô số nhà khoa học đã kiểm chứng tri thức ấy và nâng chất lượng dữ liệu huấn luyện.
Nhưng theo thời gian, xu hướng thay đổi hoặc tùy tình huống sẽ cần những kiểu sáng tạo khác nhau, nên rốt cuộc chẳng phải người sử dụng vẫn phải phát huy sự sáng tạo cho phù hợp với hoàn cảnh của mình sao..
Ý kiến trên Hacker News
Tôi thấy điều này khớp chính xác với trải nghiệm của mình. Thật ra giá trị lớn nhất mà trợ lý LLM mang lại cho tôi là nó đóng vai trò như một con “vịt cao su” khá thông minh. Đôi khi con “vịt” này còn phản biện lại ý kiến của tôi, thậm chí giúp suy nghĩ của tôi trở nên chặt chẽ hơn. (Rubber duck debugging là gì?) Nhưng tôi nghĩ câu hỏi cốt lõi mà ai cũng muốn bỏ qua là: “Giá trị này liệu còn tiếp tục tồn tại sau 2 năm nữa không?” Bản thân tôi cũng không biết câu trả lời
Với tôi, LLM không phải là vịt cao su mà giống một “cỗ máy trả lời sai”. Có câu nói rằng cách tốt nhất để nhận được đáp án trên Internet là đăng một câu trả lời sai, và với tôi nó đúng là làm vai trò đó. Khi giao cho LLM những việc đơn giản nhưng phiền phức, nó cho ra kết quả sai đến mức tôi bực mình và cuối cùng tự làm luôn bằng sức mạnh của cơn cáu giận
Một con vịt quá tự tin, thể hiện sự chắc chắn vượt xa năng lực thực tế của nó. Tôi đã thấy quá nhiều người lạc hướng khi nói chuyện với LLM
Với tôi, LLM giống như một lập trình viên junior làm dưới quyền, biết khá rõ về API nhưng thiếu thường thức ở cấp kiến trúc. Tôi phải rà soát tới 3~4 lần hầu hết các PR trước khi chuyển sang review của cả team vì lo những sai sót ngớ ngẩn. Điểm tốt là nhờ vậy tôi có thể dành não cho vấn đề khác
Giá trị này có còn giữ sau 2 năm không ư? Với tôi, mối lo còn lớn hơn chuyện “liệu cuộc trò chuyện này có còn ý nghĩa không”, mà là “liệu chúng ta có sống tới được 2 năm nữa không?” Thế giới hiện tại quá bất ổn, đến cả 6 tháng tới trông ra sao cũng không thể đoán được
Với tôi, LLM giống một đồng nghiệp pair programming. Một đối tượng để bàn ý tưởng, để review code và đưa ra phương án thay thế. Và tôi cũng có thể học được bằng cách thử những tính năng mà trước đây mình không biết
Đọc phần bình luận này, tôi có cảm giác mọi người hơi đặt kỳ vọng vào những câu như “con người là không thể thiếu”, “LLM không debug được”, “LLM dẫn sai đường”. Tất nhiên những điều đó là thật, nhưng chỉ 2 năm trước, việc sinh mã tự động còn không làm được như bây giờ, vậy mà nó đã tiến rất xa và hiện vẫn đang giữ nhịp phát triển rất nhanh. Về sau tốc độ cải thiện có thể chậm lại kiểu “định luật Pareto”, nhưng tôi tin chắc nó vẫn sẽ tiếp tục tiến bộ. Gần đây tôi kể trên r/fpga rằng mình đã dùng LLM để tạo thành công phiên bản đầu của testbench, vậy mà thật đáng kinh ngạc khi thấy những người chưa từng thử lại phủ nhận luôn khả năng đó
Kiểu thái độ này cực kỳ phổ biến trong giới hành nghề chuyên môn. Tôi cũng ghé /r/law và nghe các phản ứng về phát biểu của Dario Amodei liên quan tới AI trong lĩnh vực pháp lý, rồi cảm nhận rất rõ bầu không khí phủi tay bác bỏ theo phản xạ. Có thể đó là một cơ chế thích nghi và tự trấn an với hiện thực, nhưng tôi nghĩ nó rất có hại cho khả năng chuẩn bị trước những thay đổi kinh tế và xã hội trong tương lai
Nó giống như thời assembly còn là nền tảng, khi các ngôn ngữ lập trình mới xuất hiện thì lập trình viên lúc đó đã chế giễu chúng là kém hiệu quả, thiếu linh hoạt, quá đơn giản hóa, dù điều đó chẳng thật sự liên quan tới thực tế. Hiện tượng này là phản ứng rất tự nhiên, gần như không liên quan tới giá trị thực của công nghệ mới
LLM có vẻ từng tăng trưởng bùng nổ trong một giai đoạn ngắn, nhưng các model gần đây thậm chí lại cho cảm giác thụt lùi. Nó cho kết quả tốt khi tạo test code, nhưng nếu dùng LLM quá sâu cho những việc như triển khai tính năng mới thì mọi thứ lại trở nên kỳ quặc. Nó hợp với dự án mới hoặc web app đơn giản, nhưng không hiệu quả lắm khi refactor codebase lớn hay legacy, hoặc thêm tính năng vào đó. Ví dụ, tôi khá thường xuyên thấy Claude hay ChatGPT bịa ra cả một mớ vô nghĩa về D3 API
Rốt cuộc thì chính bạn đang tự xây ra người thay thế mình, còn đồng nghiệp của bạn thì đang di chuyển cẩn trọng
ChatGPT-4o thể hiện năng lực cực kỳ ấn tượng trong việc viết VHDL. Hôm nay tôi cũng đang trải nghiệm kết quả đáng kinh ngạc khi dùng nó để làm prototype cho bộ điều khiển cấp thấp
Lượng context cần thiết để viết phần mềm thật sự cho ra hồn là quá lớn đối với LLM. Phần mềm tự thân nó là “sự mã hóa của nghiệp vụ kinh doanh”. Làm sao LLM biết được đủ thứ điều khoản đặc biệt mà đội sales đã hứa với khách hàng, hay các quy tắc ngầm khác nhau giữa từng phòng ban? Phạm vi mà LLM có thể xử lý hiện tại vẫn còn mang tính tổng quát và giới hạn. Chỉ cần hơn hai class hoặc vượt quá 20~30 file là ngay cả LLM hàng đầu cũng bắt đầu lạc hướng và mất tập trung. Vì không giữ được context nên code churn vô ích tăng mạnh. Nếu LLM thực sự muốn thay thế lập trình viên thật, nó phải hấp thụ được nhiều context hơn rất nhiều, thu thập context từ cả tổ chức, và duy trì mạch suy nghĩ trong các dự án dài hơi. Khi những vấn đề như vậy thực sự bước vào giai đoạn được giải quyết, lúc đó tôi mới bắt đầu lo thật sự
Mỗi khi bàn chuyện LLM có thay thế lập trình viên hay không, mọi người đều quên rằng kỹ nghệ phần mềm thực tế còn vô số việc ngoài viết code. Viết code thật ra chỉ là một phần nhỏ. Những thứ quan trọng là kỹ năng xã hội, phân tích yêu cầu, tìm ra điều khách hàng thực sự muốn, trong khi ngay cả khách hàng cũng thường không biết rõ mình muốn gì nên kỹ sư phải rất vất vả để hiểu ra điều đó. Nếu việc đó đến con người còn khó, thì không có lý gì LLM lại làm nổi
Cuối cùng thì đây là vấn đề của feedback loop, tức vòng lặp lặp lại ngay lập tức nơi khách hàng dùng thử rồi đưa phản hồi. Giao diện chat rất mạnh cho vòng phản hồi với khách hàng, còn agent có thể tạo phiên bản mới rất nhanh. LLM hoàn toàn có thể làm abstraction, hệ thống nhiều component, thiết kế cấu trúc tổng thể, thậm chí cả phân tích yêu cầu. Điểm mấu chốt là tốc độ lặp nhanh tới mức nào. Độ vững và IQ của model đang tiếp tục tăng lên. Toàn bộ kỹ nghệ phần mềm đã bước vào giai đoạn tự động hóa. Có lẽ 5 năm nữa, nếu con người không được hỗ trợ thì chính họ sẽ trở thành nút thắt cổ chai lớn. Nếu không tích hợp sâu với AI thì chắc chắn sẽ tụt lại phía sau
Đây cũng chính là vấn đề từng xảy ra trong làn sóng offshoring hồi những năm 2000. Các đội ở nước ngoài khó nêu yêu cầu chỉnh sửa hay phản biện vấn đề, nên chỉ làm đúng thứ được giao và kết quả thì cứ thế tích tụ chồng chất. Có lẽ AI cũng sẽ rơi vào tình huống tương tự. Và có vẻ kết quả cũng sẽ giống nhau
Ngay từ đầu, LLM vốn không làm software engineering theo đúng nghĩa. Nhưng đó cũng không hẳn là vấn đề. Trên thực tế, rất nhiều chương trình thành công vẫn chạy ổn dù chẳng có “software engineering” đúng nghĩa. Điều này càng đúng trong môi trường nơi không ai để tâm tới cấu trúc chi phí cloud. Thậm chí tôi nghĩ trong tương lai, những người kiểu đối tác kinh doanh IT có cảm quan kỹ thuật sẽ tự làm ra cả ứng dụng mà không cần một kỹ sư phần mềm nào hỗ trợ. Trong ngành năng lượng xanh, đó đã là thực tế mỗi ngày rồi. Nhưng vấn đề sẽ bùng lên khi cần bảo trì, mở rộng và tối ưu hiệu quả. Lúc đó những chuyện như “nên dùng list hay generator trong Python” mới bắt đầu trở nên quan trọng, và đó là lúc cần tới kỹ nghệ thật sự
Sau 5 năm nữa có khi chúng ta gần như sẽ không còn tự thiết kế code nữa. So với 1 năm trước, lượng code tôi phải tự tay gõ đã giảm rất nhiều. Nhưng dù vậy đây vẫn chỉ là một phần của quy trình, chứ không phải lập trình viên sẽ biến mất hết
Mặt khác, vai trò “coder” đơn thuần thật sự đang bị thay thế khá nhiều. Đây chính là vùng mà LLM làm rất tốt. Có rất nhiều coder kiểu vô thức chỉ nhìn ticket dạng “nhận API này rồi trả ra giá trị kia”, hoàn toàn không làm chuyện hiểu yêu cầu khách hàng hay phân tích gì cả, và phần này đang bị dọn đi rất nhanh. Software engineering đúng nghĩa là một lĩnh vực hoàn toàn khác, nhưng cũng không thể phớt lờ thực tế rằng nhu cầu với coder đơn thuần từng rất lớn
Một điểm rất quan trọng là chỉ con người mới có khả năng xử lý các khái niệm trừu tượng của chương trình và giải quyết vấn đề theo cách sáng tạo. Lập trình viên là kiến trúc sư của logic, còn máy tính là thứ chuyển đổi tư duy của con người thành mệnh lệnh. Công cụ có thể bắt chước con người và giỏi sinh code cho từng tác vụ cụ thể, nhưng chưa thể thay thế vai trò thiết kế trừu tượng và xây dựng ở tầng gốc. Nếu model có được khả năng không chỉ viết code mà còn tạo hẳn cả dự án hoàn chỉnh theo đặc tả, thì vai trò của lập trình viên lại sẽ thay đổi thêm lần nữa
Luôn cần tiếp cận theo hướng “cái gì tốt hơn” là khác nhau tùy từng loại việc. LLM hiện đã làm tốt hơn tôi rất nhiều ở các công việc lặp đi lặp lại, nặng tính công thức như chỉnh cú pháp CSS hay cách gọi các thư viện nổi tiếng. Những “sự kiện lặt vặt” kiểu này trước đây từng ngốn rất nhiều thời gian của tôi, còn giờ gần như được xử lý ngay lập tức nên tôi rất hài lòng
Nhưng với styling ở mức nền tảng, tức vượt ra ngoài CSS cơ bản, thì kết quả của LLM lại khá tệ. Khi hiệu ứng khó mô tả rõ ràng, hoặc công việc trở nên tinh tế hơn, nó rất thường không đưa ra được kết quả quan trọng nhất mà lại mắc kẹt vào một cách làm duy nhất
Với thứ tôi không giỏi (SQL) thì LLM tốt hơn tôi nhiều, nhưng với thứ tôi biết rõ (CSS) thì ngược lại nó làm kém. Tiêu chuẩn đánh giá hiện ra khá rõ từ đó
Tôi đồng ý với ý “nó tốt hơn phần lớn lập trình viên”, và cả ý rằng LLM trông có vẻ tốt hơn đơn giản vì nhiều người không làm được CSS. Thật ra đây là ngộ nhận sinh ra từ việc có nhiều người ghét CSS nên không chịu học mà chỉ dùng miễn cưỡng. Nếu công ty không đủ khả năng thuê chuyên gia CSS thật sự và muốn tìm cách rẻ hơn, thì LLM là một phương án thay thế; còn nếu đủ sức tìm được người giỏi thật thì đương nhiên LLM không thể so sánh. Cuối cùng thì đối thủ cạnh tranh của LLM là các lập trình viên kém năng lực
Trong các ngôn ngữ chính hoặc lĩnh vực mình chưa nắm chính xác, autocomplete của LLM giúp ích rất nhiều. Tuy nhiên, nếu không rèn được “khả năng nhớ theo phản xạ” mà chỉ phụ thuộc vào LLM, thì sẽ có nguy cơ thiếu năng lực để đánh giá những gợi ý từ công cụ này và mắc kẹt trong các lời giải kém chất lượng
Tôi mừng vì có nhiều người quan tâm tới “code tốt”, nhưng lại sợ rằng rốt cuộc nó chẳng còn ý nghĩa gì. Ngành phần mềm từ lâu đã bị thế giới kinh doanh xâm lấn, đến mức cũng chẳng rõ nó bắt đầu từ lúc nào nữa (có phải từ khi Bill Gates viết open letter năm 1976 không?). Vấn đề thật sự là cổ đông và ban điều hành ngày càng ít quan tâm tới code, miễn lợi nhuận tăng là được. Nếu không có sự kháng cự về mặt văn hóa từ phía lập trình viên và người dùng, cấu trúc này có lẽ sẽ tiếp tục kéo dài
Về ý “nếu không có kháng cự văn hóa từ lập trình viên/người dùng thì coi như hết”, tôi muốn nói rằng vẫn có nhiều công ty làm code tốt và không phải chỗ nào cũng là một mớ hỗn độn. Vấn đề không chỉ là chất lượng code mà còn là câu hỏi đạo đức: bạn có đồng ý với các mục tiêu kinh doanh mang tính tư bản chủ nghĩa hay không. Điều quan trọng nhất là sự cân bằng giữa phần mềm đẹp và thực tế. Tôi cũng là lập trình viên và nhà sáng lập, yêu open source và engineering, nhưng đồng thời cũng muốn sống đủ thoải mái
Code là động lực của kinh doanh. Code tệ dẫn tới kinh doanh tệ. Có sự khác biệt rất rõ giữa các đội hosting (tường lửa vật lý, vmware, proxy, v.v.) và public cloud (QEMU, netfilter, phần cứng đơn giản, v.v.). Ai xâm lấn ai, tương lai sẽ ra sao, không ai đoán chắc được
Tối qua tôi vật lộn với o3 và mất sạch thời gian. Cả đời tôi chưa từng viết Dockerfile, nên định nhập kho GitHub vào o3 rồi để nó tự giải quyết, nhưng cuối cùng lại tốn hàng giờ chỉ để debug kết quả nó tạo ra. Nó cứ thêm vào những thứ không hề tồn tại, xóa hoặc trộn lẫn những thứ vốn không có, thậm chí còn nhầm cả những khái niệm cơ bản như sự khác nhau giữa python3 và python. Cuối cùng bực quá tôi đi tìm Google Docs thì mọi thứ sáng ra rất nhanh. AI đúng là công cụ tuyệt vời, nhưng không phải vạn năng, và bài học là luôn phải có ai đó thật sự “tỉnh táo” giám sát
Những công ty dùng LLM·AI để nâng năng suất làm việc của nhân viên sẽ phát triển mạnh, còn những công ty muốn thay thế luôn nhân viên thì tôi dự đoán sẽ thất bại. Trong ngắn hạn, CEO và lãnh đạo có thể vẫn hài lòng với thành tích trước mắt, dù đó là quyết định đang bào mòn tăng trưởng tương lai
Đó chính là đáp án. Dùng LLM như trợ lý cho lập trình viên mới là đúng, còn thay thế hoàn toàn thì không thực tế. Tiếp nhận công nghệ ở mức vừa phải mới là con đường đúng
Tôi thấy ý tưởng rằng việc thay nhân sự để tăng giá trị ngắn hạn có thể mang lại lợi ích cho công ty là khá thú vị. Tức là về trung và dài hạn nó có hại cho công ty, nhưng tạm thời giá cổ phiếu vẫn có thể tăng
Trợ lý code là công cụ phổ cập bắt buộc, chứ không phải vũ khí để thay thế con người. Trong thời đại đối thủ cạnh tranh cũng có thể mua cùng một gói AI như bạn, thì nó không thể dùng để thay thế người được
Chia sẻ kinh nghiệm thực tế - trước đây là lập trình viên, giờ đã thành quản lý nhưng vẫn viết code. Trợ lý LLM có ích nhưng đôi khi cũng gây khó chịu. Khi nó đột ngột tung ra hàng loạt gợi ý code ngoài dự đoán, mọi thứ có thể chệch khỏi ý định ban đầu và lại tốn thời gian để rà soát. Có lẽ là do vấn đề cài đặt, nhưng tôi muốn đổi mặc định để chỉ hiện ra khi tự mình gọi bằng lệnh. Có một điều chắc chắn là dù có giao cho LLM viết toàn bộ code hay cả một hàm, tôi vẫn luôn tự mình review lại
Trình soạn thảo Zed có tính năng kiểu chế độ “gợi ý nhẹ nhàng” này (xem chi tiết). Giá mà editor nào cũng có chế độ như vậy
Dạo này làm đủ thứ việc ở startup nên tôi không thích UI do LLM tạo ra lắm. Những khối cơ bản kiểu building block thì hữu ích, nhưng nếu giao hẳn cho Claude viết cả một block code dài thì để đi tới thứ tôi thực sự muốn lại phải làm lại vô số lần
https://freederia.com Có lẽ sẽ duy trì mối quan hệ cùng tồn tại như trang web nhà khoa học AI.