Duy trì biểu đồ tri thức tổ chức bằng mô hình ngôn ngữ lớn (LLM) và kiến trúc định hướng sự kiện (event sourcing)

Piotr Jurewicz Ngày 11 tháng 8 năm 2026 cải thiện bài viết này rails event store llm ai Duy trì biểu đồ tri thức tổ chức bằng LLM và event sourcing … và tìm hiểu lý do tại sao hơn 5.600 kỹ sư Rails cũng đọc bài viết này Duy trì biểu đồ tri thức tổ chức bằng LLM và event sourcing Các tổ chức thường có xu hướng quên lãng một cách đáng ngạc nhiên. Các quyết định được đưa ra trong các cuộc gọi, những hiểu biết sâu sắc bị chôn vùi trong các chuỗi Slack, và một tháng sau không ai còn nhớ lý do tại sao mọi thứ lại như vậy. Tại Arkency, tôi cảm thấy rằng đôi khi một số điều cũng trôi tuột khỏi chúng tôi. Các cuộc gọi hàng tuần, các cuộc họp đột xuất, các câu lạc bộ sách của chúng tôi, các cuộc thảo luận trên Slack, các đề cập trên GitHub, hộp thư điện tử – chúng tôi có thể cần một số hỗ trợ trong việc tổ chức tất cả các tín hiệu đó. Sau đó, Hội nghị Cộng đồng Ruby 2026 đã diễn ra vào tháng 3. Tại Kraków, Obie Fernandez đã trình bày một số phần của hệ thống NEXUS của ông. Ông đã mô tả nó trên blog của mình từ tháng 1, nhưng hội nghị là nơi tôi lần đầu tiên biết đến nó. Đó là động lực tôi cần để bắt đầu xây dựng phần mềm của riêng mình. Khi nó đã bắt đầu hình thành, Andrej Karpathy đã xuất bản ghi chú LLM Wiki của mình. Thay vì một hệ thống RAG (Retrieval Augmented Generation) khám phá lại tài liệu của bạn trong mỗi truy vấn, một LLM duy trì một wiki liên tục một cách tăng dần: các trang markdown được liên kết với nhau, các nguồn bất biến bên dưới và một con người quản lý vòng lặp. Thật thú vị khi nhận ra rằng tôi đang làm việc trên một thứ vừa trở thành một trong những chủ đề nóng nhất trong ngành. Cuối cùng, chúng tôi đã có Planet Arkency – một biểu đồ tri thức đa người thuê (multi-tenant) với một ontology đóng, được xây dựng trên Rails Event Store. Trong bài viết này, tôi muốn trình bày cho bạn các quyết định thiết kế mà tôi đã đưa ra. Đầu vào phi cấu trúc là nơi LLM thực sự phát huy tác dụng Đối với dữ liệu có cấu trúc, bạn có thể đã xây dựng một hệ thống như vậy từ hai mươi năm trước. Webhooks, biểu mẫu, tích hợp – phân tích đầu vào có cấu trúc thành một biểu đồ là một vấn đề đã được giải quyết. Nhưng tri thức thú vị nhất nằm ở đầu vào mà không có trình phân tích cú pháp nào có thể xử lý được: bản ghi cuộc họp, thảo luận trên Slack, email hoặc bất cứ thứ gì đến từ một tích hợp mà chưa ai xây dựng. Đây là nơi LLM đã thay đổi cuộc chơi đối với chúng tôi. Mọi thứ đều chảy vào hệ thống thông qua một điểm tiếp nhận duy nhất. Các bản ghi, các chuỗi Slack được ai đó gắn cờ bằng một biểu tượng cảm xúc chuyên dụng, email đến một hộp thư cầu nối, nguồn cấp dữ liệu RSS, lời mời lịch, ghi chú cá nhân. Chúng tôi thậm chí không viết mã cho các điểm tích hợp. Các công cụ như Zapier hoặc n8n theo dõi các nguồn và đẩy nội dung đến điểm cuối duy nhất đó. Mỗi phần nội dung được tiếp nhận sau đó trải qua quá trình trích xuất – trái tim của hệ thống. Một LLM đọc nội dung và tìm ra ý nghĩa của nó đối với tri thức của chúng tôi: những thực thể nào xuất hiện trong đó, chúng tôi đã học được gì về chúng và chúng liên quan đến nhau như thế nào. Phần lớn bài viết này nói về những gì xảy ra xung quanh bước duy nhất đó. Tại sao lại là một biểu đồ? Những cái tên tương tự liên tục xuất hiện trong các cuộc trò chuyện của chúng tôi: con người, dự án, khách hàng, công cụ, quyết định. Điều thay đổi từ tuần này sang tuần khác là những gì chúng tôi biết về chúng và cách chúng liên quan đến nhau. Điều đó ánh xạ một cách tự nhiên vào một biểu đồ: các thực thể có thuộc tính, được kết nối bằng các mối quan hệ có kiểu. Ai làm việc gì. Ai đã đưa ra quyết định nào và khi nào. Dự án nào phụ thuộc vào công cụ nào. Đây là điểm chúng tôi khác biệt nhất so với cách tiếp cận LLM Wiki. Trong một wiki, việc ai đó làm việc trong một dự án nào đó được viết thành một câu trên một trang, tốt nhất là có một liên kết giữa hai trang. Tri thức ở đó, nhưng chỉ người đọc mới có thể sử dụng nó. Trong một đồ thị được định kiểu, "person --works_on--> project" là một mẩu dữ liệu: có thể truy vấn, duyệt qua, đếm. Bản thân đồ thị được lưu trữ trên PostgreSQL: một bảng các nút (nodes), một bảng các cạnh (edges) với bộ ba (nguồn, đích, quan hệ) duy nhất, cùng các thuộc tính jsonb trên cả hai. Đây không phải là công nghệ phức tạp. Các cơ sở dữ liệu đồ thị chuyên dụng (Neo4j, các kho lưu trữ bộ ba như loại NEXUS sử dụng) có thể phù hợp hơn cho một số khối lượng công việc cụ thể, như duyệt sâu nhiều bước (deep multi-hop traversal). Nhưng đó là một chi tiết lưu trữ – loại chi tiết có thể thay đổi sau này bằng cách viết một bộ điều hợp (adapter) khác cho lớp dữ liệu. Bản thể luận (Ontology) Các loại nút và quan hệ nào có thể tồn tại được định nghĩa trong một bản thể luận, lưu trữ trong một tệp YAML đơn giản: # từ config/ontology.yml node_kinds: - kind: person description: "thành viên nhóm, ứng viên, liên hệ khách hàng, người bên ngoài" - kind: decision description: "quyết định chính thức yêu cầu phán quyết của nhóm — đối với các đề xuất thông thường hãy dùng idea" edge_relations: - relation: works_on signature: "person --works_on--> project" Bản thể luận này là đóng – nếu một loại (kind) hoặc quan hệ (relation) không có trong danh sách, mô hình không thể sử dụng nó. Ban đầu, tôi đã nghĩ về một bản thể luận mở, nơi LLM có thể tự giới thiệu các loại của riêng mình. Điều đó đã mang lại sự hỗn loạn hoàn toàn cho đồ thị một cách đáng ngạc nhiên và nhanh chóng. Theo tôi, tốt hơn là nên nói rõ cho mô hình biết trước cần tìm kiếm điều gì. Không phải một đồ thị, mà là nhiều đồ thị “Đồ thị tri thức tổ chức” (The organizational knowledge graph) gợi ý một đồ thị phổ quát duy nhất cho mọi mục đích khác nhau. Chúng tôi không tin vào điều đó, và các chuyên gia DDD (Domain-Driven Design) sẽ nhận ra lý do. Chúng tôi sử dụng kiến trúc đa đối tượng thuê (multi-tenant architecture) để duy trì các đồ thị riêng biệt với bản thể luận của riêng chúng, điều này thực sự có nghĩa là các ngôn ngữ phổ biến (ubiquitous languages) của riêng chúng. Đồ thị Arkency nội bộ của chúng tôi nói về con người, dự án và quyết định – một lĩnh vực khá gần với CRM. Đồ thị chúng tôi vận hành với tư cách là người duy trì Rails Event Store nói về các bản phát hành, các vấn đề đã biết và nội dung cộng đồng: Các miền khác nhau, các từ vựng khác nhau, nhưng cùng một cơ chế bên dưới. Ranh giới của một ngữ cảnh giới hạn (bounded context) cho bạn biết một đồ thị kết thúc ở đâu và một đồ thị khác bắt đầu. Những gì thu được từ việc trích xuất Bản thể luận được hiển thị trong lời nhắc trích xuất (extraction prompt) dưới dạng bảng markdown và trong lược đồ (schema) dưới dạng kiểu liệt kê (enums). (từ app/lib/prompts/extraction.md.erb) Bạn là một nhà phân tích tri thức tổ chức cho <%= Tenancy.current_tenant.name %>. Chúng tôi đang xây dựng một đồ thị tri thức nội bộ. Trích xuất một đồ thị tri thức từ nội dung được cung cấp: các nút và các cạnh. Đồ thị phải cho phép tái tạo hoàn chỉnh nội dung được cung cấp. ## Các nút Mỗi nút có: tên, loại (kind), mô tả ngắn (short_description)