I've tried alternatives like Diesel and sea-orm. To be honest, I feel like full-blown ORMs really aren't a very good experience in Rust. They work great for dynamic languages in a lot of cases, but trying to tie in a DB schema into Rust's type system often creates a ton of issues once you try to do anything more than a basic query.
It's got a nice little migration system too with sqlx-cli which is solid.
Most core functionality is finished, and it's ready to go. Still some work to go on docs, tutorials, and polish.
This whole repo is a single 300 LoC Python file over half of which is the system prompt and comments. It's not even a fine-tuned model or something, it's literally just a wrapper around llama-cpp with a very basic prompt tacked on.
I'm sure it's potentially useful and maybe even works, but I'm really sick of seeing these extremely low-effort projects posted and upvoted over and over.
With relatively minimal effort, I was able to spin up a little standalone container that wrapped around the service and exposed a basic API to parse a raw address string and return it as structured data.
Address parsing is definitely an extremely complex problem space with practically infinite edge cases, but libpostal does just about as well as I could expect it to.
Please Google/Demis/Sergei, just release the darn weights. This thing ain't gonna be curing cancer sitting behind an API and it's not gonna generate that much GCloud revenue when the model is this tiny.
Page 59 from the preprint[1]
Seems like they do intend to publish the weights actually
[1]: https://storage.googleapis.com/deepmind-media/papers/alphage...
Yeah sadly the stores the author talks about here aren't the right way to do things anymore in modern svelte and they're all-in on Runes.
Stores were a big part of the reason I liked svelte; they were so conceptually simple, extensible with plain JS, and made interop outside of Svelte trivial without the Svelte magic leaking out.
They're still in Svelte, but they mix poorly with runes and are basically unsupported in runes mode. I opened up a bug about store behavior not working like it used to when mixing with runes, and the response was pretty much "yeah we don't expect it to work like that anymore when runes mode is enabled".
TL;DR KANs are tricker to train than traditional neural networks, but they largely have similar loss values given equivalent parameter counts.
Part of this may be due to the fact that most of the optimizers and other components of the training stack have been tuned over decades for MLPs, and there may well be ways out there to get training to work even better for KANs.
I don't personally find a lot of appeal in KANs for big, deep models like LLMs or anything close to that scale. KANs and their B-Splines are much less hardware-friendly than matrix multiplication. However, they are interesting to me from an interpretability perspective, and there may be some unique possibilities there for smaller cases.