** Đây là chuỗi các bản nháp về paper "Thinking diagram" trước khi được dịch sang tiếng anh và đăng tải trên arxiv.

** Tài liệu có sử dụng AI trong biên tập.

Các công trình liên quan

Để định vị rõ hơn đóng góp của Thinking Diagram, phần này sẽ phân tích các công trình và kỹ thuật liên quan đang tìm cách giải quyết những hạn chế của mô hình tương tác dựa trên prompt. tôi sẽ chỉ ra rằng, dù rất hữu ích, những công nghệ này về cơ bản vẫn là những nỗ lực tối ưu hóa bên trong một mô hình cũ, chứ chưa phải là một sự thay đổi mô hình (paradigm shift) thực sự.

Nỗ lực phổ biến và cơ bản nhất trong số này là Prompt Engineering (PE). Được định nghĩa là nghệ thuật và khoa học của việc xây dựng các chuỗi văn bản đầu vào hiệu quả, PE tập trung vào việc tối ưu hóa cách chúng ta "nói chuyện" với LLM trong giới hạn của một chuỗi văn bản.

Tuy nhiên, tôi cho rằng PE tồn tại như một giải pháp tình thế cho một vấn đề cơ bản: việc tương tác chuyên sâu với các mô hình ngôn ngữ lớn là một việc quá khó khăn, không chỉ với người dùng phổ thông mà ngay cả với chính những chuyên gia về LLM.

Công việc của một Prompt Engineer có thể được so sánh với một luật sư giỏi đang cố gắng tìm ra một kẽ hở trong một bản hợp đồng để khai thác. Về lý thuyết, bất cứ ai cũng có thể đọc hợp đồng đó và có khả năng tự tìm ra kẽ hở, nhưng luật sư, với kỹ năng chuyên môn được rèn luyện, sẽ làm điều đó nhanh hơn, sâu hơn và hiệu quả hơn. Tuy nhiên, điều quan trọng nhất là kẽ hở đó thường chỉ tồn tại và có giá trị trong duy nhất bản hợp đồng đó, nó không mang tính đại diện cho mọi bản hợp đồng khác. Từ phép so sánh này, tôi khẳng định rằng PE về bản chất là một kỹ năng chuyên môn, chứ không phải một vị trí công việc có nền tảng lý thuyết vững chắc. Lý do duy nhất khiến kỹ năng này được nâng lên thành một vị trí công việc riêng biệt là vì hiện tại chưa có một giải pháp tương tác tổng thể và bền vững. Sự thiếu hụt này thể hiện ở nhiều cấp độ:

• Trên các loại mô hình khác nhau: Một kỹ thuật prompt hiệu quả cho việc tạo văn bản thường không thể áp dụng cho việc tạo hình ảnh hay video, mỗi loại đều đòi hỏi một phương pháp tiếp cận và "ngôn ngữ" riêng.
• Trên các phiên bản khác nhau: Thậm chí trong cùng một dòng sản phẩm, một prompt được tinh chỉnh hoàn hảo cho GPT-4 thường phải được thiết kế lại gần như từ đầu khi chuyển sang một phiên bản tương lai như GPT-5, thay vì có thể sử dụng trực tiếp. Tính tương thích ngược gần như không tồn tại.
• Trên các nhà cung cấp khác nhau: Sự rắc rối này càng nhân lên khi so sánh các mô hình từ những nhà cung cấp khác nhau. Một prompt được tối ưu cho dòng mô hình GPT của OpenAI gần như chắc chắn sẽ hoạt động kém hiệu quả trên Gemini của Google hay Claude của Anthropic mà không có sự tinh chỉnh sâu rộng.

Chính vì sự phân mảnh và thiếu tính chuẩn hóa này, gánh nặng nhận thức và năng lực tối thiểu yêu cầu của người có kỹ năng PE đã bị đẩy lên quá cao, buộc thị trường phải định hình nên một vị trí chuyên biệt để đáp ứng.

