# Dự án nghiên cứu

Canonical HTML: https://aogavrilov.com/vi/projects/

Document language: vi

Bắt đầu từ lỗi có thể quan sát, rồi lần theo phương pháp, bằng chứng và giới hạn phạm vi phù hợp với lỗi đó.

## Lựa chọn dựa trên lỗi quan sát được

Cùng một biểu hiện có thể bắt nguồn từ khâu biểu diễn, sinh, điều khiển hoặc kiểm chứng.

| Vấn đề quan sát được | Chẩn đoán đầu tiên | Bằng chứng cần có | Phương pháp |
| --- | --- | --- | --- |
| Đầu ra đã giải mã có chất lượng kém, nhưng chưa xác định được giai đoạn gây lỗi | Chấm điểm nguồn, bản tái dựng tương ứng và đầu ra được sinh bằng cùng một bộ đánh giá bên ngoài. | Các phân phối và hành vi phần đuôi có thể so sánh ở mọi giai đoạn. | [Chẩn đoán nút thắt theo giai đoạn](https://aogavrilov.com/vi/projects/codec-bottleneck-diagnosis/#workflow) |
| Thước đo trong không gian tiềm ẩn cải thiện nhưng chất lượng cuối thì không | Kiểm tra xem mức cải thiện của chỉ báo thay thế có được duy trì sau giải mã hay không. | Các chỉ số ghép cặp trên đầu ra đã giải mã, không chỉ riêng chẩn đoán tiềm ẩn. | [Kiểm tra khả năng chuyển giao của đại lượng đại diện](https://aogavrilov.com/vi/projects/codec-bottleneck-diagnosis/#decision-table) |
| Trình biên tập mã viết lại nhiều hơn vùng được yêu cầu | Nêu rõ ranh giới bảo toàn và đo phần sai khác bên ngoài vùng này. | Tính cục bộ và mức độ hoàn thành nhiệm vụ được đo đồng thời. | [Đánh giá chỉnh sửa cục bộ](https://aogavrilov.com/vi/projects/discrete-latent-generation/#measurement) |
| Tái cấu trúc phải bảo toàn hành vi, không chỉ cú pháp | Tách khâu đề xuất khỏi khâu thực thi và kiểm chứng. | Biên dịch, kiểm thử, kiểm tra tĩnh và phát hiện tái cấu trúc. | [Sơ đồ quyết định giao diện điều khiển](https://aogavrilov.com/vi/projects/discrete-latent-generation/#control-surface) |

Hướng nghiên cứu đang triển khai

## Sinh dữ liệu trong không gian tiềm ẩn rời rạc

Biểu diễn rời rạc phục vụ tái sinh mã có chọn lọc, cùng các lựa chọn dựa trên bằng chứng giữa sinh có ràng buộc, tái cấu trúc có AI hỗ trợ và chỉnh sửa mã có thể dự đoán.

Hướng dẫn đánh giá

## Chẩn đoán nút thắt codec

Phương pháp theo từng giai đoạn để xác định chất lượng đã giải mã bị giới hạn bởi tái dựng, sinh trong không gian tiềm ẩn hay một chỉ báo thay thế không chuyển giao sang văn bản cuối.

## Các câu trả lời trọng tâm

Các ghi chú bằng chứng độc lập dành cho những lượt tìm kiếm rộng hơn không bắt đầu bằng tên bài báo. Mỗi ghi chú đều dẫn về ấn phẩm và toàn văn tương ứng.

1. [Khuếch tán che mặt nạ trong không gian mã và không gian token: cách so sánh](https://aogavrilov.com/vi/research-notes/code-space-vs-token-space-masked-diffusion/) Quy trình so sánh nhất quán theo giai đoạn cho các mô hình ngôn ngữ khuếch tán có che mặt nạ trong không gian mã và không gian token khi codec rời rạc gây mất mát.
2. [Sửa đổi mã cục bộ bằng mô hình sinh](https://aogavrilov.com/vi/research-notes/localized-code-modification-generative-models/) Cách tránh viết lại toàn bộ hàm khi không cần thiết, đồng thời duy trì đủ mức tự do để mô hình sinh thực hiện thay đổi mã được yêu cầu.
3. [Sinh mã có ràng buộc cho kỹ nghệ phần mềm](https://aogavrilov.com/vi/research-notes/constrained-code-generation-software-engineering/) Sự phân biệt thực tiễn giữa ràng buộc ngữ pháp, ràng buộc kiểu, ranh giới bảo toàn và phép kiểm tra chấp nhận ở cấp hành vi đối với mã được sinh.
4. [Tái cấu trúc có AI hỗ trợ: phương pháp và bằng chứng](https://aogavrilov.com/vi/research-notes/ai-assisted-refactoring-evidence/) Cách đánh giá các phương pháp tái cấu trúc có AI hỗ trợ gần đây mà không nhầm lẫn một bản vá được sinh ra có vẻ hợp lý với việc bảo toàn hành vi đã được kiểm chứng.
5. [Sinh mã có thể dự đoán đòi hỏi một hợp đồng bảo toàn](https://aogavrilov.com/vi/research-notes/predictable-code-generation-preservation-contract/) Vì sao lấy mẫu tất định vẫn chưa đủ, và các thuộc tính được bảo vệ có thể quan sát cùng phép kiểm tra chấp nhận giúp hành vi sinh mã trở nên kiểm thử được như thế nào.

## Các câu hỏi nghiên cứu mà trang này có thể giải đáp

Hãy mở một câu hỏi thực tiễn để xem câu trả lời ngắn gọn, rồi theo liên kết bằng chứng để tìm hiểu phương pháp, phép đo và giới hạn. Đây là những lối tiếp cận nghiên cứu, không phải các bảo đảm phổ quát.

1. Làm thế nào mô hình sinh có thể sửa đổi mã mà không viết lại toàn bộ hàm? Trước khi sinh, hãy xác định ranh giới có thể chỉnh sửa; bảo toàn hoặc tái sử dụng mã nguồn bên ngoài ranh giới đó, chỉ sinh các thay đổi ứng viên và loại bỏ đầu ra không hoàn thành tác vụ hoặc làm biến đổi vùng được bảo vệ. Khóa biến tiềm ẩn phân cấp là một giao diện điều khiển thực nghiệm, nhưng không bảo đảm các khoảng mã nguồn hoàn toàn giống nhau. [So sánh các giao diện điều khiển chỉnh sửa theo vùng](https://aogavrilov.com/vi/projects/discrete-latent-generation/#control-surface) .
2. Bằng chứng nào cho thấy một chỉnh sửa mã có tính cục bộ chứ không chỉ hợp lệ về cú pháp? Đo phần sai khác bên ngoài vùng được yêu cầu cùng với mức độ hoàn thành tác vụ, thay đổi trong vùng có thể chỉnh sửa, các bất biến cấu trúc, kiểm thử hoặc kiểm tra tĩnh và độ biến thiên qua nhiều lần chạy. Riêng tỷ lệ phân tích cú pháp chỉ xác nhận tính hợp lệ về mặt cú pháp. [Xem lại danh mục kiểm tra bằng chứng về tính cục bộ](https://aogavrilov.com/vi/projects/discrete-latent-generation/#measurement) .
3. Nên cân bằng tính cục bộ của chỉnh sửa mã với tính đa dạng khi sinh như thế nào? Báo cáo độ ổn định của vùng được bảo vệ cùng với mức độ tự do trong vùng có thể chỉnh sửa và tính độc nhất của các phương án. Sao chép đầu vào có thể tối đa hóa độ ổn định nhưng không tạo ra tiến triển nào cho tác vụ; viết lại không hạn chế có thể tối đa hóa mức thay đổi nhưng phá hủy tính cục bộ. [Xem bằng chứng có giới hạn về độ ổn định và mức tự do](https://aogavrilov.com/vi/projects/discrete-latent-generation/#evidence) .
4. Chỉnh sửa mã cục bộ, sinh có ràng buộc và sửa chữa chương trình khác nhau như thế nào? Chỉnh sửa cục bộ nhấn mạnh những gì phải giữ nguyên; sinh có ràng buộc cưỡng chế một thuộc tính hình thức của đầu ra, chẳng hạn tính thuộc về một ngữ pháp; còn sửa chữa chương trình đòi hỏi thay đổi phải đáp ứng đặc tả lỗi hoặc nhiệm vụ. Chỉ riêng cú pháp không chứng minh được tính tương đương ngữ nghĩa, tính đúng đắn chức năng, mức độ hoàn thành nhiệm vụ hay tính cục bộ. [So sánh ba mục tiêu](https://aogavrilov.com/vi/projects/discrete-latent-generation/#comparison) .
5. Làm thế nào để sinh lại các phần được chọn của một hàm Python trong khi phần còn lại vẫn ổn định? Trước khi sinh, hãy xác định vùng được bảo vệ và vùng có thể chỉnh sửa; chỉ sửa biểu diễn có thể chỉnh sửa, tiến hành giải mã và loại bỏ ứng viên làm thay đổi mã được bảo vệ hoặc không đạt yêu cầu về cú pháp, kiểm thử, kiểm tra tĩnh hay bất biến riêng của tác vụ. Thực nghiệm tiềm ẩn phân cấp được báo cáo đo độ ổn định theo xác suất trên các hàm dài 64 token; thực nghiệm này không bảo đảm khoảng mã hoặc hành vi được giữ nguyên. [Kiểm tra quy trình sinh lại có chọn lọc](https://aogavrilov.com/vi/projects/discrete-latent-generation/#workflow) .
6. Chiến lược điều khiển nào phù hợp với tái cấu trúc bảo toàn hành vi có AI hỗ trợ? Dùng mô hình để nhận diện hoặc đề xuất một phép biến đổi, sau đó, nếu có thể, thực thi bằng công cụ tái cấu trúc đáng tin cậy và xác minh quá trình biên dịch, kiểm thử, kiểm tra tĩnh cùng phép tái cấu trúc dự kiến. Một bản vá được sinh ra trông có vẻ hợp lý chưa phải là bằng chứng đầy đủ. [Mở hàng quyết định tái cấu trúc](https://aogavrilov.com/vi/projects/discrete-latent-generation/#control-surface) .
7. Điều gì khiến quá trình sinh mã trở nên dự đoán được, thay vì chỉ có thể điều khiển? Xác lập một hợp đồng bảo toàn có thể quan sát cùng các bước kiểm tra chấp nhận trước khi chọn bộ sinh. Khả năng dự đoán phụ thuộc vào những gì vẫn ổn định sau khi giải mã và kiểm chứng, chứ không chỉ vào việc prompt, mặt nạ, ngữ pháp hay mã ẩn có được cố định hay không. [Xác định hợp đồng bảo toàn](https://aogavrilov.com/vi/projects/discrete-latent-generation/#core-idea) .
8. Trong thí nghiệm văn bản được báo cáo, khuếch tán có che mặt nạ trong không gian mã và trong không gian token khác nhau ra sao? Với cùng một bộ chấm điểm bên ngoài, MDLM trong không gian mã đạt perplexity trung vị 26.55, so với 38.42 của đường cơ sở trong không gian token, tức giảm 30.9%. Tuy nhiên, perplexity trung vị của bản tái dựng của codec đã là 27.36, vì vậy kết quả phải được diễn giải cùng với nút thắt tái dựng. [Kiểm tra các số liệu theo từng giai đoạn đã được báo cáo](https://aogavrilov.com/vi/projects/codec-bottleneck-diagnosis/#code-space-vs-token-space) .
9. Nên so sánh khuếch tán có che mặt nạ trong không gian mã và không gian token như thế nào khi codec gây mất mát? Dùng cùng các mẫu dành riêng để đánh giá và cùng bộ chấm điểm văn bản đã giải mã cho văn bản gốc, bản tái dựng của codec, đầu ra trong không gian token và đầu ra trong không gian mã. Hãy báo cáo riêng chênh lệch tái dựng, vì ngay cả một bộ sinh trong không gian tiềm ẩn mạnh hơn cũng không thể khôi phục thông tin đã bị codec loại bỏ. [So sánh các giai đoạn bằng cùng một bộ chấm điểm](https://aogavrilov.com/vi/projects/codec-bottleneck-diagnosis/#code-space-vs-token-space) .
10. Làm thế nào để chẩn đoán suy giảm chất lượng trong mô hình sinh văn bản hai giai đoạn? Với cùng một bộ đánh giá văn bản đã giải mã không thay đổi, hãy đo khoảng cách từ bản gốc đến bản tái dựng trước khoảng cách từ bản tái dựng đến kết quả sinh. Cách này tách trần chất lượng do codec áp đặt khỏi phần suy giảm bổ sung do quá trình sinh tiềm ẩn gây ra. [Thực hiện quy trình chẩn đoán qua bốn điểm kiểm tra](https://aogavrilov.com/vi/projects/codec-bottleneck-diagnosis/#workflow) .
11. Khi nào các chỉ số tốt hơn trong không gian tiềm ẩn vẫn không cải thiện được đầu ra đã giải mã? Một chỉ báo thay thế trong không gian tiềm ẩn có thể cải thiện mà không phản ánh thuộc tính hạ nguồn cần quan tâm. Hãy kiểm thử khả năng chuyển giao bằng cách giải mã các đầu ra tương ứng và đánh giá chúng bằng cùng các thước đo cuối; nếu không, hình học hoặc mức sử dụng bảng mã chỉ là bằng chứng chẩn đoán, không phải mức cải thiện chất lượng văn bản. [Sử dụng phép chẩn đoán khả năng chuyển giao của đại lượng đại diện](https://aogavrilov.com/vi/projects/codec-bottleneck-diagnosis/#decision-table) .

## Hai lát cắt bằng chứng có giới hạn

Các con số này cho biết những gì đã được đo; chúng không phải bảo đảm phổ quát về mô hình.

### Chẩn đoán quá trình nén

Trong một cấu hình TinyStories nén từ 64 xuống 16, perplexity trung vị tăng từ **15.17** đối với văn bản nguồn thành **27.36** sau tái dựng. MDLM trong không gian mã đạt **26.55** so với **38.42** đối với đường cơ sở trong không gian token khi dùng cùng bộ chấm điểm ngoài.

### Khả năng điều khiển chỉnh sửa có thể kiểm tra

Trong một cấu hình hàm Python gồm 64 token, việc khóa bốn mã cấp cao nhất đã nâng tỷ lệ phân tích cú pháp từ **0.453** đến **0.591** , trong khi các vị trí không khóa thay đổi ở mức **0.936** và các mẫu có điều kiện vẫn đạt **0.998** duy nhất.

## Những điều bản đồ này không khẳng định

Các thí nghiệm đã công bố không xác lập khả năng bảo toàn AST chính xác, tương đương ngữ nghĩa, tính đúng đắn chức năng, sửa chữa ở quy mô kho mã hay một thứ tự phổ quát giữa nút thắt codec và nút thắt bộ sinh. Các hướng dẫn chuyển hóa bằng chứng có giới hạn thành quy trình chẩn đoán có thể tái sử dụng; mỗi hệ thống mới vẫn cần được xác thực riêng ở đầu ra đã giải mã và ở cấp hành vi.