Việc ra mắt của thư viện Python tên là smartfunc, thư viện chuyển đổi docstring thành các hàm được hỗ trợ bởi LLM, đã làm dấy lên một cuộc thảo luận sôi nổi giữa các nhà phát triển về cách tiếp cận tối ưu để tích hợp các mô hình ngôn ngữ lớn vào quy trình lập trình. Cuộc tranh luận này làm nổi bật một câu hỏi cơ bản: liệu LLM nên được coi là trình biên dịch cho các đặc tả cấp cao hay là trợ lý cộng tác trong quá trình phát triển?
Mô hình biên dịch so với trợ lý
Cuộc thảo luận trong cộng đồng cho thấy nhiều nhà phát triển ưa chuộng việc coi LLM như các trình biên dịch hơn là như các lập trình viên cấp dưới. Cách tiếp cận này định vị LLM như các công cụ chuyển đổi đặc tả cấp cao (như docstring) thành mã chức năng, thay vì xem chúng như những cộng tác viên tạo ra mã thông qua đối thoại. Một người bình luận đã diễn đạt rõ ràng quan điểm này, cho rằng việc coi LLM như trình biên dịch đại diện cho một mô hình tư duy có khả năng mở rộng, mở rộng và kết hợp tốt hơn so với việc xem chúng như trợ lý phát triển.
Tuy nhiên, như Simon Willison (người tạo ra thư viện nền tảng llm mà smartfunc sử dụng) đã chỉ ra, smartfunc không thực sự hoạt động như một trình biên dịch. Thay vào đó, nó chuyển đổi các hàm thành những hàm gọi một LLM mỗi khi chúng được thực thi, truyền docstring như một prompt. Sự làm rõ này đã làm dấy lên thêm cuộc thảo luận về việc một triển khai thực sự giống như trình biên dịch có thể trông như thế nào—có lẽ là tạo ra và lưu trữ mã Python khi gọi lần đầu tiên thay vì thực hiện các cuộc gọi API lặp đi lặp lại.
Tính linh hoạt thời gian chạy và các cách tiếp cận thay thế
Một hạn chế đáng kể được nhiều nhà phát triển chỉ ra là khó khăn trong việc sử dụng cùng một hàm với các LLM khác nhau tại thời điểm chạy. Mẫu decorator được smartfunc sử dụng khóa lựa chọn mô hình tại thời điểm import, điều mà một số người thấy hạn chế cho môi trường sản xuất. Các thư viện thay thế như think được đề cập là cung cấp nhiều tính linh hoạt hơn bằng cách truyền các đối tượng LLM một cách rõ ràng.
Cuộc thảo luận cũng đề cập đến các triển khai tương tự trên các ngôn ngữ khác nhau, với các nhà phát triển đề cập đến các công cụ tương đương cho JavaScript và sự quan tâm đến các phiên bản Java. Sự quan tâm đa ngôn ngữ này cho thấy nhu cầu ngày càng tăng về các mẫu tiêu chuẩn để tích hợp LLM vào các môi trường phát triển khác nhau.
Các Thư viện Tương tự Được Đề cập trong Thảo luận
- smartfunc: Thư viện Python chuyển đổi docstrings thành các hàm LLM
- Tanuki: Chức năng tương tự như smartfunc
- promptic: Bao bọc litellm với hỗ trợ cho nhiều nhà cung cấp mô hình
- think: Phương pháp thay thế truyền các đối tượng LLM xung quanh để linh hoạt trong thời gian chạy
- llm-docsmith: Plugin để tạo docstrings cho mã hiện có
- neuro-lingo: Được đề cập là có kết quả hàm "được ghim"
- instructor: Thư viện thay thế với nhiều tính năng hơn, có hỗ trợ xác thực
- marvin: Thư viện hàm LLM thay thế
Tương lai của lập trình ngôn ngữ tự nhiên
Một số người bình luận đã vẽ nên sự tương đồng giữa các nỗ lực tích hợp LLM hiện tại và các nỗ lực lịch sử nhằm làm cho lập trình dễ tiếp cận hơn thông qua ngôn ngữ tự nhiên, chẳng hạn như COBOL trong những năm 1960. Trong khi COBOL đại diện cho một nỗ lực ban đầu về cú pháp giống tiếng Anh, các LLM hiện đại có khả năng đưa chúng ta đến gần hơn với tầm nhìn của Jensen Huang về việc ngôn ngữ tự nhiên trở thành một ngôn ngữ lập trình.
Cuộc thảo luận cũng làm nổi bật một sự tương phản thú vị trong quy trình làm việc. Trong khi smartfunc sử dụng docstring để tạo ra chức năng, một số nhà phát triển báo cáo việc sử dụng LLM theo hướng ngược lại—yêu cầu chúng tạo ra tài liệu toàn diện cho mã không được chú thích đầy đủ. Mối quan hệ hai chiều giữa mã và ngôn ngữ tự nhiên này gợi ý về các phương thức phát triển đang phát triển, nơi ranh giới giữa đặc tả, triển khai và tài liệu ngày càng trở nên linh hoạt.
Lưu trữ và thực thi cục bộ
Hướng tới các cải tiến trong tương lai, các nhà phát triển bày tỏ sự quan tâm đến các phương pháp tiếp cận sẽ chưng cất chức năng LLM thành các mô hình nhỏ hơn, chuyên biệt cho các chức năng cụ thể thay vì thực hiện các cuộc gọi API lặp đi lặp lại đến các mô hình nền tảng. Điều này có thể giúp giảm độ trễ và chi phí đồng thời cải thiện độ tin cậy.
Khái niệm lưu trữ các đầu ra tốt đã biết cũng được thảo luận như một cách để giảm thiểu tính chất không xác định của LLM. Một số đề xuất các triển khai sẽ tạo mã trong các bước xây dựng, xác minh nó so với các yêu cầu kiểm tra hoặc biên dịch, và sau đó lưu trữ các kết quả thành công—về cơ bản là tạo sandbox cho những gì LLM có thể thay đổi trong khi vẫn duy trì quyền kiểm soát của nhà phát triển.
Khi các mẫu tích hợp LLM tiếp tục phát triển, cộng đồng dường như đang hội tụ vào các phương pháp tiếp cận duy trì quyền tự chủ của lập trình viên trong khi tận dụng sức mạnh của AI để xử lý các nhiệm vụ lập trình lặp đi lặp lại hoặc dài dòng. Cho dù thông qua các hàm được hỗ trợ bởi docstring như smartfunc hay các hệ thống tạo và lưu trữ mã phức tạp hơn, những công cụ này đại diện cho những bước đầu tiên hướng tới một mô hình lập trình mới, nơi ngôn ngữ tự nhiên và mã tồn tại trong một mối quan hệ cộng sinh hơn.
Tham khảo: smartfunc