What if your search box could understand what the ...
# feed
s
What if your search box could understand what the user actually means? Instead of sending a raw search query from the client and handling all the logic on the server, Vectora can understand the user's intent and turn it into a structured search request. Vectara is here to change that. With its new Query Understanding feature, search requests between client and server are significantly smoother and you get a much better ux for your application. vectora.cam github.com/ShadAdman/Vectora
❤️ 1
m
Hi @Shadman, really cool to see Vectora shipping Query Understanding 🔥 I couldn’t resist doing a small experiment and added SKaiNET as an additional engine: github.com/ShadAdman/Vectora/pull/23 (I’m the creator of SKaiNET — an open-source Kotlin/KMP ML stack focused on on-device use cases. Still alpha, but it’s already running as a PoC in a few apps.) Would love to hear what the biggest pain points were when building around TFLite/LiteRT, and where where a Kotlin-native ML stack might help. Feedback from people actually shipping this kind of thing is gold.
❤️ 1
s
Hi @Michal Harakal. thats realy cool. i'll check it out soon. thanks. nice library. wondering whats skainet using under the hood for inferance 🤔 whats the differ between skainet and my kflite?
m
Thanks! Glad you like it 🙂 Under the hood SKaiNET is a from-scratch Kotlin Multiplatform ML engine — its own tensors, ops, compute graph and execution backends. Models can be defined in Kotlin and executed eagerly or go through compilation paths. On the JVM, for example, the CPU backend can use SIMD via the Java Vector API when available. The main difference from KFlite is the layer they operate at: • KFlite provides a KMP abstraction around an existing inference runtime such as TFLite/LiteRT — you bring the model and the runtime executes it. • SKaiNET is the ML engine itself. In the Vectora PR, for example, it loads the BERT weights directly from SafeTensors/GGUF and executes the model through SKaiNET’s own tensor/runtime stack — there’s no TFLite involved. So they’re not necessarily direct competitors — they sit at different layers and could actually complement each other nicely. The motivation behind SKaiNET is making on-device ML/AI feel like a natural part of the Kotlin/KMP ecosystem, rather than something that always requires reaching through another runtime. Happy to dive deeper into any part if you’re curious 🙂
❤️ 1
s
@Michal Harakal interesting. thinking of adding it as another engine to kflite alongside litert, tflite and executorch.
❤️ 1
m
Oh, that would be really interesting 🙂 I think the architecture could fit nicely, KFlite as the unified KMP inference API, with SKaiNET as another engine alongside LiteRT / TFLite / ExecuTorch. Happy to help with the integration and figure out the cleanest boundary between the two if you decide to explore it. Feel free to ping me anytime, open an issue or reach out if you need anything on the SKaiNET side.
s
@Michal Harakal thanks
e
nice library. have you done any performance benchmark runs?
s
@Eric C thank you. not yet but it was in my mind. i'll add an issue for it