Xuất hiện trong ChatGPT: năm thử nghiệm, không công thức

Hãy để chúng tôi thành thật từ đầu. Chúng tôi không thể nói cho bạn cách để xuất hiện trong ChatGPT, vì OpenAI chưa công bố cách thức hệ thống tìm kiếm của họ chọn nguồn, và câu trả lời của ChatGPT có thể thay đổi giữa các lần chạy.

Điều bạn có thể làm là quan sát. Tìm kiếm ChatGPT, ra mắt ngày 31 tháng 10 năm 2024, hiển thị các nguồn được liên kết, vì vậy mỗi câu trả lời đều để lại dấu vết. Perplexity và Claude với tìm kiếm web cũng hoạt động tương tự, cho phép bạn so sánh các công cụ trên cùng một câu lệnh.

Mỗi lần chạy là một mẫu dữ liệu. Không phải là phán quyết cuối cùng. Hãy sử dụng cùng một câu lệnh, một phiên đăng xuất nếu có thể, và một cột ghi ngày. Nếu không có kỷ luật đó, kết quả chỉ là những câu chuyện anecdote, dù bạn có thu thập bao nhiêu ảnh chụp màn hình đi nữa. Hãy giữ kích thước mẫu đủ nhỏ để hoàn thành, nhưng đủ lớn để có ý nghĩa. Hãy viết kế hoạch đó trên một trang giấy.

Đừng spam câu lệnh vào trợ lý để làm tăng bất kỳ con số nào, và đừng công bố ảnh chụp màn hình làm bằng chứng cho một xu hướng. Quy tắc này là bắt buộc. Một bảng tính gọn gàng sẽ thuyết phục nhiều người hơn một thư mục chứa hình ảnh.

Cách đọc kết quả trả về

Cách nhau một giờ, cùng một câu lệnh có thể trích dẫn các trang khác nhau. Hãy mong đợi nhiễu, và mong đợi văn bản câu trả lời thay đổi trong khi các nguồn vẫn giữ nguyên.

Các lần xuất hiện đơn lẻ chứng minh rất ít. Hãy đánh giá dựa trên tần suất. Nếu tên miền của bạn xuất hiện trong sáu trong tám lần chạy hàng tuần cho một câu hỏi, đó là một xu hướng đáng để ghi chú. Nếu nó chỉ xuất hiện một lần, đó chỉ là sự trùng hợp ngẫu nhiên có vẻ đẹp lòng bạn.

Google AI Overviews, tìm kiếm ChatGPT, Perplexity và Claude mỗi công cụ đều truy xuất theo cách riêng, vì vậy một chiến thắng ở công cụ này nói rất ít về công cụ khác. Hãy so sánh các công cụ riêng biệt. Từ điển thuật ngữ giải thích tại sao việc gắn kết (grounding) khác nhau giữa chúng.

Hãy lên kế hoạch thời gian trước khi bắt đầu. Thử nghiệm một mất một buổi chiều. Các thử nghiệm khác chủ yếu là chờ đợi: việc lập chỉ mục lại có thể mất vài ngày hoặc vài tuần, và không có gì trong quy trình này có thể được đẩy nhanh bằng cách trả tiền.

Tại sao cùng một câu lệnh lại bị trôi lệch

Trước khi ghi nhận một sự thay đổi vào nhật ký, hãy liệt kê những thứ đã thay đổi giữa các lần chạy. Hầu hết sự trôi lệch đều có nguyên nhân đơn giản nằm ở thiết lập hơn là ở công cụ tìm kiếm.

Cách diễn đạt và phiên làm việc

Những chỉnh sửa nhỏ trong câu lệnh có thể thay đổi các nguồn được trích dẫn. Một câu hỏi phụ, một từ đồng nghĩa hoặc một mệnh đề bổ sung có thể kéo vào các trang khác. Một phiên đăng nhập cũng có thể mang theo lịch sử mà một trình duyệt sạch sẽ không có.

Viết chính xác câu lệnh vào nhật ký, không phải bản diễn giải. Các bản diễn giải có vẻ vô hại cho đến khi bạn cố gắng so sánh hai tháng dữ liệu. Hãy nói cho đồng nghiệp biết bộ câu lệnh trước khi bắt đầu, để danh sách không thể được chỉnh sửa cho phù hợp với kết quả.

Thời gian trong ngày và thay đổi sản phẩm

Cùng một câu lệnh có thể trả về các nguồn khác nhau cách nhau vài giờ. Các mô hình, hệ thống truy xuất và đầu vào của chúng đều thay đổi, và các nhà cung cấp không thông báo về mọi thay đổi. Một nhật ký có ngày tháng là cách duy nhất để phân biệt sự trôi lệch với sự thay đổi thực sự. Một lần chạy có vẻ kỳ lạ đáng để lặp lại trong cùng ngày, vì một giờ kỳ lạ đơn lẻ chứng minh rất ít.