Sự tồn tại của vị trí này đã vô tình tạo ra một quy trình làm việc kém hiệu quả và tốn kém. Trong đó, một chuyên gia lĩnh vực (A) phải cố gắng diễn giải ý tưởng và chuyên môn của mình cho một Prompt Engineer (B), người này sau đó lại "phiên dịch" nó thành một hoặc một loạt prompt cho một LLM (C) thực thi. Trong quy trình này, người B về bản chất chỉ là một thông dịch viên, và có khả năng rất cao là không có chuyên môn chi tiết về vấn đề của người A. Hơn thế nữa, nếu người A có đủ khả năng để tự diễn giải thành một prompt hiệu quả, thì sự tồn tại của người B trở nên hoàn toàn dư thừa. Mô hình này không khác gì việc hai người bất đồng ngôn ngữ cần một người phiên dịch trực tiếp, thậm chí nó còn phức tạp hơn vì "ngôn ngữ" của LLM liên tục thay đổi. Hệ quả trực tiếp là chi phí sử dụng tăng lên đáng kể, trong khi hiệu quả lại thấp do thông tin liên tục bị mất mát và "tam sao thất bản" qua các bước trung gian.

Cuối cùng, ngay cả trong trường hợp lý tưởng nhất là chuyên gia A cũng đồng thời là một người có kỹ năng PE, quy trình vẫn vấp phải một rào cản tâm lý học cơ bản. Con người là sinh vật có tính quán tính, có xu hướng mất mát thông tin ngay trong chính nhận thức của mình. Chúng ta thường bỏ qua những chi tiết mà bản thân cho là "hiển nhiên" hoặc những ý tưởng phức tạp vì chúng quá khó để diễn giải thành lời một cách đầy đủ. Sự kết hợp giữa một quy trình tương tác vốn đã thiếu sót và xu hướng mất mát thông tin tự nhiên trong nhận thức con người đã tạo ra một "vùng tối thông tin" (dark zone of information) không hề nhỏ. Đây chính là khoảng trống mênh mông giữa ý định thực sự của người dùng và những gì LLM thực sự hiểu.

Tất cả những vấn đề trên—từ sự mong manh của prompt, quy trình làm việc cồng kềnh, cho đến "vùng tối thông tin"—thực ra đều bắt nguồn từ một sai lầm trong triết lý nền tảng. Chúng ta đang chấp nhận một nghịch lý: một LLM được quảng bá là "nhà thông thái vạn năng" nhưng lại không thể tự xử lý những "ý tưởng hỗn loạn" của con người.

Việc đòi hỏi phải có một vị trí chuyên biệt chỉ để sắp xếp và diễn giải lại thông tin cho LLM là một sự thừa nhận thất bại trong thiết kế, một sự lãng phí tài năng và trực tiếp phủ nhận tiềm năng của chính công nghệ AI. Không ai thuê một người chỉ để viết lại những gì họ nghĩ, trừ những trường hợp đặc biệt. Câu hỏi cốt lõi cần được đặt ra không phải là "Làm sao để tạo ra prompt tốt hơn?", mà là "Tại sao chúng ta phải chấp nhận một mô hình tương tác mà bắt buộc phải có Prompt Engineering ngay từ đầu?"

Lịch sử phát triển của PE chính là minh chứng rõ ràng nhất cho luận điểm này. Nó khởi nguồn từ nhu cầu thực tiễn phải tìm ra "điểm cân bằng" mong manh cho prompt, để không quá dài hay quá ngắn. Dần dần, nó phát triển thành các kỹ thuật phức tạp hơn như việc thiết kế các lớp logic trung gian để chuẩn hóa đầu vào. Không thể phủ nhận rằng PE đã là một bước tiến lớn, giúp chúng ta khai thác LLM hiệu quả hơn rất nhiều so với thuở sơ khai.

