HackerTrans
トップ新着トレンドコメント過去質問紹介求人

breadislove

207 カルマ登録 2 年前

投稿

Asymmetric Quantization: Near-Lossless Retrieval with 97% Storage Reduction

mixedbread.com
109 ポイント·投稿者 breadislove·11 日前·44 コメント

Dense Retrievers Know More Than They Can Express

mixedbread.com
2 ポイント·投稿者 breadislove·先月·0 コメント

The whole point of OpenAI's Responses API is to help them hide reasoning traces

seangoedecke.com
2 ポイント·投稿者 breadislove·7 か月前·0 コメント

Boosting Claude: Faster, Clearer Code Analysis with MGrep

elite-ai-assisted-coding.dev
1 ポイント·投稿者 breadislove·8 か月前·0 コメント

Show HN: Mgrep – A Semantic, Multimodal Grep

github.com
6 ポイント·投稿者 breadislove·8 か月前·1 コメント

From Control to Resonance: Why I Let an AI Decode My Voice

substack.com
2 ポイント·投稿者 breadislove·9 か月前·0 コメント

Meta overhauls legacy AI operations

axios.com
7 ポイント·投稿者 breadislove·9 か月前·1 コメント

Fantastic (Small) Retrievers and How to Train Them

mixedbread.com
2 ポイント·投稿者 breadislove·9 か月前·0 コメント

Show HN: Semantic search over the National Gallery of Art

nga.demo.mixedbread.com
145 ポイント·投稿者 breadislove·9 か月前·37 コメント

Show HN: Search 4 Cute Cats

cats.mixedbread.com
2 ポイント·投稿者 breadislove·9 か月前·0 コメント

コメント

breadislove
·昨日·議論
adam, i'd like to get in touch and would love to run the benachmark with mixedbread as a search backend. we are doing this right now with a lot of compliance companies. would be very curious how it improves quality/cost e2e
breadislove
·8 日前·議論
yes, your are right. what heading would you have taken here?
breadislove
·8 日前·議論
everything worth writing, you should write yourself
breadislove
·9 日前·議論
ah whoops, I'll fix it. ty!
breadislove
·9 日前·議論
The ndcg loss is minimal 90.26 -> 89.65. This means it maintains most of the quality.
breadislove
·9 日前·議論
to which email did you send it? can u send it to support please?
breadislove
·9 日前·議論
this is the reason why we report ndcg and not recall. ndcg respects fine grained details so you get the an overview of how much details you are trading off since it would hurt the ranking.
breadislove
·9 日前·議論
yes exactly.
breadislove
·23 日前·議論
slop complaining about other slop
breadislove
·先月·議論
very bad take. with most modern multomodal models you get way better performance then going to text first
breadislove
·6 か月前·議論
this might be interesting: https://www.theinformation.com/articles/chatgpt-doctors-star...

> $150M RR on just ads, +3x from August. On <1M users.

source: https://x.com/ArfurRock/status/1999618200024076620
breadislove
·6 か月前·議論
a good system (like openevidence) indexes every paper released and semantic search can incredible helpful since the the search api of all those providers are extremely limited in terms of quality.

now you get why those system are not cheap. keeping indexes fresh, maintaining high quality at large scale and being extremely precise is challenging. by having distributed indexes you are at the mercy of the api providers and i can tell you from previous experience that it won't be 'currently accurate'.

for transparency: i am building a search api, so i am biased. but i also build medical retrieval systems for some time.
breadislove
·8 か月前·議論
you should check mixedbread out. we support indexing multimodal data and making data ready for ai. we are adding video and audio support by the end of the year. might be interesting for the OP as well.

we have couple investigative journalists and lawyers using us for a similar usecase.
breadislove
·9 か月前·議論
or deberta but nevertheless super interesting!
breadislove
·9 か月前·議論
For everyone wondering how good this and other benchmarks are:

- the OmniAI benchmark is bad

- Instead check OmniDocBench[1] out

- Mistral OCR is far far behind most Open Source OCR models and even further behind then Gemini

- End to End OCR is still extremely tricky

- composed pipelines work better (layout detection -> reading order -> OCR every element)

- complex table parsing is still extremely difficult

[1]: https://github.com/opendatalab/OmniDocBench
breadislove
·9 か月前·議論
we have extremely processing heavy jobs where user upload large collection of files (audios, pdfs, videos etc.) and expect to get fast processing. its just that we need to fan out sometimes, since a lot of our users a sensitive to processing times.
breadislove
·9 か月前·議論
We have extremely processing heavy jobs where user upload large collection of files (PDFs, audios, videos etc.) and expect to get fast processing.
breadislove
·9 か月前·議論
Hetzner is really great until you try to scale with them. We started building our service on top of Hetzner and had couple 100s of VMs running and during peak time we had to scale them to over 1000 VMs. And here couple of problems started, you get pretty often IPs which are black listed, so if you try to connect to services hosted by Google, AWS like S3 etc. you can't reach them. Also at one point there were no VMs available anymore in our region, which caused a lot of issues.

But in general if you don't need to scale crazy Hetzner is amazing, we still have a lot of stuff running on Hetzner but fan out to other services when we need to scale.
breadislove
·9 か月前·議論
yeah but if people would like to double check the results it would be nice to have the actual benchmark. especially given that your playground is broken...

"We ran into an error processing your request. Please try again"
breadislove
·9 か月前·議論
guys please release the benchmark or the benchmark code. like this is just "trust me bro"