Ghi chú các thay đổi sản phẩm trong nhật ký khi bạn biết về chúng. Một dòng thời gian có ngày tháng giúp bạn khớp một xu hướng với một lần ra mắt, mặc dù ngày ra mắt chỉ là một manh mối.

Công cụ, quốc gia và tài khoản

Mỗi công cụ có đường truy xuất riêng, và mỗi quốc gia hoặc loại tài khoản cũng vậy. Hãy so sánh các yếu tố tương tự với nhau, và ghi lại vị trí mà lần chạy đã sử dụng. Ghi chú lại những yếu tố nào bạn đã kiểm soát.

Một kết quả từ một khu vực không phải là kết quả cho mọi khu vực. Hãy nói rõ điều này trong bất kỳ báo cáo nào, bên cạnh con số mà nó áp dụng. Nếu một công cụ được thử nghiệm trên máy tính xách tay và công cụ khác trên điện thoại, hai thứ đã thay đổi, vì vậy hãy giữ thiết bị cố định trong suốt chuỗi thử nghiệm.

Thế nào được coi là một sự thay đổi thực sự

Một sự thay đổi chỉ là thực sự khi nó nổi bật lên khỏi độ rung lắc mà bạn sẽ thấy dù sao đi nữa. Điều này nghe có vẻ hiển nhiên, nhưng nhiều nhật ký bỏ qua dữ liệu nền tảng và đọc mọi biến động như một kết quả.

Đánh giá một chuyển động so với nhiễu của nó

Trước khi gọi bất kỳ điều gì là một sự thay đổi, hãy đo lường xem các câu trả lời di chuyển bao nhiêu khi tự chúng. Một dữ liệu nền tảng dao động mạnh sẽ làm cho một cải tiến nhỏ trở nên vô hình.

So sánh độ phân tán của dữ liệu nền tảng với kích thước của sự thay đổi mà bạn hy vọng thấy. Nếu sự thay đổi nhỏ hơn độ rung lắc, nhãn chính xác là không có sự thay đổi nào có thể phát hiện được. Hãy ghi chú lại dữ liệu nền tảng trông như thế nào vào ngày bạn bắt đầu, bao gồm cả bất kỳ kết quả kỳ lạ nào bạn đã giữ lại. Những ghi chú đó ngăn việc so sánh sau này bị dịch chuyển một cách âm thầm.

Tần suất quan trọng hơn ảnh chụp màn hình đơn lẻ

Một ảnh chụp màn hình chỉ ghi lại một khoảnh khắc, và một xu hướng cần nhiều dữ liệu. Hãy đếm số lần chạy mà tên miền của bạn xuất hiện, sau đó chia cho tổng số lần chạy cho câu lệnh đó.

Hãy báo cáo tỷ lệ, không phải ảnh chụp màn hình, và nêu rõ có bao nhiêu lần chạy đã tạo nên con số đó. Người đọc sau đó có thể tự đánh giá kích thước mẫu.

Giữ ngân sách minh bạch

Các thử nghiệm thất bại về thời gian thường xuyên hơn là về tiền bạc. Một kế hoạch phù hợp với tuần của bạn sẽ dễ duy trì hơn một kế hoạch tham vọng bị đình trệ sau lần chạy đầu tiên.

Bao nhiêu lần chạy là đủ

Bốn lần chạy hàng tuần là mức tối thiểu, không phải mục tiêu. Tám lần cho thấy một xu hướng rõ ràng hơn cho hầu hết các câu hỏi, mặc dù con số phù hợp phụ thuộc vào mức độ biến động của các câu trả lời.

Hãy đếm số câu lệnh, không phải số giờ. Hai mươi câu lệnh chạy bốn lần tạo ra tám mươi hàng, điều này đã nhiều hơn nhiều so với một cái nhìn lướt qua trong một buổi chiều sẽ mang lại.

Thời gian trôi đi đâu

Hầu hết nỗ lực rơi vào buổi chiều đầu tiên, khi bộ câu lệnh và nhật ký được xây dựng. Sau đó, công việc là sự lặp lại, và sự lặp lại rất dễ bị bỏ qua. Hãy đặt lần chạy tiếp theo vào lịch trước khi bạn kết thúc lần chạy hiện tại. Một quy tắc thô giúp ích ở đây: quyết định số lần chạy trước lần chạy đầu tiên, và không mở rộng chuỗi thử nghiệm vì kết quả đầu看起来很 tốt.

Hãy dành ngân sách cho phần viết báo cáo. Một ghi chú ngắn gọn nêu rõ mẫu dữ liệu, ngày tháng và các giới hạn sẽ khó viết hơn chính các lần chạy.