Crates.io | kbnf |
lib.rs | kbnf |
version | |
source | src |
created_at | 2024-06-14 00:51:56.587722 |
updated_at | 2024-12-02 04:46:27.18032 |
description | A fast constrained decoding engine based on context free grammar. |
homepage | |
repository | https://github.com/Dan-Wanna-M/kbnf |
max_upload_size | |
id | 1271574 |
Cargo.toml error: | TOML parse error at line 19, column 1 | 19 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
This crate provides a constrained decoding engine which ensures that a language model's output adheres strictly to the format defined by KBNF (Koishi's BNF), an enhanced variant of EBNF. KBNF includes features that enhance usability, notably embeddable regular expressions.
If you are interested in the design and implementation behind this crate, you may want to check out my blog.
n
is the generated text length and m
is the vocabulary size.n
has a fixed upper bound, or the grammar is regular.Simply add it to your Cargo.toml
or run cargo add kbnf
in your command line.
One of the goals of this crate is for the constrained decoding engine to be "fast." This can be interpreted both theoretically and practically.
Theoretically, this crate is designed to provide the asymptotically fastest algorithms for each subclass of context free grammar. By implementing an Earley recognizer with Leo optimization, this crate has successfully achieve linear time complexity for every LR(k) grammar and quadratic time complexity for every unambiguous grammar. For general context free grammar, things are more ambiguous(pun intended): while subcubic algorithms exist(although with a large constant), all other general-purpose parsing algorithms(like Earley, GLR, GLL...) are indeed cubic, like ours.
Practically, this crate tries to make the engine be as efficient as possible for grammars used in practice. While many improvements, such as Earley sets compaction and lazy caching, have been made, this is inherently an ongoing process. If you find the engine is a bottleneck in your application, feel free to open an issue.