Tác giả: @hi_im_isaac_, @learnwdaniel, @gaozenghao
ghi chú: phiên bản tương tác của blog kỹ thuật đầy đủ có sẵn tại: https://www.cerebras.ai/blog/how-we-built-our-knowledge-base
Nhân viên đặt hơn 15.000 câu hỏi mỗi ngày vào cơ sở kiến thức nội bộ của chúng tôi. Nó đã trở thành một trong những công cụ nội bộ được sử dụng rộng rãi nhất tại công ty kể từ khi ra mắt 3 tháng trước. Được sử dụng bởi con người, các quy trình tự động hóa và các tác nhân AI.
Tại Cerebras, các nhóm của chúng tôi làm việc trên các lĩnh vực vận hành trung tâm dữ liệu, thiết kế chip, phần cứng, đào tạo, suy luận, nền tảng đám mây, v.v. Với hàng trăm nhân viên mới gia nhập mỗi năm, các kênh giao tiếp của chúng tôi đã bị tràn ngập bởi cùng một loại câu hỏi:
- "Tôi có thể tìm thấy X ở đâu?"
- "Ai là chuyên gia về Y?"
- "Z là gì?"
Chúng tôi đã xây dựng Cerebras Knowledge để giúp mọi người kết nối mọi người và hệ thống với thông tin hữu ích.
Gặp gỡ dữ liệu tại nơi nó tồn tại
Việc tìm kiếm thông tin trong một tổ chức là khó khăn. Dữ liệu nằm rải rác trên nhiều công cụ, và cứ mỗi quý hoặc lâu hơn, ai đó lại đề xuất cùng một giải pháp tuyệt vời: hãy ghi lại mọi thứ vào một nền tảng duy nhất để tất cả thông tin đều ở một nơi. Giấc mơ về một nguồn sự thật duy nhất, tất nhiên, hiếm khi hoạt động trong thực tế.
Thông tin được tạo ra ở bất cứ nơi nào thuận tiện và công thái học: các chỉnh sửa đề xuất trong tài liệu, các chuỗi tin nhắn trong Slack, tham chiếu mã trong GitHub, và siêu dữ liệu trạng thái trong Jira. Các nền tảng này được thiết kế riêng cho các lĩnh vực cụ thể của chúng, được tối ưu hóa qua nhiều năm phát triển sản phẩm và phân tích. Thảo luận về một pull request trong Google Docs sẽ là một trải nghiệm tồi tệ.
Vì vậy, chúng tôi đã thiết kế một hệ thống yêu cầu thay đổi tối thiểu đối với hành vi hiện tại. Về phía thu thập dữ liệu, điều này có nghĩa là trích xuất dữ liệu từ mỗi nền tảng một cách trực tiếp.
Giải phẫu của một cơ sở kiến thức
Cơ sở kiến thức của chúng tôi cung cấp ba điều:
- Một nền tảng để thu thập và lưu trữ dữ liệu nội bộ.
- Một nền tảng để truy vấn dữ liệu đó.
- Một lớp thực thi xác thực và phân quyền, với kiểm toán và phân tích.
Cốt lõi là một bảng Postgres duy nhất chứa các embeddings, tóm tắt thô và siêu dữ liệu từ nhiều nguồn. Hệ thống liên tục hấp thụ dữ liệu từ khắp công ty và duy trì một kho dữ liệu sẵn sàng cho truy vấn.
Chúng tôi muốn một giao diện dữ liệu đơn giản nhưng có thể hoạt động với hầu hết các dạng dữ liệu. Chúng tôi cũng muốn các nhà phát triển khác tại Cerebras có thể xây dựng các kết nối tùy chỉnh. Kết quả là một thiết kế có chủ đích đơn giản: mọi nguồn, từ chuỗi Slack đến netlists, đều đổ vào cùng một bảng embeddings, và bất kỳ thứ gì trong bảng đó đều có thể truy vấn ngay lập tức thông qua cùng một giao diện:
Mỗi nguồn dữ liệu xác định dữ liệu là gì, cách kết nối với nó và tần suất nên được tìm nạp. Mỗi hàng embedding kết quả tuân theo cùng một giao diện bất kể nó đến từ Slack, kho lưu trữ mã, hệ thống tài liệu hay cơ sở dữ liệu tùy chỉnh.
Cách chúng tôi xử lý các cuộc hội thoại Slack phi cấu trúc
Slack là nguồn dữ liệu quan trọng nhất mà chúng tôi cần thiết kế. Đây là nơi diễn ra các cuộc thảo luận kỹ thuật cập nhật nhất trên toàn công ty.
Ban đầu chúng tôi đã thử nghiệm xem liệu các embeddings đơn giản trên văn bản thô có hoạt động đủ tốt hay không. Chúng tôi nhanh chóng nhận ra rằng chỉ riêng tìm kiếm vector là không đủ để khớp tất cả dữ liệu liên quan.
Tin nhắn Slack đặt ra một số thách thức:
- Mật độ thông tin thay đổi rất lớn: "Ừ đúng rồi Mike" và một lời giải thích chi tiết về kernel đều là tin nhắn.
- Độ dài tin nhắn khác nhau và các tin nhắn ngắn hơn thường đánh bại các tin nhắn dài hơn, chi tiết hơn trong độ tương đồng cosine.
- Ý nghĩa của một tin nhắn thường phụ thuộc vào cuộc hội thoại xung quanh.
Chúng tôi cần một cách tiếp cận kết hợp. Chúng tôi đã xây dựng quy trình hấp thụ Slack để mọi luồng có thể được truy xuất thông qua nhiều kỹ thuật tìm kiếm cùng một lúc, trong đó mỗi kỹ thuật bù đắp cho điểm yếu của các kỹ thuật khác:
- Tìm kiếm toàn văn bắt các token chính xác mà embeddings làm mờ đi: chuỗi lỗi, tên cờ, tên máy chủ. Khi một kỹ sư dán một thông báo lỗi theo nghĩa đen, một kết hợp từ vựng chính xác hầu như luôn là bằng chứng tốt nhất và không có mức độ tương đồng ngữ nghĩa nào có thể vượt qua nó.
- Tìm kiếm embeddings bắt các diễn giải. Người hỏi "khôi phục bị treo sau khi tải manifest" và người trả lời "checkpoint bị kẹt trên NFS mount" có thể không bao giờ chia sẻ từ vựng. Độ tương tự vector là thứ kết nối một câu hỏi với một câu trả lời được viết bằng các từ khác nhau.(1)
- Tần suất tài liệu nghịch đảo tách biệt tín hiệu khỏi phần đệm. Một tin nhắn ngắn được xây dựng xung quanh các token hiếm, chẳng hạn như một cờ cấu hình mơ hồ, xứng đáng được xếp hạng. "Nghe hay đấy, cảm ơn!" nằm gần nhiều truy vấn trong không gian embedding nhưng đạt điểm gần như bằng không khi tính đến độ hiếm của thuật ngữ.
- Suy giảm theo thời gian mã hóa rằng các câu trả lời trên Slack sẽ hết hạn. Hai luồng có thể trả lời cùng một câu hỏi và luồng từ sáu tháng trước có thể mô tả cơ sở hạ tầng không còn tồn tại. Khi mức độ liên quan bằng nhau, luồng mới hơn sẽ thắng.
Không có bộ chấm điểm nào được tin cậy một mình. Mỗi kỹ thuật tạo ra chế độ xem xếp hạng riêng của cùng một kho ngữ liệu và các chế độ xem đó được hợp nhất tại thời điểm truy vấn (xem Reranking).
Chế độ Socket
Để thu thập dữ liệu theo thời gian thực, chúng tôi đã cài đặt một bot Slack vào không gian làm việc của mình và chạy nó ở Chế độ Socket. Slack đẩy mọi sự kiện tin nhắn đến chúng tôi qua một WebSocket liên tục, vì vậy chúng tôi nhận được các bản cập nhật theo thời gian thực mà không cần phải thăm dò Web API và vượt quá giới hạn tốc độ của nó.
Khi một sự kiện đến, chúng tôi ngay lập tức xác nhận nó, loại bỏ trùng lặp bằng cách sử dụng ID sự kiện ổn định và đánh dấu tin nhắn cho người tiêu dùng hấp thụ.
Người tiêu dùng hấp thụ không lưu một tin nhắn mới một cách riêng lẻ. Nó giải quyết luồng mà tin nhắn thuộc về và tìm nạp lại toàn bộ cuộc hội thoại, bao gồm cả tin nhắn cha và mọi phản hồi, từ Slack API. Sau đó, nó ghi toàn bộ luồng trở lại thành một hàng. Do đó, một phản hồi cho một luồng hiện có sẽ kéo lại tin nhắn cha và tất cả các tin nhắn chị em, vì vậy nội dung được lưu trữ, danh sách người tham gia và dấu thời gian hoạt động cuối cùng luôn phản ánh cuộc hội thoại đầy đủ.
Mỗi kênh Slack trong hệ thống của chúng tôi có nguồn dữ liệu riêng. Điều này cung cấp khả năng tinh chỉnh chi tiết cho độ tươi của dữ liệu. Ví dụ: một nhóm có thể chọn hấp thụ một kênh sự cố bận rộn thường xuyên hơn.
Luồng và tin nhắn
Văn bản Slack thô có thể tìm kiếm bằng từ khóa ngay khi nó đến vì chúng tôi duy trì một chỉ mục toàn văn bản Postgres (GIN) trên nội dung thô. Tuy nhiên, để cho phép tìm kiếm vector hữu ích, chúng tôi thực hiện một số xử lý bổ sung.(8)
Trong quá trình chưng cất, một LLM trích xuất dữ liệu có cấu trúc từ luồng đầy đủ:
- Một câu hỏi một dòng mà một kỹ sư thực sự sẽ tìm kiếm.
- Một bản tóm tắt ngắn.
- Giải pháp.
- Các hệ thống và tham chiếu mã được đề cập.
Chúng tôi nhúng các điểm dữ liệu này và ghi chúng vào bảng embeddings dùng chung. Bản ghi gốc không được nhúng trực tiếp. Trong các thử nghiệm của chúng tôi, độ chính xác đã tăng lên đáng kể khi luồng được chuẩn hóa thành một định dạng nhất quán.(7,9) Siêu dữ liệu bổ sung cũng cung cấp cho kết quả khớp ngữ nghĩa nhiều tín hiệu hữu ích hơn.
Bursting
Tại thời điểm này, tìm kiếm trên Slack đã tốt, nhưng chúng tôi liên tục gặp phải cùng một vấn đề: các tin nhắn quan trọng bên trong các luồng dài không phải lúc nào cũng được thể hiện trong bản tóm tắt cấp luồng.
Để tăng cường tín hiệu từ các tin nhắn riêng lẻ, chúng tôi sử dụng bursting. Một burst là một chuỗi các tin nhắn liên tiếp từ cùng một tác giả. Chúng tôi nhúng các burst riêng lẻ với chủ đề luồng được thêm vào như ngữ cảnh(2) bởi vì đôi khi câu trả lời nằm trong một tin nhắn lạc đề mà từ vựng của nó không bao giờ xuất hiện trong bản tóm tắt luồng. Các embedding burst làm cho tin nhắn đó có thể tìm thấy được một cách riêng lẻ.
Để ngăn dữ liệu có tín hiệu thấp đến cơ sở dữ liệu, mỗi burst được chấm điểm dựa trên sự kết hợp có trọng số của các tín hiệu và phải vượt qua một ngưỡng trước khi được nhúng:
- Nó chứa một token tương đối hiếm trong toàn bộ kho ngữ liệu, với IDF ít nhất là 4.0.
- Burst kết hợp có ít nhất 200 ký tự.
- Một hoặc nhiều tin nhắn trong burst có phản ứng, cung cấp một sự tăng cường xã hội.
Sau khi chưng cất, các burst đủ điều kiện được nhúng và lưu trữ trong bảng embeddings cùng với bản ghi cấp luồng.
Kho lưu trữ mã
Ban đầu chúng tôi đã tranh luận về việc liệu có cần thiết phải nhúng các kho lưu trữ mã hay không. Với sự gia tăng của Claude Code và các công cụ dòng lệnh khác, việc tạo embeddings mã có vẻ phản trực giác khi có vẻ như "grep là tất cả những gì bạn cần." Sau khi nói chuyện với những người khác trong ngành và đọc các phát hiện của Cursor về tìm kiếm ngữ nghĩa trong các cơ sở mã lớn, chúng tôi quyết định thử.
Chúng tôi có nhiều kho lưu trữ nội bộ, một số lớn hơn 40 GB. Mối quan tâm chính của chúng tôi là làm thế nào để giữ cho chúng luôn cập nhật một cách hiệu quả.
Sử dụng @cocoindex_io để duy trì các embeddings mã
Sau một số thử nghiệm, chúng tôi đã chọn CocoIndex, một framework nhúng tài liệu mã nguồn mở chuyên về vector hóa các cơ sở mã.
Đối với mỗi kho lưu trữ, chúng tôi chia mã bằng cách sử dụng các ranh giới regex dành riêng cho ngôn ngữ được sắp xếp từ thô đến mịn. Bộ chia cố gắng các ranh giới cấp cao hơn, chẳng hạn như các lớp, trước. Nếu một khối kết quả vẫn quá lớn, nó sẽ chuyển sang ranh giới phương thức và sau đó là các khối nhỏ hơn. Chúng tôi nhúng các khối kết quả và ghi các vector vào Postgres. Một tệp duy nhất có thể tạo ra nhiều embeddings ở các mức độ cụ thể khác nhau, chẳng hạn như bản ghi cấp tệp và cấp hàm.
CocoIndex theo dõi siêu dữ liệu đồng bộ hóa trong Postgres. Trên mỗi lần commit, nó nhúng lại và xuất lại chỉ các khối mã đã thay đổi thay vì tính toán lại toàn bộ kho lưu trữ. Điều này hoạt động đặc biệt tốt đối với chúng tôi vì trạng thái đồng bộ hóa và kho lưu trữ embeddings sống trong cùng một cơ sở dữ liệu.
Khi số lượng cơ sở mã tăng lên, chúng tôi đã chuyển việc đưa kho lưu trữ vào các tệp cấu hình mà các nhóm có thể tự gửi, bao gồm danh sách cho phép và danh sách chặn ở cấp đường dẫn tệp.
Các nguồn dữ liệu tùy chỉnh
Một số nhóm đã có cơ sở dữ liệu riêng của họ và không muốn chuyển dữ liệu sang Slack hoặc hệ thống tài liệu chỉ để tham gia vào cơ sở kiến thức. Họ muốn cùng một bề mặt truy vấn trên các bảng hiện có của họ.
Để hỗ trợ điều này, chúng tôi coi các nguồn tùy chỉnh như các tập lệnh plugin. Một nhóm mở một pull request với một module Python nhỏ biết cách đọc từ hệ thống của nó và phát ra các hàng có hình dạng giống như bảng embeddings của chúng tôi, cùng với một mục nhập nguồn dữ liệu phù hợp.
Miễn là tập lệnh ghi vào cơ sở dữ liệu dùng chung bằng cách sử dụng cùng một lược đồ như mọi hàng embedding khác, phần còn lại của ngăn xếp hoạt động không thay đổi. Dữ liệu trở nên có thể truy vấn được cùng với Slack, mã và tài liệu, mà không cần xử lý đặc biệt ở bất kỳ nơi nào khác trong hệ thống.
Lập kế hoạch và phân nhánh công cụ
Đối với mỗi truy vấn, trước tiên chúng tôi chạy một lượt lập kế hoạch ngắn trong đó một LLM quyết định công cụ và nguồn dữ liệu nào có khả năng quan trọng. Các công cụ chính:
- subsystem_index: tóm tắt LLM theo tệp.
- search: đường ống vector thống nhất trên Slack, wiki, mã và các nguồn được lập chỉ mục khác, được hợp nhất và xếp hạng lại nội bộ.
- search_slack: truy xuất Slack trực tiếp.
- search_code: ripgrep trên các kho lưu trữ nguồn.
- recent_prs: các pull request gần đây liên quan đến câu hỏi.
- who_knows: những người có chuyên môn đã được chứng minh về một chủ đề.
Bộ lập kế hoạch làm việc trên một mô tả nhỏ gọn về những gì chúng tôi đã lập chỉ mục: những dự án nào tồn tại, những nguồn nào có sẵn trong mỗi dự án và mỗi nguồn giỏi trả lời những gì. Với truy vấn của người dùng và phạm vi hoạt động, nó phát ra các lựa chọn công cụ mà bộ thực thi phân nhánh song song, chuẩn hóa thành một định dạng bằng chứng chung và chuyển đến một LLM tổng hợp cuối cùng.(4)
Xếp hạng lại
Một tài liệu có thể xuất hiện gần đầu chỉ đơn giản vì nó chia sẻ từ vựng với truy vấn trong khi trả lời một câu hỏi khác. Trước khi xếp hạng lại, chúng tôi kết hợp các danh sách kết quả không tương thích của các bộ truy xuất với hợp nhất thứ hạng tương hỗ (reciprocal rank fusion - RRF). Đối với mỗi tài liệu, chúng tôi thêm trọng số / (60 + thứ hạng) cho mỗi danh sách mà nó xuất hiện, với trọng số mặc định là 1.0 và hằng số làm mượt là 60.
Hằng số làm mượt làm cho sự đồng thuận quan trọng hơn một phiếu bầu mạnh duy nhất: một tài liệu xuất hiện gần đầu trong nhiều bộ truy xuất có thể đánh bại một tài liệu chỉ xếp thứ nhất trong một trong số chúng. Sau đó, chúng tôi hợp nhất các khối trùng lặp trở lại một nguồn, giới hạn số lượng kết quả mà mỗi tệp có thể đóng góp và kết thúc với một danh sách hai mươi kết quả đa dạng hơn.
Chúng tôi gửi truy vấn gốc và các ứng viên đó đến một mô hình xếp hạng lại nhỏ. Nó cho mỗi tài liệu điểm từ 0 đến 10 và chúng tôi giữ lại mười tài liệu hàng đầu.(6)
Khi thứ hạng đã được xác định, chúng tôi thêm ngữ cảnh trở lại cho những người chiến thắng. Ví dụ: nếu chúng tôi khớp một phần wiki, chúng tôi kéo vào hai phần lân cận để tiêu đề, điều kiện tiên quyết và lưu ý mà việc chia nhỏ đã tách ra không bị mất. Điều này mang lại cho người đọc một đoạn trích hoàn chỉnh thay vì một đoạn văn đơn độc thiếu bối cảnh quan trọng.
Vì vậy, đầu ra của tìm kiếm là một gói bằng chứng phong phú: các kết quả được hợp nhất từ các bộ truy xuất khác nhau, loại bỏ trùng lặp ở cấp nguồn, xếp hạng lại dựa trên câu hỏi thực tế và chỉ sau đó mới được mở rộng với ngữ cảnh xung quanh.
MCP
Trong tích hợp MCP, chúng tôi hiển thị các khối xây dựng truy xuất dưới dạng các công cụ trực tiếp thay vì ẩn chúng đằng sau một endpoint "trả lời câu hỏi này". Các công cụ này có chủ đích đơn giản và không có LLM càng nhiều càng tốt để khách hàng có thể truy vấn chúng một cách nhanh chóng và rẻ.(5)
Mỗi công cụ MCP tương ứng với một nguyên thủy truy xuất cơ bản, chẳng hạn như search_slack, search_code, search hoặc who_knows. Đầu vào và đầu ra của công cụ hẹp, có cấu trúc và ổn định, giúp chúng dễ dàng gọi từ bất kỳ khách hàng hoặc tác nhân nào mà không cần nhúng logic điều phối bổ sung vào bên trong công cụ.
Hầu hết các công cụ chạy một đường ống truy vấn, chẳng hạn như tìm kiếm vector, tìm kiếm từ vựng hoặc ripgrep, áp dụng các phương pháp phỏng đoán chấm điểm nhẹ và trả về các hàng bằng chứng thô.
Claude Code, hoặc bất kỳ tác nhân tương thích MCP nào, trở thành công cụ điều phối. Nó quyết định công cụ nào để gọi, theo thứ tự nào và cách lắp ráp các kết quả thành một câu trả lời cuối cùng hoặc chỉnh sửa mã. Bản thân lớp truy xuất không phụ thuộc vào các quyết định LLM đó để phục vụ các yêu cầu.
Giao diện Web
Trong giao diện web, các công cụ tương tự tồn tại, nhưng chúng được kết nối với một đường ống truy vấn hoàn chỉnh chạy từ đầu đến cuối cho mọi câu hỏi của người dùng. Tác nhân giao diện người dùng sở hữu các bước lập kế hoạch và thực thi.
- Bộ lập kế hoạch: Một lượt LLM nhẹ kiểm tra truy vấn và dự án đang hoạt động, sau đó chọn công cụ truy xuất nào để gọi, chẳng hạn như search, search_slack và subsystem_index.
- Bộ thực thi: Hệ thống phân nhánh các lệnh gọi công cụ đó song song, thu thập kết quả và chuẩn hóa chúng thành một lược đồ bằng chứng chung với điểm số, độ gần đây và gợi ý nguồn.
- Tổng hợp: Một lượt LLM cuối cùng lấy gói bằng chứng đã gõ và câu hỏi gốc, sau đó tạo ra câu trả lời được hiển thị trong giao diện người dùng, bao gồm trích dẫn, lưu ý và tổng hợp chéo nguồn.
Từ góc nhìn của người dùng, giao diện web chỉ đơn giản là "đặt câu hỏi và nhận câu trả lời." Bên dưới, nó chạy cùng một mẫu lập kế hoạch → thực thi → tổng hợp mà các khách hàng MCP có thể tái tạo một cách rõ ràng.
Tổ chức
Khi kho ngữ liệu phát triển, "tìm kiếm mọi thứ ở mọi nơi" nhanh chóng trở nên không hữu ích. Các kỹ sư trong nhóm trình biên dịch không muốn các sổ tay hướng dẫn cơ sở hạ tầng trong kết quả của họ, và ngược lại. Các dự án là cách chúng tôi làm cho tìm kiếm trở nên phù hợp theo mặc định.
Dự án và tìm kiếm phạm vi
Chúng tôi đã giới thiệu các dự án như là cách chính để tổ chức không gian làm việc mà một truy vấn chạy trên đó. Một dự án là một gói các nguồn dữ liệu được đặt tên: các kênh Slack cụ thể, kho lưu trữ mã, cơ sở dữ liệu nội bộ và không gian tài liệu liên quan đến một nhóm hoặc sáng kiến.
Các dự án có chủ đích nhẹ. Cùng một nguồn dữ liệu, chẳng hạn như một kênh sự cố dùng chung hoặc kho lưu trữ nền tảng trung tâm, có thể được tham chiếu bởi nhiều dự án thay vì bị trùng lặp.
Đăng ký và mặc định
Trong quá trình đăng ký, người dùng được nhắc chọn hoặc tạo một dự án mặc định phù hợp với cách họ làm việc, chẳng hạn như Cơ sở hạ tầng đào tạo ML, Trình biên dịch hoặc Vận hành trung tâm dữ liệu.
Dự án mặc định đó được lưu trữ trên hồ sơ người dùng và tự động giới hạn phạm vi truy vấn. Một kỹ sư mới nhận được các câu trả lời có tín hiệu cao mà không cần đầu tiên phải học những kênh Slack, kho lưu trữ hoặc không gian tài liệu nào là quan trọng.
Suy nghĩ cuối cùng
Cuối cùng, cơ sở kiến thức hoạt động vì nó gặp gỡ mọi người tại nơi thông tin đã tồn tại, thay vì ép buộc mọi thứ vào một hệ thống cứng nhắc. Bằng cách kết hợp các kỹ thuật tìm kiếm khác nhau, chúng tôi có thể đưa ra bằng chứng một cách nhanh chóng. Kết quả là một trải nghiệm tìm kiếm đủ linh hoạt cho dữ liệu công ty thực tế, nhưng đủ cấu trúc để vẫn hữu ích khi Cerebras tiếp tục phát triển.
Nếu bạn đọc đến đây và điều này thú vị với bạn, nhóm ai/growth đang tuyển dụng. Hãy liên hệ nếu bạn quan tâm @learnwdaniel
Tài liệu tham khảo
- Malkov và Yashunin, Tìm kiếm Láng giềng Gần đúng Hiệu quả và Mạnh mẽ sử dụng Đồ thị Thế giới Nhỏ Phân cấp Điều hướng, arXiv:1603.09320 / IEEE TPAMI 2018.
- Anthropic, Giới thiệu về Truy xuất Ngữ cảnh, 2024.
- Cormack, Clarke, và Büttcher, Kết hợp Xếp hạng Đối nghịch Vượt trội hơn Condorcet và Các Phương pháp Học Xếp hạng Cá nhân, SIGIR 2009.
- Li và cộng sự, Search-o1: Mô hình Suy luận Mở rộng Tăng cường Tìm kiếm Tác nhân, arXiv:2501.05366, 2025.
- Anthropic, Thực thi Mã với MCP, 2025.
- Liu và cộng sự, Lạc giữa: Cách Mô hình Ngôn ngữ Sử dụng Ngữ cảnh Dài, arXiv:2307.03172, 2023.
- Anthropic, Sử dụng Thẻ XML.
- Salesforce/Slack Engineering, Cách Slack AI Xử lý Hàng tỷ Tin nhắn, 2024.
- Improving Agents, Định dạng Dữ liệu Lồng nhau Tốt nhất, 2025.
- Cursor, Cải thiện Tác nhân với Tìm kiếm Ngữ nghĩa, 2025.
