LatticeDB: Cơ sở dữ liệu đồ thị nhúng hỗ trợ tìm kiếm vector và văn bản toàn diện

Cơ sở dữ liệu đồ thị thuộc tính nhúng (embedded) với khả năng đánh chỉ mục vector và toàn văn bản (full-text) gốc.

LatticeDB là cơ sở dữ liệu cục bộ dạng tệp đơn lẻ dành cho dữ liệu có kết nối, dữ liệu ngữ nghĩa và dữ liệu văn bản. Nó cho phép bạn duyệt qua các mối quan hệ, thực hiện tìm kiếm tương đồng vector và tìm kiếm toàn văn bản BM25 trên cùng một tập dữ liệu trong một engine và một lớp truy vấn duy nhất. Nó được thiết kế cho các khối lượng công việc nặng về mối quan hệ trên một máy đơn lẻ, với cơ chế vận hành không cần cấu hình và mô hình ghi đơn (single-writer) nhúng.

LatticeDB là cơ sở dữ liệu đồ thị nhúng, tệp đơn lẻ cho phép các ứng dụng cục bộ truy vấn cùng một dữ liệu theo mối quan hệ, ngữ nghĩa và văn bản, sau đó tiêu thụ các sự kiện đồ thị và ứng dụng bền vững từ cùng một tệp đó. Các khối lượng công việc như Graph RAG, bộ nhớ tác nhân (agent memory) và các công cụ tri thức cục bộ là những ví dụ được xây dựng trên các nguyên hàm đó, chứ không phải là định nghĩa của engine này.

Cài đặt

CLI

Python

Các gói wheel được xuất bản dự kiến sẽ đi kèm với liblattice trên các nền tảng được hỗ trợ. Việc cài đặt từ mã nguồn cũng có thể bao gồm một thư viện gốc đã được dàn dựng trong quá trình build wheel với LATTICE_BUNDLE_LIB_DIR=/path/to/lib.

TypeScript / Node.js

Các gói tarball được xuất bản dự kiến sẽ đi kèm với liblattice trên các nền tảng được hỗ trợ. Việc kiểm tra mã nguồn có thể dàn dựng thư viện gốc vào gói với lệnh LATTICE_BUNDLE_LIB_DIR=/path/to/lib npm run bundle:native.

Go

Xem bindings/go/README.md để biết quy trình cgo hiện tại. Đường dẫn tiêu thụ mặc định sử dụng metadata pkg-config đã cài đặt; quá trình phát triển trong repo có thể sử dụng -tags repolocal với zig-out/lib. Ngoài ra còn có một ví dụ về truy xuất đồ thị/vector/văn bản có thể chạy được trong examples/go.

Các thay đổi gần đây về bề mặt binding đã chuyển các trình trợ giúp nhúng vào các module và subpackage chuyên biệt. Xem docs/client_api_migration.md để biết các lệnh import ưu tiên và các alias tương thích hiện tại.

Bắt đầu tại đây

Ví dụ

Một ví dụ hoàn chỉnh: tạo một đồ thị tri thức nhỏ với các tài liệu và tác giả, lưu trữ các embedding, đánh chỉ mục văn bản, sau đó truy vấn qua cả ba chế độ tìm kiếm.

Các ví dụ sử dụng trình trợ giúp hash_embed / hashEmbed / HashEmbed tích hợp sẵn để chúng có thể chạy mà không cần dịch vụ bên ngoài. Đây là một trình giữ chỗ mang tính xác định, không phải là một embedding ngữ nghĩa: văn bản tương tự không tạo ra các vector gần nhau, vì vậy ngưỡng khoảng cách là tùy ý và một truy vấn tương đồng có thể không khớp với bất kỳ kết quả nào. Hãy sử dụng một mô hình embedding thực tế cho bất kỳ mục đích nào cần kết quả có ý nghĩa — xem Working with Embeddings.

Python

TypeScript

Go

Hiệu năng

Được benchmark trên Apple M1, đơn luồng, với buffer pool tự động mở rộng. Chạy zig build benchmark để tái lập. Đối với khối lượng công việc đánh chỉ mục FTS các thuật ngữ lặp lại vốn trước đây bộc lộ hành vi append bậc hai, hãy chạy zig build fts-benchmark.

Các thao tác cốt lõi

Tìm kiếm Vector (HNSW) ở quy mô lớn

Vector cosine 128 chiều, M=16, ef_construction=200, ef_search=64, k=10. Chạy zig build vector-benchmark để tái lập.

Độ trễ tìm kiếm tăng theo tỷ lệ dưới tuyến tính (O(log N)) với recall@10 đạt 99–100%. Sử dụng phương pháp chọn láng giềng theo heuristic (Thuật toán 4 trong bài báo HNSW) để đảm bảo tính kết nối đồ thị đa dạng, đóng gói trang kết nối để giảm ~4,5 lần bộ nhớ và tích vô hướng đã chuẩn hóa trước để tính khoảng cách cosine nhanh chóng.

Độ nhạy ef_search (1 triệu vector)

Phân tích cạnh tranh

Tra cứu điểm (Point Lookups)

B+Tree của LatticeDB đạt tốc độ tra cứu trong bộ nhớ đệm dưới một micro giây, ngang bằng với RocksDB trong bộ nhớ và vượt trội hơn SQLite trên đĩa tới 23 lần.

Tìm kiếm Vector

LatticeDB ở quy mô 1 triệu đạt mức trung bình 0,83 ms với recall@10 đạt 100% — nhanh hơn HNSW đơn luồng của FAISS và cạnh tranh với các hệ thống dựa trên server như Weaviate và Qdrant (vốn phát sinh thêm chi phí mạng trong thực tế).

Duyệt đồ thị (Graph Traversal)

Chỉ các hàng của SQLite được đo lường trực tiếp trên cùng một máy và cùng một bộ công cụ. Các số liệu của Kuzu và Neo4j đến từ các bài đăng của bên thứ ba trên phần cứng và phương pháp luận mà chúng tôi không kiểm soát, vì vậy hãy coi chúng là định hướng về độ lớn thay vì kết quả benchmark chính thức.

LatticeDB so với SQLite — Đồ thị mạng xã hội với phân phối bậc theo luật lũy thừa, bộ nhớ đệm kề (adjacency cache) đã được làm nóng trước:

Quy mô nhỏ (10K nút, 50K cạnh)

Quy mô trung bình (100K nút, 500K cạnh)

Duyệt giới hạn độ sâu (10K nút, 50K cạnh)

LatticeDB sử dụng BFS với bộ nhớ đệm kề và theo dõi các nút đã ghé thăm bằng bitset. SQLite sử dụng CTE đệ quy với khử trùng lặp UNION. Cả hai đều tính toán các tập hợp nút có thể tiếp cận giống hệt nhau (~8K nút). Khoảng cách nới rộng ở các độ sâu lớn hơn khi chi phí CTE của SQLite tăng lên theo từng cấp độ đệ quy. Chạy zig build graph-benchmark -- --quick để tái lập.

Tìm kiếm toàn văn bản (BM25)