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

pmc00

no profile record

投稿

[untitled]

1 ポイント·投稿者 pmc00·7 か月前·0 コメント

Foundry IQ: a knowledge layer for agents

techcommunity.microsoft.com
2 ポイント·投稿者 pmc00·8 か月前·0 コメント

Using an LLM for query planning in RAG –> 40% better answer relevance

techcommunity.microsoft.com
1 ポイント·投稿者 pmc00·昨年·0 コメント

[untitled]

1 ポイント·投稿者 pmc00·2 年前·0 コメント

Nearly 100x Compression for Vector Search with Minimal Quality Loss

techcommunity.microsoft.com
3 ポイント·投稿者 pmc00·2 年前·0 コメント

VoiceRAG: A pattern for RAG and voice with the GPT-4o Realtime API for audio

techcommunity.microsoft.com
11 ポイント·投稿者 pmc00·2 年前·0 コメント

Up to 11x vector database capacity increase in Azure AI Search, no price change

azure.microsoft.com
1 ポイント·投稿者 pmc00·2 年前·1 コメント

コメント

pmc00
·9 か月前·議論
Windows isn’t quite like Linux in that typically apps don’t make syscalls directly. Maybe you could say what’s in ntdll is the system call contract, but in practice you call the subsystem specific API, typically the Win32 API, which is huge compared to the Linux syscall list because it includes all sorts of things like UI, COM (!), etc.

The project has some of the properties discussed above such as not having a typical main() (or winmain), because there’s no CRT to call it.
pmc00
·9 か月前·議論
You can do this in Windows too, useful if you want tiny executables that use minimum resources.

I wrote this little systemwide mute utility for Windows that way, annoying to be missing some parts of the CRT but not bad, code here: https://github.com/pablocastro/minimute
pmc00
·9 か月前·議論
Fair point on latency, we (Azure AI Search) target both scenarios with different features. For instant search you can just do the usual hybrid + rerank combo, or if you want query rewriting to improve user queries, you can enable QR at a moderate latency hit. We evaluated this approach at length here: https://techcommunity.microsoft.com/blog/azure-ai-foundry-bl...

Of course, agentic retrieval is just better quality-wise for a broader set of scenarios, usual quality-latency trade-off.

We don't do SPLADE today. We've explored it and may get back to it at some point, but we ended up investing more on reranking to boost precision, we've found we have fewer challenges on the recall side.
pmc00
·昨年·議論
Code-golfed Game of Life in Javascript we wrote a while back with some friends. Always surprising how much abuse Javascript can take: https://shorterlife.github.io/challenge/
pmc00
·2 年前·議論
For another set of measurements that support RRF + Hybrid > vectors, we (Azure AI Search team) did a bunch of evaluations a few months ago: https://techcommunity.microsoft.com/t5/ai-azure-ai-services-...

We also included supporting data in that write up showing you can improve significantly on top of Hybrid/RRF using a reranking stage (assuming you have a good reranker model), so we shipped one as an optional step as part of our search engine.
pmc00
·2 年前·議論
(Disclaimer: I work in this team)

More details, including old vs new limits: https://techcommunity.microsoft.com/t5/ai-azure-ai-services-...
pmc00
·2 年前·議論
It depends on the scenario. For example, for concept-seeking queries, vectors tend to do better (less likely to be an overlap in words between query and content), whereas for keyword searches (a product name, a serial number, project codenames, etc.) BM25 + keywords does much better. If your workload is all concept-seeking queries, it's reasonable that keywords don't add much.

If you look at the table in the section "3. Hybrid Retrieval brings out the best of Keyword and Vector Search" of that article, we shared there the significant variability of metrics as a function of query types.
pmc00
·2 年前·議論
Here's a bit of a quantification of the point Doug makes. Indeed, for a number of scenarios you get better results if you combine vector search and keyword search into a hybrid retrieval step, and do reranking on top of that.

https://techcommunity.microsoft.com/t5/ai-azure-ai-services-...

(disclaimer: I work in that team)