Tuy nhiên, về bản chất, nó vẫn chỉ là một "giải pháp tình thế" được tối ưu hóa quá mức, đến nỗi chúng ta tạm gói nó lại và gọi là một giải pháp thực sự. Nó không giải quyết tận gốc các vấn đề về cấu trúc, nhận thức hay sự hợp tác. Điều này càng khẳng định rằng, vấn đề không nằm ở việc liên tục tinh chỉnh cách "nói chuyện" với AI, mà nằm ở chính "ngôn ngữ" chúng ta đang sử dụng. Nhu cầu cho một triết lý thiết kế tương tác mới là hoàn toàn cần thiết.

Một trong những nỗ lực quan trọng nhất để vượt qua giới hạn của mô hình LLM khép kín chính là kiến trúc Retrieval-Augmented Generation (RAG). Không thể phủ nhận rằng RAG là một bước tiến lớn. Nó đã thành công trong việc giải quyết vấn đề ảo giác (hallucination) bằng cách nối đất LLM vào một nguồn dữ liệu thực tế, đồng thời làm giàu ngữ cảnh để LLM có đủ thông tin cơ bản hoạt động.

Để có cơ sở phân tích, tôi sẽ tóm tắt lại kiến trúc cốt lõi của một hệ thống RAG điển hình. Về cơ bản, nó bao gồm ba thành phần chính: (1) một Kho tri thức (Knowledge Base), nơi tài liệu được một mô hình embedding riêng biệt vector hóa; (2) một Bộ truy xuất (Retriever), có nhiệm vụ tìm kiếm và lấy ra các đoạn văn bản liên quan từ kho tri thức dựa trên prompt đầu vào; và (3) chính Mô hình Ngôn ngữ Lớn (LLM), có nhiệm vụ tổng hợp câu trả lời dựa trên prompt gốc đã được làm giàu bởi các văn bản được truy xuất.

Tuy nhiên, khi nhìn vào thiết kế này, ta có thể thấy rõ bản chất của RAG: nó là một hệ thống cố gắng suy diễn (infer) ý định phức tạp của người dùng và tự động truy xuất những thông tin mà nó phỏng đoán (presume) là liên quan. Quy trình này, dù thông minh, lại tiềm ẩn nhiều rủi ro và gần như không được kiểm soát bởi người dùng, dẫn đến các vấn đề cố hữu:

• Garbage In, Garbage Out: Bộ truy xuất không thể đánh giá được chất lượng hay tầm quan trọng của thông tin. Nó chỉ tìm kiếm sự tương đồng, và nếu thông tin gốc bị sai lệch hoặc kém chất lượng, LLM sẽ tạo ra những kết quả sai lầm một cách đầy thuyết phục.
• Hai Lớp Hộp đen: Bản thân LLM đã là một hộp đen. RAG đặt thêm một chiếc hộp đen mới (Bộ truy xuất) lên trên. Khi kết quả sai, chúng ta không thể biết lỗi đến từ việc truy xuất sai thông tin hay do LLM suy luận sai, khiến việc kiểm soát chất lượng ở quy mô lớn trở nên bất khả thi.

Một kịch bản thực tế minh họa rõ nét cho vấn đề này là trong lĩnh vực phát triển phần mềm. Các LLM thường thất bại khi được yêu cầu tái cấu trúc (refactor) toàn bộ một dự án lớn. Hệ thống RAG, khi cố gắng cung cấp toàn bộ ngữ cảnh này, thường gây nhiễu và dẫn đến các giải pháp sai. Ngược lại, khi một lập trình viên chủ động cung cấp ngữ cảnh giới hạn trong một vài tệp liên quan, LLM lại có khả năng thực hiện tác vụ một cách chính xác. Sự khác biệt này nhấn mạnh rằng vấn đề cốt lõi nằm ở sự thiếu kiểm soát, và chúng ta cần tiếp cận vấn đề cung cấp thông tin dưới một lăng kính mới, thay vì chỉ cố gắng tối ưu một quy trình vốn đã sai về mặt triết lý.

