quantike
Joined 3 years ago
Joined 3 years ago
Nice work, really happy to have found this today.
I'd be curious if there's some benefit to the runtime-memory utilization to baking in the precision of the vector if it's known at comptime/runtime. In my own usage of vector DBs I've only ever used a single-precision (f32), and often have a single, known dimension. But if Helix is aiming for something more general purpose, then it makes sense to offer the mixing of precision and dimension in the internals.
Cheers
I notice that in your core vector type (`HVector`), you choose to store the vector data as a `Vec<f64>`. Given what I have seen from most embedding endpoints, they return `f32`s. Is there a particular reason for picking `f64` vs `f32` here? Is the additional precision a way to avoid headaches down the line or is it something I am missing context for?
Really cool project, gonna keep reading the code.
I really dislike auto-play so I have always strategically rested my cursor in between the columns of video. Now, as I scroll, my cursor will end up within a column that is misaligned and start autoplay. The worst!
I am working on a similar use-case by creating a DuckDB extension that can stream from NATS JetsStream: https://github.com/quantike/duckstream
Still early days on feature support, but querying with SQL in DuckDB is the path I've been going.
I will need to give this a try.