Hầu hết trợ lý AI đều là kiểu "dùng xong là quên". Hôm nay sửa một thói quen, ngày mai nó lại mắc cùng lỗi; tuần trước dạy nó quy trình riêng của nhóm bạn, tuần này nó hành xử như chưa từng nghe đến. Mọi cuộc trò chuyện đều bắt đầu từ con số không — và dù mô hình thông minh đến đâu, nó vẫn là một người thông minh bị mất trí nhớ.
Orkas theo đuổi một hướng khác: để tác tử học từ việc sử dụng hằng ngày của chính nó, chắt lọc những kinh nghiệm lặp lại để lần sau có thể tự áp dụng. Nói đơn giản — càng dùng, nó càng hữu ích, và sự "hữu ích" đó phát triển theo hướng bạn, sở thích của bạn, lĩnh vực của bạn, thay vì thứ nhà cung cấp mô hình đặt sẵn cho tất cả mọi người.
Bài viết này giải thích cách xây dựng cơ chế đó. Nó không đơn giản là "cho mô hình nhớ cuộc trò chuyện" — phía sau là cả một vòng lặp: tự quan sát → quyết định có cần tự nhìn lại không → thực sự tự nhìn lại → ghi kết luận thành thứ có thể tái sử dụng → dùng lại lần sau. Chúng ta sẽ đi qua từng phần.
Điều quan trọng nhất cần nói trước: mọi thứ bên dưới — toàn bộ việc "quan sát", "ghi lại" và "tự nhìn lại" — đều diễn ra hoàn toàn trên thiết bị của bạn. Dữ liệu phiên chạy, kỹ năng, hiểu biết của tác tử về chính nó — tất cả đều nằm cục bộ dưới dạng tệp thông thường. Không dữ liệu nào được tải lên máy chủ của Orkas, và không dữ liệu nào được dùng để phân tích chéo người dùng hay huấn luyện mô hình. "Tự tiến hóa" nghĩa là một chương trình đọc bản ghi chạy của chính mình ngay trên máy và tự cải thiện ngay trên máy — không phải thu thập dữ liệu của bạn. Kinh nghiệm này không bao giờ rời khỏi máy, và chỉ phục vụ bạn, trên đúng chiếc máy này.
Toàn bộ vòng lặp
sử dụng thực tế, lặp đi lặp lại
│ ghi cục bộ: đã gọi công cụ nào, có lỗi không, có bị sửa không
▼
tín hiệu tích lũy
│ trích xuất tín hiệu ngay từ cuộc trò chuyện, tất cả được giữ trên thiết bị
▼
quyết định có cần tự nhìn lại không
│ chấm điểm có trọng số trên các tín hiệu, chỉ kích hoạt khi vượt ngưỡng; trục trặc mạng không tính
▼
tự nhìn lại ở chế độ nền
│ không phải mỗi lượt — mà theo định kỳ, chọn các tác tử đủ điều kiện
▼
chắt lọc thành hai thứ
│ ① "kỹ năng" tái sử dụng được ② "hiểu biết" về chính mình
▼
tự động đưa vào lượt tiếp theo
└──────────► quay về đầu, tiếp tục vòng lặpMỗi bước trong vòng lặp này đều có những điểm tinh tế. Hai chỗ dễ làm sai nhất chính là hai bước thoạt nhìn có vẻ đơn giản nhất: khi nào nên tự nhìn lại, và khi đã làm thì nên ghi lại gì. Hãy bắt đầu từ đầu.
Bước 1: tự quan sát với chi phí gần như bằng không
Muốn học từ kinh nghiệm, trước tiên cần có "kinh nghiệm" để xem xét. Cuối mỗi phiên chạy của tác tử, chương trình thống kê — ngay tại chỗ, trên máy — một vài dữ kiện nhẹ về phiên chạy: lượt này đã gọi khoảng bao nhiêu công cụ, có lỗi gì không, đó là lỗi tạm thời (như sự cố mạng) hay lỗi thực sự, và người dùng có sửa ngay lúc đó không. Chỉ vài bộ đếm và cờ trạng thái, tất cả được tính trên máy, không gọi mô hình nào và không gửi đi đâu.
Điều này quan trọng vì nó không tốn chi phí mô hình. Các con số được đếm trực tiếp từ bản ghi cuộc trò chuyện của lượt hiện tại; không cần gọi thêm mô hình chỉ để "tự phân tích". Nếu mỗi lượt đều cần thêm một lệnh gọi mô hình để tự xem xét, chi phí và độ trễ sẽ không thể chịu nổi, và cả cơ chế sẽ không bao giờ được đưa vào sản phẩm.
Phần "có bị sửa hay không" khá thú vị. Đây hoàn toàn là phán đoán theo quy tắc kinh nghiệm tại máy, được ước tính bằng cách đối chiếu một vài cách diễn đạt trong tin nhắn trên thiết bị của bạn — tiếng Trung như "不对" / "应该是" / "重新", tiếng Anh như wrong, actually, instead. Nó không đặt mục tiêu chính xác tuyệt đối — nó chỉ là một tín hiệu, không phải kết luận, và thỉnh thoảng nhận nhầm cũng không sao, vì sau đó nó được tính trọng số cùng các tín hiệu khác; không có quyết định nào chỉ dựa vào riêng nó.
Bước 2: khi nào việc tự nhìn lại thực sự đáng làm
Đây là phần trong toàn bộ cơ chế mà tôi nghĩ thể hiện rõ nhất sự khéo léo trong thiết kế.
Cách làm ngây thơ là "tự nhìn lại sau khi tích lũy N lần xảy ra". Nhưng cách đó quá thô: ba lần mạng hết thời gian chờ liên tiếp và ba lần người dùng sửa liên tiếp rõ ràng không giống nhau, không nên được đối xử như nhau. Orkas sử dụng chấm điểm đa tín hiệu có trọng số: mỗi hiện tượng đáng chú ý là một tín hiệu mang trọng số; cộng trọng số của các tín hiệu được kích hoạt trong lượt này, và chỉ tự nhìn lại nếu tổng vượt ngưỡng (mặc định là 0.7).
Các tín hiệu chính đại khái như sau:
| Tín hiệu | Trọng số | Điều kiện kích hoạt |
|---|---|---|
| Người dùng sửa | 0.9 | Phát hiện người dùng sửa trong lượt này |
| Kỹ năng không hiệu quả | 0.85 | Đã nạp kỹ năng nhưng lượt vẫn gặp lỗi |
| Khắc phục được lỗi | 0.8 | Có lỗi nhưng cuối cùng đã khắc phục được |
| Gặp điểm yếu đã biết | 0.7 | Nhiệm vụ chạm vào điểm yếu đã ghi trong phần tự đánh giá |
| Độ phức tạp của nhiệm vụ | 0.5 | Số lần gọi công cụ vượt một mức nhất định |
Ví dụ: một lượt vừa có người dùng sửa (0.9), vừa có độ phức tạp nhất định (0.5), tổng là 1.4, vượt xa 0.7, nên sẽ tự nhìn lại; một lượt chỉ hơi phức tạp (0.5) thì chưa đủ và được bỏ qua. Cách đặt trọng số cũng thể hiện một phán đoán — lời sửa trực tiếp từ người dùng nhận trọng số cao nhất, 0.9, vì đó là phản hồi có tỷ lệ tín hiệu trên nhiễu cao nhất: người dùng đã nói rõ bạn sai, nên rất có thể điều đó đáng được ghi lại.
Một ngoại lệ then chốt
Trong toàn bộ logic chấm điểm, có một quy tắc mà tôi coi là ranh giới quyết định cơ chế này có "học đúng điều" hay không: lỗi tạm thời không bao giờ được tính.
Mạng hết thời gian chờ, mất kết nối, giới hạn tần suất — đây là vấn đề của môi trường, không phải thiếu sót trong năng lực của tác tử. Nếu không loại chúng ra, điều tệ hại sẽ xảy ra: một công cụ lỗi vì trục trặc mạng ngẫu nhiên, rồi cơ chế tự nhìn lại ghi rằng "công cụ này không đáng tin, hãy dùng ít đi" — hoặc thậm chí sửa hỏng hay xóa một kỹ năng hoàn toàn tốt. Từ đó, tác tử đã học một bài học sai, và sai lầm đó cứ đeo bám nó.
Vì thế, các tín hiệu "khắc phục được lỗi", "kỹ năng không hiệu quả" và "gặp điểm yếu đã biết" đều chủ động loại trừ lỗi thuần túy tạm thời. Lời nhắc tự nhìn lại cũng nhắc lại điều này: lỗi thuộc nhóm mạng là do môi trường, đừng ghi thành điểm yếu, đừng động vào các kỹ năng liên quan. Điều một hệ thống tự cải thiện nên sợ nhất không phải học chậm — mà là học sai hướng. Ngoại lệ này bảo vệ chính xác khỏi điều đó.
Bước 3: tự nhìn lại chạy ở chế độ nền, không chen ngang trước mặt bạn
Một cái bẫy dễ mắc: ngay khi phát hiện "đến lúc tự nhìn lại", dừng lại và làm ngay tại chỗ. Điều đó khiến tác tử có vẻ thỉnh thoảng bị khựng, đi đâu đó để "suy ngẫm cuộc đời" — một trải nghiệm tệ.
Orkas chuyển việc tự nhìn lại xuống chế độ nền, theo nhịp cố định. Các quy tắc lập lịch, đại khái là:
- Bắt đầu một chu kỳ tự nhìn lại sau mỗi khoảng thời gian nhất định (chẳng hạn khoảng hơn chục giờ).
- Áp dụng thời gian nghỉ tối thiểu giữa hai lần tự nhìn lại của cùng một tác tử (vài giờ), để không chạy quá thường xuyên.
- Nhưng nếu đã quá lâu chưa tự nhìn lại (chẳng hạn hơn một tuần), buộc thực hiện một lần để không kéo dài vô hạn.
- Giới hạn số tác tử được chọn trong mỗi chu kỳ, để không dàn trải quá nhiều cùng lúc.
Có một thiết kế nhỏ mà tôi thích, gọi là cổng kiểm tra thay đổi: khi chu kỳ bắt đầu, trước tiên kiểm tra xem tác tử này có gì mới kể từ lần tự nhìn lại trước không — tín hiệu mới, bản ghi cuộc trò chuyện được cập nhật. Nếu hoàn toàn không có thay đổi, bỏ qua lần này để không lãng phí một lần tự nhìn lại có tốn chi phí mô hình. Đơn giản, nhưng thực tế tiết kiệm rất nhiều.
Bước 4: việc tự nhìn lại thực sự diễn ra thế nào
Khi thực sự đến lúc tự nhìn lại, quy trình là: trước tiên sắp xếp hoạt động gần đây thành một "gói", rồi ghép với lời nhắc được viết cẩn thận và giao cho mô hình đọc, tổng hợp.
Gói này có giới hạn: lấy tối đa một số ít cuộc trò chuyện gần đây, thêm vài nhóm sự kiện hệ thống, xen kẽ theo trình tự thời gian, và giữ tổng dưới một giới hạn token (chẳng hạn hơn mười nghìn). Không phải nhét toàn bộ lịch sử vào — vừa không đủ chỗ, vừa có tỷ lệ tín hiệu trên nhiễu thấp.
Phần thực sự cần chăm chút là lời nhắc. Nó yêu cầu mô hình tạo ra không phải "mô tả" mà là mệnh lệnh có thể thực thi. Khác biệt trông nhỏ nhưng có ý nghĩa rất lớn. Hãy so sánh:
✗ "Đầu ra của tác tử đôi khi quá dài dòng; hãy lưu ý."
✓ "Khi trả lời câu hỏi về văn phòng quản lý tài sản gia đình, không bao giờ vượt quá 5 gạch đầu dòng."
✗ "Người dùng có vẻ thích câu trả lời ngắn gọn."
✓ "Khi trả lời trong bối cảnh văn phòng quản lý tài sản gia đình, luôn đưa kết luận chính trước, rồi mới nêu lập luận."
Lời nhắc chủ động hướng mô hình đến cấu trúc "không bao giờ / luôn luôn / khi-thì" với điều kiện kích hoạt cụ thể. Lý do rất thực tế: ghi chú "lưu ý trả lời ngắn gọn" không cho tác tử hành động cụ thể nào trong lần đọc tới, còn "không bao giờ vượt quá 5 gạch đầu dòng" thì có thể làm theo ngay. Muốn tự cải thiện hữu ích, điều chắt lọc được phải là chỉ dẫn áp dụng được — không phải một lời sáo rỗng đúng đắn.
Sau khi tự nhìn lại, mô hình có thể làm vài việc: tạo hoặc sửa một kỹ năng, cập nhật hiểu biết về chính mình, hoặc — nếu thực sự không có gì đáng ghi lại trong khoảng này — chỉ nói "không có gì để lưu". Cho phép nó không làm gì cũng là một lựa chọn thiết kế quan trọng: đừng ép phải có kết quả học tập, kẻo tích lũy cả đống nhiễu vô dụng.
Chắt lọc thành hai thứ
Kết quả tự nhìn lại được đưa vào hai nơi.
Một là kỹ năng. Mỗi kỹ năng là một tài liệu Markdown có siêu dữ liệu — một khối frontmatter ghi tên, mô tả, thời gian tạo và cập nhật, số lần đã chỉnh sửa, lần dùng gần nhất — tiếp theo là các bước hoặc điểm chính thực tế:
---
name: "Weekly Report Export"
description: "Compile this week's data into the standard weekly-report format"
createdAt: "2025-01-01T00:00:00Z"
updatedAt: "2025-01-08T00:00:00Z"
patchCount: 2
lastUsedAt: "2025-01-09T10:00:00Z"
---
## Steps
1. ...
2. ...Lưu kỹ năng dưới dạng tệp là một lựa chọn thực dụng: con người có thể đọc và sửa trực tiếp — không bị khóa trong một cơ sở dữ liệu khó hiểu nào đó.
Thứ còn lại là hiểu biết về chính mình. Phần này giống một bản ghi nhớ tác tử tự viết cho mình hơn, gồm hai phần: một phần ghi "mình giỏi gì và hay vấp ở đâu", phần kia ghi "những cách làm mình đã đúc kết cho người dùng này và lĩnh vực này". Cả hai đều có giới hạn độ dài, buộc phải súc tích — không phải càng dài càng tốt, mà càng đúng càng tốt. Khi cuộc trò chuyện tiếp theo bắt đầu, nội dung này được đưa vào lời nhắc hệ thống, để tác tử bước vào với "hiểu biết về chính mình".
Kỹ năng không chỉ được ghi rồi để đó
Nếu chỉ tạo kỹ năng, theo thời gian bạn sẽ tích lũy một bãi phế liệu. Vì thế kỹ năng có vòng đời đầy đủ.
Ngoài tạo mới, thao tác phổ biến hơn thực ra là chỉnh sửa từng phần: thay đổi một đoạn nhỏ trong kỹ năng hiện có thay vì bỏ đi và viết lại. Mỗi lần chỉnh sửa tăng bộ đếm và làm mới thời gian cập nhật. Điều này giúp kỹ năng lớn dần cùng kinh nghiệm, thay vì bị viết lại toàn bộ ở mỗi lượt.
Số lượng cũng có giới hạn. Tổng số kỹ năng bị giới hạn (chẳng hạn 200); khi đã đầy, thêm kỹ năng mới sẽ loại một kỹ năng cũ theo LRU (lâu không được dùng nhất) để nhường chỗ. Việc loại bỏ có thứ tự ưu tiên: loại trước những kỹ năng chưa từng được dùng kể từ khi tạo — một kỹ năng chưa bao giờ được đọc có lẽ ngay từ đầu đã không được chắt lọc đúng, và nên nhường chỗ.
Mỗi lần tác tử đọc một kỹ năng, "thời gian dùng gần nhất" được cập nhật. Dấu thời gian này vừa phục vụ quyết định loại bỏ của LRU, vừa giúp cơ chế cục bộ biết kỹ năng nào thực sự đang được dùng và kỹ năng nào chỉ chiếm chỗ.
Làm sao biết một kỹ năng có thực sự hữu ích
Đây là bước mà nhiều hệ thống "tự học" lười biếng bỏ qua: nó đã học được gì đó — nhưng thứ đó có tốt không? Orkas biến câu hỏi này thành vài chỉ số, ngay trên máy. Những chỉ số này được tính để cơ chế tiến hóa trên máy tự sử dụng — quyết định kỹ năng nào cần sửa hoặc xóa — và cũng không bao giờ rời khỏi máy.
Cơ chế như sau: đầu mỗi lượt, các kỹ năng có sẵn xuất hiện trong mục lục của lời nhắc hệ thống — đó là một "lần hiển thị"; nếu tác tử thực sự đọc một kỹ năng trong lượt đó, đó là một "lần gọi dùng". So sánh hai con số sẽ có chỉ số đầu tiên —
- Tỷ lệ gọi dùng = số lần gọi dùng / số lần hiển thị. Một kỹ năng nằm đó ngày này qua ngày khác mà không ai dùng có tỷ lệ gọi dùng thấp, nghĩa là nó vô dụng hoặc được mô tả theo cách không ai biết khi nào nên dùng.
- Tỷ lệ chỉnh sửa sau khi dùng = tỷ lệ những lần kỹ năng được gọi dùng nhưng sau đó người dùng sửa kết quả bằng tay. Cao nghĩa là kết quả kỹ năng tạo ra chưa thật sự hợp ý người dùng.
- Tỷ lệ không hiệu quả = tỷ lệ những lần kỹ năng được gọi dùng nhưng lượt kết thúc bằng lỗi không tạm thời. Cao cho thấy bản thân kỹ năng có thể có vấn đề.
Ở đây bạn lại thấy dấu ấn của ngoại lệ đó: khi tính tỷ lệ không hiệu quả, lỗi tạm thời không được tính, và những lượt người dùng chủ động dừng giữa chừng cũng vậy — không thể đánh dấu xấu một kỹ năng hoàn toàn tốt chỉ vì một lần trục trặc mạng.
Với vài con số này, kỹ năng chuyển từ "tích lũy trong hộp đen" thành "thứ có thể đánh giá và tối ưu". Việc sửa hay xóa kỹ năng nào không còn là quyết định theo cảm tính.
Khép kín vòng lặp
Nối những phần trên lại, một chu kỳ hoàn chỉnh diễn ra như sau:
Tác tử xử lý các nhiệm vụ thực tế, ghi dữ liệu phiên chạy cục bộ và đánh dấu tín hiệu ngay trong quá trình làm. Khi đến chu kỳ tự nhìn lại ở chế độ nền, hệ thống chọn các tác tử có thay đổi mới và đã hết thời gian nghỉ, gom hoạt động gần đây của từng tác tử thành một gói, rồi để mô hình xem xét đối chiếu với hiểu biết hiện tại về chính mình — gộp những gì nên gộp, loại bỏ những gì nên loại bỏ, chắt lọc những gì nên chắt lọc thành kỹ năng mới. Đầu ra của việc xem xét trở thành kỹ năng và hiểu biết về bản thân. Ở cuộc trò chuyện tiếp theo, các kỹ năng được đưa vào mục lục lời nhắc, hiểu biết về bản thân được đưa vào lời nhắc hệ thống, và tác tử trở lại mang theo những gì đã học từ vòng trước. Rồi vòng này tạo ra chỉ số và tín hiệu mới, được đưa ngược về đầu.
Vòng lặp tiếp diễn, hết vòng này đến vòng khác. Không phải vòng nào cũng mang lại bước tiến ngoạn mục, nhưng hướng đi chỉ có một: hiểu bạn hơn và lặp lại ít lỗi cũ hơn.
Một vài sự đánh đổi đáng nêu rõ
Nhìn lại, có một vài quyết định then chốt trong cơ chế này.
Việc tự quan sát phải ít tốn kém. Hệ thống tự quan sát bằng các chỉ số không phát sinh chi phí mô hình; việc tự đánh giá thực sự tốn kém được chuyển xuống nền, chạy không thường xuyên và phải vượt qua bước kiểm tra thay đổi trước. Kiểm soát thật chặt phần "tốn kém" thì toàn bộ cơ chế mới thực sự vận hành được.
Thà không học còn hơn học sai. Miễn trừ lỗi tạm thời, cho phép việc tự đánh giá "không lưu gì", viết chỉ dẫn có thể thực thi thay vì mô tả mơ hồ — tất cả đều hướng đến cùng một nhận định: với một hệ thống tự cải thiện, học sai hướng nguy hiểm hơn nhiều so với học chậm.
Những gì học được phải hiển thị rõ, chỉnh sửa được và nằm trong tay bạn. Kỹ năng là các tệp văn bản thuần, sự tự nhận thức là một bản ghi nhớ văn bản thuần, hiệu quả kỹ năng có thể kiểm tra qua các chỉ số — và tất cả những tệp này đều nằm trên máy của bạn, không phải trên đám mây. Không có hộp đen nào cả; con người có thể mở ra và điều chỉnh bất cứ lúc nào.
Đặt phanh cho việc học. Giới hạn số lượng, loại bỏ theo LRU, giới hạn độ dài — thiếu những điều này, "học liên tục" sớm muộn cũng thành "phình to liên tục". Quên, loại bỏ và cắt tỉa quan trọng không kém ghi nhớ.
Lời kết
Về bản chất, khả năng tự tiến hóa của Orkas là bổ sung một vòng lặp chậm cho tác tử: vòng lặp nhanh là phản hồi tức thì trong mỗi cuộc trò chuyện; vòng lặp chậm là định kỳ nhìn lại và chắt lọc kinh nghiệm thành thứ có thể dùng lần sau. Phần khó không phải là "khiến mô hình ghi nhớ" — mà là những phán đoán kỹ thuật dễ bị bỏ qua: làm sao biết kinh nghiệm nào đáng ghi lại, làm sao không bị một thất bại ngẫu nhiên làm chệch hướng, làm sao biến điều học được thành thứ thực sự có thể thực thi, và làm sao cắt tỉa trước khi nó phình to.
Kết hợp lại, những phán đoán đó biến "càng dùng càng hữu ích" từ một câu tiếp thị thành một cơ chế thực sự vận hành. Một trợ lý học từ bạn — và không học những điều sai — có lẽ gần với điều đa số mọi người thực sự muốn hơn một trợ lý chỉ thông minh hơn.