HN giới thiệu: FastGraphRAG – kỹ thuật RAG cải tiến tận dụng PageRank truyền thống
(github.com/circlemind-ai)- Fast GraphRAG là một framework GraphRAG được đơn giản hóa cho quy trình truy xuất dựa trên tác nhân có thể diễn giải và độ chính xác cao, tập trung vào việc gắn RAG nâng cao vào pipeline truy xuất mà không cần tự xây dựng các quy trình tác nhân phức tạp
- Biến đồ thị tri thức thành dạng con người có thể khám phá, cho phép truy vấn, trực quan hóa và cập nhật, đồng thời tự động tạo và tinh chỉnh đồ thị theo yêu cầu miền và ontology
- Đối với phản hồi truy vấn, sử dụng duyệt đồ thị dựa trên personalized PageRank để tìm thông tin liên quan, và README liên kết đến bài báo HippoRAG như phần tổng quan về cách tiếp cận này
- Trong ví dụ chi phí với The Wizard of Oz,
fast-graphragđược nêu là $0.08 còngraphraglà $0.48, và cho biết giảm chi phí 6 lần còn được cải thiện hơn khi kích thước dữ liệu và số lần chèn tăng lên - Hoạt động trên Python 3.10.1 trở lên, hỗ trợ cài đặt từ mã nguồn và từ PyPI, sau khi thiết lập khóa API OpenAI có thể chèn tài liệu và truy vấn, đồng thời tự động duy trì tri thức trong cùng thư mục làm việc
Framework truy xuất mà Fast GraphRAG cung cấp
- Fast GraphRAG là một framework GraphRAG hướng tới tri thức có thể diễn giải và gỡ lỗi được
- Đồ thị cung cấp tri thức ở dạng con người có thể khám phá và hỗ trợ các tác vụ sau
- Truy vấn
- Trực quan hóa
- Cập nhật
- Tập trung vào việc cung cấp các tính năng RAG nâng cao đồng thời giảm gánh nặng phải tự xây dựng và thiết kế quy trình tác nhân
Tính năng chính
- Được thiết kế để có thể chạy ở quy mô lớn với tốc độ nhanh và chi phí thấp, theo hướng giảm nhu cầu tài nguyên nặng và chi phí cao
- Hỗ trợ dữ liệu động, tự động tạo và tinh chỉnh đồ thị theo yêu cầu về miền và ontology
- Hỗ trợ cập nhật gia tăng khi dữ liệu thay đổi, cho phép cập nhật theo thời gian thực
- Cung cấp duyệt thông minh sử dụng duyệt đồ thị dựa trên PageRank để nâng cao độ chính xác và độ tin cậy
- Tổng thể hoạt động theo kiểu bất đồng bộ, hướng tới quy trình làm việc vững chắc và có thể dự đoán nhờ hỗ trợ kiểu đầy đủ
Ví dụ chi phí
- Trong ví dụ sử dụng The Wizard of Oz, chi phí của
fast-graphragđược nêu là $0.08, còngraphraglà $0.48 - README mô tả đây là mức giảm chi phí 6 lần, và cho biết hiệu quả tiết kiệm sẽ còn tốt hơn khi kích thước dữ liệu và số lần chèn tăng lên
Cài đặt và luồng thực thi
- Các cách cài đặt được khuyến nghị được chia thành cài đặt từ mã nguồn để có hiệu năng và cài đặt từ PyPI để có độ ổn định
- Cài đặt từ mã nguồn: clone kho lưu trữ rồi chạy
poetry install - Cài đặt từ PyPI:
pip install fast-graphrag
- Cài đặt từ mã nguồn: clone kho lưu trữ rồi chạy
- Ví dụ bắt đầu nhanh trước hết thiết lập biến môi trường
OPENAI_API_KEY - Sau khi tải xuống văn bản A Christmas Carol, khởi tạo
GraphRAGtrong mã Python - Ví dụ khởi tạo bao gồm các giá trị sau
working_dir="./book_example"domainđể phân tích nhân vật, tương tác, địa điểm và quan hệ trong câu chuyện- Danh sách truy vấn mẫu
- Các kiểu thực thể
["Character", "Animal", "Place", "Object", "Activity", "Event"]
- Chèn tài liệu bằng
grag.insert(f.read()), và in kết quả truy vấn bằnggrag.query("Who is Scrooge?").response - Nếu khởi tạo lại trong cùng thư mục làm việc thì tri thức sẽ tự động được duy trì
- Khi dùng mô hình cục bộ hoặc các trường hợp tương tự, có thể tùy chọn đặt biến môi trường như
CONCURRENT_TASK_LIMIT=8để kiểm soát số lượng tác vụ xử lý đồng thời của LLM
Ví dụ và tùy chọn cấu hình
- Thư mục
examplescung cấp các hướng dẫn về những trường hợp sử dụng phổ biến của thư viện custom_llm.pylà ví dụ đơn giản về việc cấu hình khác nhau giữa mô hình ngôn ngữ và bộ nhúng tương thích với OpenAI APIcheckpointing.ipynbtrình bày cách dùng checkpoint để tránh hỏng dữ liệu không thể hoàn tácquery_parameters.ipynbđề cập đến nhiều tham số truy vấn khác nhau và cho thấy cách bao gồm tham chiếu đến thông tin được dùng trong câu trả lời vớiwith_references=True
Triết lý thiết kế và cách duyệt
- Mục tiêu là tăng số lượng ứng dụng GenAI thành công, và để làm điều đó họ xây dựng công cụ bộ nhớ và dữ liệu giúp các ứng dụng LLM tận dụng pipeline truy xuất chuyên biệt mà không cần thiết lập và duy trì các quy trình tác nhân phức tạp
- Fast GraphRAG duyệt đồ thị bằng thuật toán personalized PageRank để tìm thông tin liên quan nhất nhằm trả lời truy vấn hiện tại
- Như tài liệu tham khảo tổng quan về lý do cách tiếp cận này hoạt động, README dẫn tới HippoRAG paper
Mã nguồn mở và dịch vụ được quản lý
- Kho lưu trữ được cung cấp theo MIT License, chi tiết có tại LICENSE.txt
- Dự án cung cấp dịch vụ được quản lý như một cách để bắt đầu nhanh và đáng tin cậy
- Với dịch vụ được quản lý, 100 yêu cầu đầu tiên mỗi tháng là miễn phí, sau đó tính phí theo mức sử dụng
- Để tìm hiểu thêm về dịch vụ được quản lý, có thể đặt lịch demo hoặc xem docs
- Hướng dẫn đóng góp có tại CONTRIBUTING.md, và có thể đặt câu hỏi trên Discord
1 bình luận
Các ý kiến trên Hacker News
Ngoài PageRank, còn có vài chỉ số trung tâm thú vị có thể ảnh hưởng đến RAG trên dữ liệu có cấu trúc
Trong đó, Triangle Centrality tính độ trung tâm bằng cách đếm các tam giác xung quanh nút, dựa trên khái niệm rằng tam giác đóng chặt các quan hệ, còn các kết nối mở sẽ lấy bớt trọng số khỏi trung tâm và làm loãng độ trung tâm
https://arxiv.org/abs/2105.00110
Bài báo nói rằng nó hiệu quả hơn các chỉ số trung tâm khác như PageRank, nhưng trong nghiên cứu dùng GraphBLAS, trên nhiều đồ thị thưa với quy mô tới 1,8 tỷ cạnh, TC chậm hơn triển khai PageRank thưa của chúng tôi
Tuy vậy, có vẻ TC mở rộng tốt hơn khi đồ thị lớn hơn, và rất có khả năng hiệu quả hơn ở phạm vi cạnh tính bằng nghìn tỷ
https://fossies.org/linux/SuiteSparse/GraphBLAS/Doc/The_Grap...
Dù sao thì khi tạo câu trả lời, phần LLM phân tích cú pháp sẽ là nút thắt cổ chai
PageRank là bước đầu, nhưng tôi cũng muốn thử các lựa chọn thay thế chính xác hơn
Ở đây đang dùng PageRank cá nhân hóa, nên sẽ gán trọng số ban đầu cho một tập nút cụ thể; tôi tò mò liệu Triangle Centrality có hỗ trợ điều này không
Ngoài ra cũng đang xét trọng số cạnh, nên muốn biết phần đó có khả thi không
https://link.springer.com/content/pdf/10.1007/978-3-030-6097...
Tôi đã làm khá nhiều trong lĩnh vực này và có vài điều rút ra được
Tôi đã kết hợp ba điều này để tạo ra một bước phân rã/trích xuất tri thức tương tự, rồi gắn thêm meta prompter để gần như tự động tạo ra domain/kiểu thực thể
Về cơ bản, LLM không giỏi chọn đúng mức độ chi tiết cho tri thức đã phân rã
Một mẹo là yêu cầu LLM xuất mindmap mermaid.js để chia đầu vào thành cây phân cấp, rồi ở cuối nói mức nào là gốc phù hợp cho một nút tri thức
Sau đó tạo các câu hỏi có thể được trả lời bằng tri thức trong nút đó, rồi lập chỉ mục văn bản câu hỏi này và cũng tạo embedding cho nó
Ngay cả khi so khớp trực tiếp truy vấn người dùng với các câu hỏi này bằng BM25 thuần túy cũng cho kết quả tốt; cách tiếp cận hybrid còn tốt hơn, nhưng chênh lệch không quá lớn
Nếu không dùng LLM ở thời điểm truy vấn, cũng có thể dùng độ tương đồng embedding làm hàm chi phí duyệt để đi theo phân cấp từ gốc xuống các nút sâu hơn
Cuối cùng tôi quyết định chuyển sang đồ thị như một dạng tổng quát hóa của cây
Tôi xem ý tưởng dùng độ tương đồng embedding để “đi” trên đồ thị là cốt lõi, và cũng đang tích cực tích hợp vào FastGraphRAG theo cách gán trọng số cạnh tùy theo truy vấn
Thật thú vị khi thấy nhiều giải pháp hội tụ về thiết kế tương tự
Ý tưởng tạo câu trả lời giả định từ truy vấn rồi dùng câu trả lời đó để tìm kiếm embedding rất thú vị, tôi định thêm vào danh sách thử nghiệm
Giờ tôi cũng tò mò liệu tạo câu trả lời giả định bằng LLM được tinh chỉnh theo kho ngữ liệu có thể hoạt động tốt hơn không
Tôi cũng muốn biết khi tạo câu trả lời giả định, bạn có prompt phản hồi theo “kích thước chunk” không
Dùng PageRank để có độ trung tâm tốt hơn nghe có vẻ ổn, nhưng vẫn không giải quyết được khiếm khuyết có lẽ là bất khả giải của RAG, tức lý do về cơ bản RAG khó hoạt động
Lý do mọi DB RAG đều có hiệu năng thấp hơn kỳ vọng là vì RAG về căn bản không tìm được quan hệ giữa các từ cần thiết để tìm thông tin người dùng muốn
Nghe có vẻ lạ, vì có thể nghĩ cơ chế “attention” vốn phải làm tốt việc này, nhưng thực tế là chưa đủ
Ví dụ, giả sử trong một bài viết có nội dung một người tên ‘Sharon’ đã tham dự nhiều hội nghị hóa lý, nhưng nghề nghiệp không được nêu rõ
Nếu tìm “Nghề nghiệp của Sharon là gì?”, gần như mọi cách tiếp cận RAG nhiều khả năng sẽ không nối được ‘nghề nghiệp’, việc tham dự hội nghị và loại hội nghị để suy luận là ‘nhà hóa học’
Loại lỗi này lan rộng trên nhiều loại thông tin khi tìm kiếm thông tin bằng RAG
Cuối cùng, các giải pháp như trên trông giống như tái phát minh các phương thức truy vấn khác như SQL, PageRank qua nhiều bước hơn, và đến điểm đó thì vector hóa không còn nhiều ý nghĩa
Thành phần RAG chỉ cần tìm bài viết liên quan đến Sharon trong tập dữ liệu lớn rồi chuyển toàn bộ làm ngữ cảnh cho LLM
Nếu xem bài báo HippoRAG được trích trong bài gốc, ví dụ tạo động lực gần như giống hệt, và phần đánh giá cũng chủ yếu nhắm vào loại hỏi đáp đa bước như thế này
Chỉ cần lấy thực thể Sharon, rồi nhận các nút và cạnh gần Sharon làm ngữ cảnh bổ sung
Phần tiếp theo là vai trò của LLM, và nếu trong ngữ cảnh được cung cấp không có nghề nghiệp, nó nên cho biết “Không thể tìm thấy nghề nghiệp của Sharon trong ngữ cảnh được cung cấp”
Thấy thú vị nên tôi đã đăng ký và thử tải vài tài liệu PDF lên dashboard
Use case là phân tích tài liệu tuân thủ liên quan đến sản xuất tại một startup AI; để nó hữu ích với chúng tôi thì cần hiểu hệ thống hoạt động được đến quy mô nào và mô hình chi phí ra sao
Mỗi khách hàng có khoảng 300.000 PDF, và dự kiến mỗi tháng khoảng 10% tập tài liệu sẽ thay đổi
Bất kỳ hệ thống GraphRAG nào cũng cần xử lý tài liệu ở quy mô lớn; có thể dùng S3 làm cơ chế ingest, nhưng cần biết chi phí và thời gian xử lý cho đến khi hệ thống sẵn sàng sử dụng ở các thời điểm sau
Muốn trao đổi chi tiết hơn, bạn liên hệ antonio [at] circlemind.co nhé
Thú vị đấy, tôi tò mò không biết corpus văn bản đặc thù theo domain cần lớn đến mức nào để có được một knowledge graph hữu ích
Aider từ lâu đã áp dụng PageRank lên call graph của repository mã nguồn
Mọi code không tầm thường đều có rất nhiều cấu trúc graph để hỗ trợ PageRank, nên cách này hoạt động rất tốt trong việc tìm ngữ cảnh liên quan nhất trong project cho tác vụ hiện tại
https://aider.chat/docs/repomap.html#optimizing-the-map
Khi có nhiều người bắt đầu dùng thử hơn, tôi rất muốn nghe phản hồi
Không biết có kế hoạch cho phép ép tạo repo map và kiểm tra nó không
Hay quá
Tôi tò mò graph được lưu trữ và truy vấn như thế nào
Tôi quen với graph database, nhưng có vẻ nó không phải dependency
Cũng tò mò liệu các bạn đã thử mô hình sciphi triplex cho việc trích xuất chưa
Trước đây khi tôi thử trích xuất, nếu trích xuất cùng một chunk nhiều lần liên tiếp thì kết quả không nhất quán
Codebase được thiết kế để có thể dễ dàng tích hợp bất kỳ graph DB nào bằng cách viết một wrapper nhẹ, và trong tương lai gần sẽ hỗ trợ những thứ như neo4j
Chúng tôi chưa thử triplex, vì hiện tại gpt4o-mini đã đủ nhanh và chính xác
Chúng tôi dùng gpt4o-mini không chỉ để trích xuất entity và quan hệ, mà còn để sinh mô tả và xử lý xung đột
Fine-tuning chắc chắn sẽ làm kết quả tốt hơn
Truy vấn graph hoạt động bằng cách tìm tập node ban đầu có liên quan đến truy vấn đã cho, rồi chạy PageRank cá nhân hóa từ các node đó để tìm các đoạn liên quan khác
Hiện tại chúng tôi chọn node ban đầu bằng tìm kiếm ngữ nghĩa trên cả toàn bộ truy vấn lẫn các entity trích xuất từ truy vấn, nhưng cũng đang lên kế hoạch cho vài phần mở rộng thú vị cho cách này
Ý tưởng hay
Cá nhân tôi nghĩ information retrieval truyền thống mới là hướng đi cho RAG
Vector search thì tốt, nhưng chậm và đắt, và mọi người có xu hướng dùng nó như bột phép
Nó hoạt động tốt với dữ liệu phi cấu trúc, nhưng không nhất thiết phù hợp như vậy với dữ liệu có cấu trúc
Trừ khi được tinh chỉnh rất tốt, vector search cũng không vượt trội hơn nhiều so với truy vấn truyền thống được tối ưu tốt
Tôi từng thấy thực tế là người ta biến dữ liệu có cấu trúc thành dữ liệu phi cấu trúc rồi mới làm vector search hoặc prompt engineering; nhìn tổng thể thì hơi như đi ngược
Nó vẫn hoạt động ở một mức độ nào đó, nhưng rất có thể có cách thông minh hơn để đạt cùng kết quả
Bản chất của Graph RAG là tận dụng cấu trúc dữ liệu
Dù đó là SQL join hay truy vấn graph DB thì cũng không quá quan trọng
Việc dạy LLM cách truy vấn, hoặc cho nó giao tiếp với các API tìm kiếm/truy vấn hiện có, cũng sẽ có giá trị
Xếp hạng chưa tốt thì có thể bù bằng kích thước ngữ cảnh lớn hơn, rồi lấy hàng trăm kết quả trở lên bằng nhiều truy vấn
Mở rộng theo cách đó sẽ nhanh và rẻ hơn vector search rất nhiều
Trông có vẻ tốt, nhưng tôi từng bị các lớp trừu tượng khác như LangChain làm khổ, nên lo ngại việc đơn giản hóa quá mức
Tôi tò mò các bạn định làm gì để không lặp lại sai lầm tương tự
Tôi tò mò liệu có điểm metric đánh giá cho phần tìm kiếm và sinh nội dung không
Ví dụ như trên các dataset KILT hay NQ
Benchmark dataset không phải là tất cả, nhưng nếu cho thấy điểm số tương đối ổn và thời gian suy luận thì sẽ rất hữu ích để thuyết phục hoặc để kỹ sư chọn framework
Với tư cách kỹ sư xử lý ngôn ngữ tự nhiên freelance, tôi đã xây khá nhiều pipeline RAG, và tôi dự định sẽ tự mình thử cái này
Tôi hiện đang làm một chatbot Q&A và gặp khó khi xử lý kịch bản sau
Khi người dùng hỏi “ý bạn là gì trong câu trước vừa nói?”, tôi tò mò framework này có thể tìm đúng một tập con nhỏ tri thức thô và tích hợp vào LLM như thế nào để tạo phản hồi liên quan
Tôi thấy khó giải quyết vấn đề này nếu không phụ thuộc vào framework bên ngoài
https://www.reddit.com/r/LocalLLaMA/comments/1gtzdid/d_optim...
Tôi muốn biết framework này giải quyết vấn đề đó và đơn giản hóa quy trình ra sao
Nếu không có bước này, hệ thống thường thất bại khi người dùng hỏi kiểu “giải thích kỹ hơn mục 2” hoặc “cho ví dụ chi tiết về nội dung trên”
Triển khai hiện tại có 3 index; sau khi cung cấp truy vấn và các tin nhắn trước đó, tôi yêu cầu LLM phân rã thành các phần sau
Yêu cầu đầy đủ, câu hỏi tối ưu cho BM25, từ khóa, câu hỏi tối ưu cho tìm kiếm ngữ nghĩa
Sau đó thực hiện RAG và rerank, rồi đưa top N đoạn cùng với yêu cầu đầy đủ vào lần gọi LLM thứ hai
Cần tập trung vào bước orchestration
Bạn có thể tìm hiểu ReAct agent, và có thể xây bằng LangGraph hoặc Bedrock Agents