Một hướng tiếp cận quan trọng khác nhằm giải quyết sự phức tạp của việc tương tác với AI là sự trỗi dậy của các giao diện dựa trên đồ thị (graph-based interfaces). Các công cụ như ComfyUI, LangFlow, và nhiều nền tảng khác đã chứng minh sức mạnh của việc trực quan hóa các quy trình AI (workflows) vốn rất phức tạp. Để phân tích sâu hơn, tôi sẽ tập trung vào ComfyUI như một ví dụ điển hình, đặc biệt trong lĩnh vực tạo sinh hình ảnh.

ComfyUI cho phép người dùng định nghĩa các quy trình xử lý media phức tạp bằng cách kết nối các node với nhau, mang lại sự tường minh và khả năng kiểm soát chi tiết. Điểm sáng giá nhất của nó nằm ở khả năng tiếp cận: không giống như Prompt Engineering đòi hỏi một kỹ năng chuyên biệt, ComfyUI trao quyền trực tiếp cho các chuyên gia lĩnh vực. Một họa sĩ có thể nhanh chóng học và xây dựng các quy trình phức tạp để hiện thực hóa tầm nhìn nghệ thuật của mình mà không cần phải trở thành một chuyên gia về LLM. Điều này chứng tỏ giao diện đồ thị tương thích một cách tự nhiên với cách con người tư duy và xây dựng các hệ thống, hạ thấp đáng kể rào cản nhận thức.

Một quan sát quan trọng khác là ComfyUI không hề có một hệ thống RAG chính thức, nhưng vẫn đạt được kết quả đầu ra chất lượng rất cao. Lý do là vì chính bản thân đồ thị, khi được người dùng chuyên môn xây dựng một cách có chủ đích, đã trở thành một cơ chế cung cấp ngữ cảnh và thông tin vượt trội. Mỗi node và mỗi kết nối trong quy trình không chỉ là một hành động, mà còn là một bước làm giàu và định hướng thông tin một cách tường minh. Có thể nói, một đồ thị được thiết kế tốt chính là hình thức Active RAG hiệu quả nhất. Điều này là một minh chứng thực tế rằng sự kế thừa tự nhiên của RAG chính là một cấu trúc đồ thị do người dùng kiểm soát.

Tuy nhiên, dù đã vô tình chứng minh cho triết lý của Active RAG, cần phải làm rõ một sự khác biệt tinh tế nhưng cốt lõi: ComfyUI là một công cụ để định nghĩa quy trình xử lý (workflow definition), không phải để xây dựng tư duy đầu vào (input construction). Các node trong ComfyUI đại diện cho các hành động hoặc các mô hình, không phải các khái niệm hay mối quan hệ logic cấu thành nên một yêu cầu phức tạp. Mục đích của nó là điều phối các công cụ AI, chứ không phải để diễn tả một ý tưởng phức tạp cho AI hiểu.

Tựu trung lại, việc phân tích các công trình liên quan đã cho thấy một bức tranh rõ ràng. Phân tích về Prompt Engineering đã chỉ ra nhu-cầu cấp thiết về một ngôn ngữ tương tác mới, vượt qua sự mong manh và thiếu cấu trúc của văn bản thuần túy. Phân tích về RAG đã nhấn mạnh đòi hỏi về một cơ chế kiểm soát ngữ cảnh chủ động và tường minh, thay vì bị động và phỏng đoán. Cuối cùng, sự thành công của ComfyUI đã chứng minh sức mạnh của giao diện đồ thị, đồng thời bộc lộ khoảng trống về một công cụ dùng đồ thị để xây dựng chính tư duy làm đầu vào, thay vì chỉ để sắp xếp quy trình.

Thinking Diagram được đề xuất như một giải pháp tổng thể, đáp ứng đồng thời cả ba nhu cầu này. Nó chính là ngôn ngữ tương tác mới, với cơ chế Active RAG nội tại, được thể hiện qua một giao diện đồ thị để xây dựng tư duy. Trong phần tiếp theo, tôi sẽ trình bày chi tiết về kiến trúc và triết lý của Thinking Diagram.