- Nhiều sản phẩm AI vẫn chỉ dừng ở mức wrapper gọi các mô hình bên ngoài như ChatGPT qua API, từ đó kéo các rủi ro về khác biệt hóa, chi phí, tốc độ và khả năng tùy biến vào ngay trong sản phẩm
- Cách chỉ gọi LLM đơn thuần có thể giúp làm ra sản phẩm nhanh, nhưng ai cũng có thể sao chép và nếu OpenAI đưa cùng tính năng đó vào ChatGPT thì sẽ khó bảo vệ được giá trị riêng
- LLM đa dụng có chi phí vận hành cao, nên có thể dẫn tới cấu trúc như GitHub Copilot: thu $10/tháng nhưng chi phí trung bình là $20, và với một số người dùng có thể lên tới $80/tháng
- Visual Copilot của Builder từng thử cách dùng chỉ LLM để chuyển thiết kế Figma thành mã, nhưng do độ trễ phản hồi và giới hạn chất lượng nên đã chuyển sang toolchain riêng
- Về thực tế, tốt hơn nên giải bài toán trước bằng mã thông thường, rồi chỉ gắn các mô hình AI chuyên biệt vào những vùng hẹp mà mã tiêu chuẩn khó xử lý; cách này nhanh hơn, rẻ hơn và dễ kiểm soát hơn
Giới hạn của cách làm wrapper LLM đơn thuần
- Nhiều sản phẩm AI hiện nay gần như là các wrapper đặt trên mô hình khác, hoạt động bằng cách gửi đầu vào ngôn ngữ tự nhiên tới API ChatGPT và nhận đầu ra ngôn ngữ tự nhiên
- Cách này dễ triển khai và có thể nhanh chóng tạo ra các tính năng thú vị, nhưng nếu giá trị riêng của sản phẩm nằm ở công nghệ AI cao cấp thì rủi ro bị sao chép sẽ rất lớn
- Giống như các ứng dụng chat với PDF: một người làm ra thì nhiều người khác cũng có thể làm ứng dụng tương tự, rồi sau đó OpenAI lại đưa trực tiếp tính năng đó vào ChatGPT; đây là điều thường xảy ra khi thiếu công nghệ khác biệt
- Nếu sản phẩm chỉ ở mức gửi yêu cầu tới ChatGPT bằng một nút bấm rồi hiển thị phản hồi cho người dùng, thì khả năng phòng thủ là yếu nhất
- Nếu có công nghệ riêng đáng kể và LLM chỉ hỗ trợ một phần nhỏ nhưng quan trọng, thì vị thế sẽ tốt hơn, nhưng bài toán chi phí và tốc độ vẫn còn đó
Chi phí và tốc độ là ràng buộc thực tế khi sản phẩm hóa
- LLM đã trở nên lớn và phức tạp để có được tính đa dụng rộng, và vì thế chi phí chạy cũng cao hơn
- Theo Wall Street Journal, GitHub Copilot thu của người dùng $10/tháng nhưng chi phí trung bình là $20, và với một số người dùng còn tạo ra chi phí lên tới $80/tháng cho GitHub
- Nhiều sản phẩm không cần một mô hình khổng lồ đã học từ toàn bộ internet, và 99.9% phạm vi huấn luyện đó có thể không liên quan tới use case cụ thể
- Có thể xảy ra tình huống chi phí vận hành dịch vụ dựa trên LLM còn cao hơn số tiền người dùng sẵn sàng trả
- Tốc độ cũng ảnh hưởng mạnh tới trải nghiệm sản phẩm
- Với trải nghiệm đọc từng từ như ChatGPT, đầu ra chậm ở một mức nào đó vẫn có thể chấp nhận được
- Nhưng với các ứng dụng cần toàn bộ phản hồi trước khi chuyển sang bước tiếp theo của workflow, độ trễ sẽ trực tiếp làm giảm khả năng sử dụng
- Visual Copilot của Builder từng thử chuyển đổi bằng LLM để biến thiết kế thành mã chất lượng cao, nhưng quá trình đưa toàn bộ đặc tả thiết kế vào và nhận lại biểu diễn mới theo từng token mất tới vài phút, nên không thực tế
- Biểu diễn mà LLM trả về cũng không ở dạng con người có thể đọc ngay, nên trạng thái tải gần như chỉ là một spinner đơn giản, khiến trải nghiệm người dùng không tốt
Chỉ fine-tuning thôi vẫn khó đủ để tùy biến
- LLM hỗ trợ fine-tuning nên có thể điều chỉnh phần nào để tiến gần hơn tới hướng mong muốn
- Builder đã áp dụng fine-tuning cho cách đưa thiết kế Figma vào làm đầu vào và xuất mã ra làm đầu ra, nhưng dù cung cấp nhiều ví dụ thì chất lượng vẫn không được cải thiện
- Kết quả là một cách tiếp cận vừa chậm, vừa đắt, vừa cho chất lượng thấp, nên cần một hướng khác
- Phương án thay thế được chọn là xây dựng toolchain riêng
- fine-tuned LLM
- custom compiler do chính họ viết
- mô hình do họ tự huấn luyện
- Hiện nay, việc tự huấn luyện mô hình không còn là điều chỉ data scientist hay tiến sĩ machine learning mới làm được; developer có kinh nghiệm phù hợp cũng có thể làm
- Cách tiếp cận này giúp tạo ra sản phẩm nhanh hơn, đáng tin cậy hơn, rẻ hơn và khác biệt hơn
Sản phẩm AI phức tạp được cấu thành từ toolchain, không phải một mô hình khổng lồ duy nhất
- Một hiểu lầm phổ biến về sản phẩm AI là cho rằng toàn bộ công nghệ cốt lõi đều do một mô hình thông minh duy nhất xử lý
- Xe tự lái cũng không hoạt động theo kiểu một AI khổng lồ nhận đầu vào từ camera, cảm biến, GPS rồi ngay lập tức xuất ra hành động như rẽ phải
- Trên thực tế, nhiều mô hình chuyên biệt và mã thông thường được nối với nhau
- Mô hình computer vision tìm và nhận diện đối tượng
- Mô hình ra quyết định dự đoán hành vi của người khác
- Mô hình xử lý ngôn ngữ tự nhiên hiểu lệnh thoại
- Rất nhiều mã và logic thông thường tạo nên kết quả cuối cùng
- Xe tự lái là ví dụ phức tạp hơn rất nhiều, và khi bắt đầu với một sản phẩm AI thông thường thì chưa cần mức độ phức tạp như vậy
- Các tính năng trên ô tô cũng không hoàn thiện trong một lần, mà bắt đầu từ tự đỗ xe, tự dừng khi ở gần vật cản, rồi dần thêm các lớp như chỉnh lệch làn đường và ra quyết định lái xe tổng thể
- Cũng như phần mềm, các tính năng AI được xây theo kiểu chồng từng lớp lên nhau
Trước tiên giải bằng mã thông thường, rồi chỉ gắn AI chuyên biệt vào nơi cần thiết
- Điểm xuất phát quan trọng trong cách làm Visual Copilot là ban đầu không dùng AI
- Cần khám phá không gian bài toán bằng phương pháp lập trình thông thường trước, rồi xác định chính xác vùng nào thật sự cần mô hình chuyên biệt
- Cách “siêu mô hình” là nhét thật nhiều dữ liệu Figma vào mô hình rồi nhận ngay mã hoàn chỉnh là quá phức tạp
- Có nhiều framework cần hỗ trợ
- Có nhiều tùy chọn styling và tùy biến
- Khó liên tục huấn luyện lại để phản ánh dữ liệu mới
- Hệ thống có thể trở nên quá phức tạp, chậm và đắt, đến mức khó ra mắt sản phẩm
- Builder trước hết đã tìm hiểu xem có thể đi được bao xa nếu không dùng AI
- Mỗi node trong thiết kế cần được chuyển thành đối tượng có thể biểu diễn bằng mã
- Cần hiểu chi tiết các thành phần như hình ảnh, nền, tiền cảnh
- Cần xử lý tinh vi cách biến mọi đầu vào thành responsive
- Họ đã tạo ra nhiều thuật toán tinh vi bằng logic viết tay, chẳng hạn xử lý để các mục xếp dọc trở thành flex column, còn các mục nằm cạnh nhau trở thành flex row
- AI chỉ được thêm vào khi chạm tới giới hạn của mã tiêu chuẩn
- Ví dụ, bài toán tự động phát hiện lớp nào nên gộp thành một hình ảnh duy nhất thì con người cảm nhận rất dễ, nhưng với mã JavaScript mệnh lệnh lại không hề đơn giản
- Những loại mô hình đã được chuẩn hóa tốt như object detection có thể được huấn luyện bằng cách chọn qua GUI trên các sản phẩm như Google Vertex AI, chuẩn bị dữ liệu rồi tải lên
- Có thể tận dụng internet để tạo dữ liệu
- Dùng puppeteer mở website trong trình duyệt và chụp ảnh màn hình
- Duyệt HTML để tìm các thẻ
img - Dùng vị trí ảnh làm dữ liệu đầu ra, còn ảnh chụp màn hình trang web làm dữ liệu đầu vào
- Từ đó có được tọa độ ảnh con và ảnh gốc để dùng làm dữ liệu huấn luyện cho mô hình object detection
- Khi kết hợp mã với các mô hình AI chuyên biệt, người dùng có thể chọn thiết kế, bấm Generate code rồi chỉ chờ khoảng 1 giây để chuyển sang Builder.io
- Trên Builder, họ có thể nhận được website hoàn toàn responsive và mã chất lượng cao có thể tùy biến, đồng thời hỗ trợ nhiều framework và tùy chọn khác nhau
Lợi thế sản phẩm khi kiểm soát mô hình riêng
- Khi sở hữu mô hình riêng, bạn không chỉ dừng ở việc bọc quanh mô hình bên ngoài mà còn có thể liên tục cải thiện mô hình đó
- Nếu chỉ phụ thuộc vào các mô hình bên ngoài như OpenAI, bạn không thể đảm bảo khi nào nó sẽ thông minh hơn, nhanh hơn hay rẻ hơn cho use case cụ thể của mình
- Mức độ kiểm soát chỉ thông qua prompt engineering và fine-tuning cũng có giới hạn
- Visual Copilot hiện vẫn ở giai đoạn beta nên vẫn còn những thiết kế mà nó chưa nhập tốt được, và Builder đang phát hành cải tiến hằng ngày dựa trên phản hồi người dùng
- Khi kiểm soát công nghệ riêng, bạn cũng có thể đáp ứng tốt hơn các yêu cầu về quyền riêng tư
- Các công ty lớn coi trọng quyền riêng tư thường phản hồi rằng họ không thể dùng OpenAI hoặc sản phẩm sử dụng OpenAI
- Họ có yêu cầu dữ liệu không được đi vào những hệ thống không được phép
- Vì Builder kiểm soát toàn bộ công nghệ nên có thể áp dụng tiêu chuẩn quyền riêng tư cao
- Bước dùng LLM không phải bắt buộc mà gần như là tùy chọn, nên có thể tắt đi
- Doanh nghiệp cũng có thể kết nối LLM riêng của mình
- mô hình nội bộ hoàn toàn
- fork
llama2 - instance OpenAI enterprise riêng
- hoặc các mô hình khác
- Nên dùng AI ít nhất có thể, và giữ mã thông thường làm nền tảng nhanh, đáng tin cậy, có tính quyết định, dễ debug, dễ sửa, dễ quản lý và dễ kiểm thử
- Sự kỳ diệu của sản phẩm không đến từ việc thay toàn bộ bằng AI, mà từ việc dùng mô hình AI ở những vùng nhỏ nhưng mang tính quyết định
1 bình luận
Ý kiến trên Hacker News
Tôi đồng tình với tinh thần chung của bài viết, nhưng có lẽ sẽ không chọn cách triển khai mà tác giả đề xuất
Kết luận tôi rút ra là đừng phụ thuộc quá nhiều vào LLM. Điều đó áp dụng cả với phạm vi công việc giao cho nó lẫn việc tránh bị khóa vào một LLM cụ thể
Ví dụ, dù có dùng OpenAI nội bộ, một sản phẩm cạnh tranh trực diện với ChatGPT có thể bất lợi về dài hạn. Nếu bạn làm một ứng dụng đặt khách sạn và vé máy bay bằng chatbot, rất có khả năng một ngày nào đó ChatGPT, Microsoft hoặc Google sẽ cung cấp tính năng tương tự tốt hơn và vô hiệu hóa một doanh nghiệp nhỏ
Tôi cũng cho rằng phụ thuộc quá mức vào những thứ như OpenAI SDK là lãng phí thời gian; gọi trực tiếp REST API sẽ linh hoạt hơn
Tuy nhiên, việc thêm compiler vào chuỗi công cụ lại là vấn đề khác. Mỗi lần đưa compiler vào, độ phức tạp không cần thiết và sự phụ thuộc vào công cụ cụ thể đều tăng lên. React hay Svelte đã đủ rồi, dùng một compiler chuyển đổi chéo component có vẻ chỉ làm tăng thêm một thứ phải học để xây dựng web app
Tôi nghĩ thông điệp cuối cùng của bài nên là “hãy xây dựng chuỗi công cụ hiệu quả nhất để đạt mục tiêu”. Gắn thêm nhiều công cụ không tự tạo ra giá trị, làm theo cách người khác làm cũng không tự tạo ra giá trị; điều này áp dụng không chỉ cho việc tích hợp ứng dụng LLM mà còn cho kỹ nghệ phần mềm nói chung
Tôi không rõ AI sẽ làm điều này khác đi như thế nào, và liệu cuối cùng nó có lại đụng phải cùng những ràng buộc đó hay không
Nó sẽ độc đáo và không dễ sao chép, nhưng xét đến các ngôn ngữ cần hỗ trợ thì chi phí bảo trì sẽ rất lớn
Lớp trừu tượng bổ sung này hơi có cảm giác factory-factory-factory
Ngược lại, AI còn có nhiều dư địa chuyên biệt hóa hơn so với tìm kiếm vé máy bay
Với chatbot cho tác vụ chuyên môn, khi khả năng diễn giải ngôn ngữ cơ bản đã đủ tốt, chất lượng của mô hình ngôn ngữ đa dụng không còn là yếu tố quan trọng nhất. Một chatbot đặt du lịch được tùy chỉnh theo sở thích của tôi và tích hợp với các API ngách liên quan sẽ không dễ bị một công cụ đa dụng, tuy phân tích câu hỏi tốt hơn một chút nhưng lại muốn đặt mọi thứ qua Expedia, lấn át
Trong những thị trường như vậy, chỉ một lần nhận được gợi ý tốt hoặc gợi ý tệ cũng có thể tạo ra lòng trung thành với thương hiệu hoặc sự ác cảm, nên cũng khó xem đây là kiểu thị trường người thắng lấy tất cả
Trọng tâm của bài blog thực ra không phải là chuyện đó
Sản phẩm của họ là công cụ tự động chuyển đổi file thiết kế Figma thành mã React. Cách giải quyết vấn đề này bằng mã thông thường chính là compiler
Họ không bảo mọi người dùng compiler
Trong ngữ cảnh này, phê phán chung chung về compiler không thật sự phù hợp. Phương án thay thế là dùng ChatGPT như một compiler, và bài viết lập luận khá thuyết phục rằng cách đó còn tệ hơn. Hoặc tôi tự hỏi có phải ý bạn là bản thân việc tạo ra sản phẩm sinh mã React đã là tệ không
Đây là một bài viết gợi nhiều điều để suy nghĩ, và tôi đồng ý với ý chính “đừng dùng AI lâu nhất có thể”
AI tốt nhất nên được dùng cho những việc chỉ AI mới làm được. Nếu có cách xây dựng tính năng hoặc giải quyết vấn đề mà không cần AI, thì nên làm theo cách đó
Giờ đây mọi người đều có khả năng tiếp cận gần như tương đương với các mô hình hàng đầu, nên một sản phẩm tốt rốt cuộc sẽ được định nghĩa bởi những thứ không phải AI, tức các yếu tố kiểu cũ như workflow, UI, trải nghiệm người dùng và hiệu năng
Tuy nhiên tôi không chắc về lời khuyên “hãy huấn luyện mô hình riêng”. Đó có thể là con đường khiến sản phẩm nhanh chóng lỗi thời. Nó có thể tạo khác biệt trong chốc lát, nhưng nếu trong vòng 6–12 tháng OpenAI hoặc một đối thủ có nguồn vốn khổng lồ tung ra mô hình tốt hơn nhiều, mô hình khác biệt hóa đó sẽ lập tức trở thành nợ kỹ thuật
Một startup nhỏ cố cạnh tranh bằng mô hình có vẻ là một sự phân tán lớn. Nó giống như tự xây cơ sở dữ liệu riêng thay vì dùng Postgres hay MySQL. Tất nhiên vẫn cần hào lũy và sản phẩm khó sao chép, nhưng đó phải là lĩnh vực mà với nguồn lực hiện có, bạn có thể thực tế trở thành người giỏi nhất
Rồi khi ChatGPT xuất hiện, công sức của các đối thủ lập tức trở nên lỗi thời, còn anh ấy có thể bắt kịp các tính năng AI chỉ trong vài tuần
Anh ấy đoán đúng thứ cần xây, nhưng sai về lý do; và kết quả là doanh nghiệp được lợi rất lớn
Khác biệt hóa thực sự là một yếu tố khá quan trọng
Đây là một bài viết hay, và tôi nghĩ hầu hết các startup AI mới sẽ thấy đồng cảm. Lời khuyên của tôi là đừng tạo ra sản phẩm AI ngay từ đầu
Khuôn mẫu “sản phẩm X” hiếm khi dẫn đến hướng tạo thêm giá trị cho khách hàng. Ví dụ như sản phẩm web3, sản phẩm observability, sản phẩm thị giác máy, sản phẩm AI, v.v.
Cũng như mọi ý tưởng startup tốt, trọng tâm là bắt đầu từ nhu cầu thực của người dùng, chứ không phải vì muốn dùng một công nghệ mới nổi rồi ép nó vào một vấn đề. Gắn UI vào một công nghệ đang bị thổi phồng kỳ vọng không có nghĩa là nhu cầu người dùng được đáp ứng
Tôi không nói vậy vì ghét LLM, nhưng hầu hết những người tôi biết ngoài đời đều ghét tương tác với chatbot như một sản phẩm. Gần đây khi chuyển nhà, tôi phải làm việc với bot hỗ trợ khách hàng của các nhà cung cấp điện, nước và internet, và tất cả đều kinh khủng
Tôi cho rằng việc bắt đầu từ “GPT thật ấn tượng” rồi tạo chatbot tùy chỉnh khó có thể giải quyết nhu cầu thực của người dùng hoặc dẫn tới một doanh nghiệp bền vững
Ngay cả việc phát hiện một vấn đề đủ thật để đáng bỏ chi phí công nghệ vào cũng nằm ngoài vùng thoải mái của nhiều người làm kỹ thuật. Chúng ta thường giả định vấn đề là thật, hoặc tệ hơn là mong nó thật, rồi lao thẳng vào giải pháp. Vì xây dựng là vùng quen thuộc của chúng ta
Bản thân thái độ hay quy trình này không hẳn là sai. Trong nhiều trường hợp người làm kỹ thuật giải quyết được vấn đề thực, vấn đề thực đó tình cờ lộ ra trong quá trình xây dựng, lặp lại và dừng lại
Vì vậy với người làm kỹ thuật, cách tốt nhất để tìm ra vấn đề thực có thể không phải là ở quá lâu trong giai đoạn khám phá vấn đề, mà là có một chu kỳ ra mắt-lặp lại-dừng lại tốt hơn. Tức là nhìn vào mức sử dụng hiện tại để suy đoán tương lai, và nhanh chóng quyết định nên hoặc không nên xây dựng gì
Sau khi đọc tiểu sử của nhiều lãnh đạo công nghệ, tôi bắt đầu thấy năng lực cốt lõi phân biệt họ là khả năng bắt đầu từ một MVP rất cơ bản, rồi trong thời gian ngắn liên tục mài sắc trực giác về nhu cầu tương lai theo cấp số nhân
Vài năm trước chatbot đã tồn tại, và gần như mọi tập đoàn lớn đều từng lập chiến lược xoay quanh nó. Ý tưởng là có thể cắt giảm mạnh nhân sự call center và cải thiện trải nghiệm khách hàng
Vấn đề không chỉ nằm ở chất lượng hội thoại. Với nhiều người dùng, điều quan trọng không chỉ là nhận được câu trả lời cho vấn đề, mà còn là cảm giác kết nối con người rằng có người đang lắng nghe họ
Điều tôi muốn là việc được xử lý nhanh nhất có thể, chứ việc tôi có nói chuyện với người thật hay không không quan trọng
Lý do chatbot từ trước đến nay không hữu ích là vì chúng làm quy trình mất thêm thời gian và gây thêm bực bội. Bước đầu tiên thường là bắt chatbot nhả ra số điện thoại, hoặc cố lắm mới được nối với nhân viên tư vấn
Tất nhiên chatbot trước OpenAI rất tệ. Nhưng nếu chatbot sau OpenAI thật sự xuất sắc, tôi không thấy lý do gì khiến mọi người không dùng
Vài năm trước là blockchain. Tôi không biết tiếp theo là gì, nhưng đã thấy mạng lưới “dân công nghệ” trên LinkedIn chuyển từ startup crypto sang startup AI
Đây có vẻ là một đánh đổi rất lớn với tốc độ ra mắt
Khi bạn mất 6–12 tháng để ra mắt, các đội khác có thể đã trực tiếp dùng mô hình hosted, lặp lại hai lần và xây được tệp khách hàng thực. Lúc đó bạn mới cho khách hàng đầu tiên xem v0.1, và khách hàng có thể nói thật ra họ muốn thứ khác
Khi đó không còn là chỉnh prompt một chút nữa, mà phải code lại compiler và toolchain, từ trên xuống dưới của stack
Nếu bạn thật sự hiểu rất rõ khách hàng và yêu cầu thì điều đó có thể hợp lý, nhưng trong một tình huống dễ như vậy, tôi lại hoài nghi hơn về việc tại sao không dùng một mô hình hosted, dù tổng quát và đắt tiền, để kiểm chứng khái niệm sớm. Đây giống vấn đề tối ưu hóa quá sớm là cội nguồn của mọi điều xấu
Có rất nhiều nói về công nghệ và pipeline, nhưng nếu không có sản phẩm cần làm và vấn đề cần giải quyết thì tất cả chẳng có ý nghĩa gì
Nó giống như tranh luận với người dùng xem SOAP hay REST tốt hơn. Người dùng không quan tâm bạn đã xây nó như thế nào
Bạn đang suy nghĩ quá mức từ góc độ cạnh tranh. Chỉ cần tạo ra thứ không dễ bị sao chép
Có nhiều cách để làm điều đó, nhưng từ góc độ cạnh tranh thì quy tắc cần thiết chỉ có vậy
Ở gần như mọi thị trường dọc, gần 100% toàn bộ thị trường vẫn còn bỏ ngỏ
Khác biệt hóa kỹ thuật chỉ là một mảnh nhỏ, điều quan trọng trước tiên theo tôi là độ phủ
Đây là cuộc đua tới 1 tỷ người dùng, còn nếu là B2B như chúng tôi thì có lẽ là cuộc đua tới 1 triệu người dùng. Đồng thời đây là cuộc đua về giá trị tốt nhất, tức vấn đề được giải quyết và trải nghiệm người dùng, chứ không phải cuộc đua về thông số kỹ thuật tốt nhất
Nếu điểm khác biệt là thứ người khác không thể dùng OAI để sao chép, thì dùng OAI vẫn an toàn
Nếu điểm khác biệt duy nhất của bạn chỉ là dùng OAI, thì dù sao bạn cũng đã thua rồi
Tóm lại, tôi phần lớn đồng ý với trạng thái được đề xuất. Sản phẩm của chúng tôi cũng dùng LLM trong luồng điều khiển kiểu state machine, và hoạt động tốt
Tuy nhiên tôi không đồng ý với cảm xúc của tác giả. Nếu là lập trình viên chỉ từng dùng UI web của ChatGPT, bạn chắc chắn nên tự đụng tay vào và thử xây công nghệ “AI wrapper” 100%
Vì trước khi tự mình tìm ra giới hạn của các mô hình hàng đầu, rất khó thấy nên dùng LLM ở đâu và như thế nào trong một software stack truyền thống
Công ty của tác giả rốt cuộc cũng có vẻ đã đi theo con đường này. Ban đầu họ tạo một nguyên mẫu dựa trên LLM để chuyển từ Figma sang code, và sau khi nó hoạt động “ở một mức độ nào đó”, họ phát hiện các lỗ hổng trong quy trình
Vì vậy tôi nghĩ tốt hơn là cứ thử làm thứ bạn muốn bằng GPT-4-Vision, dù là “hệ thống chấm điểm thẻ sưu tập dựa trên AI” hay gì đi nữa, rồi sau đó tìm cách biến nó thành sản phẩm thực sự hoạt động như builder.io
Có vẻ AI sẽ sớm được tích hợp vào nhiều phần mềm. Khi đó mọi thứ sẽ vừa rất tuyệt vừa đáng sợ
Một ví dụ đơn giản là ứng dụng email. Khi ai đó yêu cầu quyết định hoặc xác nhận, AI có thể trích xuất câu hỏi và đưa ra các nút radio
Ví dụ: Chấp nhận thời gian hẹn được đề xuất: [Thứ Sáu 10:00] [Thứ Hai 11:30] [Đề xuất thời gian khác]
George đang hỏi liệu anh ấy có thể trình bày bản nháp không: [Có] [Không]
Có vẻ các phần mềm ticket hỗ trợ khách hàng như Zendesk đã có AI. Rất có khả năng nhiều yêu cầu hỗ trợ đã được trả lời gần như tự động
Bộ phận nhân sự cũng có thể dùng AI để sàng lọc hồ sơ ứng tuyển, cho AI tìm thêm thông tin về ứng viên trên Internet, rồi tạo các mục dữ liệu chuẩn hóa trong cơ sở dữ liệu. Tất nhiên việc này có thể có rất nhiều sai sót
Điều thú vị là những kiểu ứng dụng như vậy, chứ không phải lại thêm một tiện ích mở rộng hay plugin ChatGPT khác
Tôi định chạy một pipeline cho mỗi email mới để đề xuất vài hành động
Vẫn còn đang cân nhắc nhiều cách tiếp cận trong đầu, nhưng chuyện này đã có vẻ hoàn toàn khả thi
Phần mở đầu có vẻ hơi quá hoa mỹ và phóng đại. Ví dụ, LLM cũng không đắt đến thế, tuyên bố của WSJ rằng Copilot lỗ trên mỗi người dùng thì không thuyết phục lắm, và cũng khó nói LLM lúc nào cũng “chậm đến đau đớn”
Dù vậy, các khuyến nghị thực sự của bài viết khá hợp lý
Tức là xử lý càng nhiều phần càng tốt bằng code, và dùng AI chuyên biệt cho những phần không thể làm bằng code
Hợp lý, nhưng không phải điều gì đặc biệt mới
Tôi đã kỳ vọng bài viết đi sâu hơn vào cách tạo ra sản phẩm AI thực sự hữu ích và tốt. Gần đây có nhiều nỗ lực như lần ra mắt Humane, nhưng có vẻ vẫn chưa có nhiều thành công
Bài viết này khá tập trung vào cách xây dựng sản phẩm AI, nhưng cá nhân tôi cho rằng thành bại của một “sản phẩm AI” phụ thuộc vào việc nó có thật sự hữu ích không, hơn là khác biệt hóa, chi phí, tốc độ hay tùy biến mô hình
Đáng tiếc là phần lớn sản phẩm tôi thấy cho đến nay đều có cảm giác như một lời giải đang đi tìm bài toán
Tôi nghĩ con đường các công ty nên đi lúc này là tìm ra những phần nhàm chán và lặp lại nhất khi dùng sản phẩm, rồi tìm cách dùng AI để đơn giản hóa chúng một cách ổn định
Như mọi chu kỳ cường điệu, nếu thứ duy nhất bạn có là cái búa thì mọi thứ đều trông như cái đinh
Cái búa cách đây không lâu là blockchain, còn bây giờ là AI
Nếu bạn từng ngây thơ đến mức tin vào lời hứa của blockchain, thì việc thất vọng vì AI không phải là một mô hình kim tự tháp làm giàu nhanh giúp kiếm hàng triệu đô la mà không cần thời gian, năng lượng hay tư duy độc lập cũng là điều dễ hiểu
Nếu bạn chỉ tìm những thứ như vậy thì bạn sẽ tiếp tục thất vọng, và cũng đáng thôi
AI có nhiều thứ hơn blockchain rất nhiều. So sánh hai thứ này như ngang hàng nghĩa là bạn chưa thật sự hiểu đúng về bất kỳ thứ nào trong hai thứ đó