bhavnicksm

Hey there!

i just had a tiny nerd snipe thinking about why models tokens are priced a certain way.

tldr: its very complicated.

but wanted to suggest an alternate reality to the one we live in, maybe one where we can have fixed magins on costs.

Hope you like the read! :)

Hey! Author of the blog here.

This is pretty cool~ Thanks for suggesting this, I will read this in detail and add it to the next (0.5.0) release of memchunk.

thanks! this is still pretty early, please let us know if you face any issues with the library, database or anything else :)

it doesn't right now, but the fallback feature is planned for in a future release. mostly because there's no simple way to handle the classic fallbacks like aws, gcp and azure, and we wanted to spend some time thinking about their DX.

Hey!

Right now, some things are somewhat hard-coded to be Cloudflare compatible. If someone's willing, you can just deploy this without Cloudflare, but you'd need to dig into the code a little.

In the future releases, I'll make it possible to host it on VPCs and release a Dockerfile along with it, so that should help a little.

Thanks for checking the project out!

Yes, that's quite fair re:Cloudflare!

I couldn't find the right words to describe this, in comparison to something like Github Gist. I suppose "Own-your-data" since the D1 db generated is yours completely.

Happy to change the branding to be more reflective of this!

Thank you so much for giving Chonkie a chance! Just to note Chonkie is still in beta mode (with v0.1.2 running) with a bunch of things planned for it. It's an initial working version, which seemed promising enough to present.

I hope that you will stick with Chonkie for the journey of making the 'perfect' chunking library!

Thanks again!

I don't fully understand what you mean by "maximum length truncation of the string"; but if you're talking about splitting the sentence into 'chunks' which have token counts less than a pre-specified max_token length then, yes!

Is that what you meant?

TokenChunking is really limited by the tokenizer and less by the Chunking algorithm. Tiktoken tokenizers seem to do better with warm-up which Chonkie defaults to -- which is also what the 2nd one is using.

Algorithmically, there's not much difference in TokenChunking between Chonkie and LangChain or any other TokenChunking algorithm you might want to use. (except Llamaindex, I don't know what mess they made for 33x slower algo)

If you only want TokenChunking (which I do not recommend completely), better than Chonkie or LangChain, just write your own for production :) At least don't install 80MiB packages for TokenChunking, Chonkie is 4x smaller than them.

That's just my honest response... And these benchmarks are just the beginning, future optimizations on SemanticChunking which would increase the speed-up from the current 2nd (2.5x right now) to even higher.

That's pretty cool! I believe a research paper called LumberChunker recently evaluated that to be pretty decent as well.

Thanks for responding, I'll try to make it easier to use something like that in Chonkie in the future!

Just to clarify, the 21MB is the size of the package itself! Other package sizes are way larger.

Memory footprint of the chunking itself would vary widely based on the dataset, and it's not something we tested on... usually other providers don't test it either, as long as it doesn't bust up the computer/server.

If saving memory during runtime is important for your application, let me know! I'd run some benchmarks for it...

Thanks!

Right now, we haven't worked on adding support for code -- some things like comments (#, //) have punctuations that adversely affect chunking, along with indentation and other issues.

But, it's on the roadmap, so please hold on!

Haha~ thanks!