Add bloop case study (#115)
* Add Bloop case study * Add draft variable * docs auto-sync * Fix YAML formatting * Add footnotes * Fix case studies layout * Add links to https://bloop.ai/ * Add images and change case studies layout * Reduce logo size * Add schema.org desc into case-studies * Add PNG as a social preview image * Resize social preview to 1200x627 --------- Co-authored-by: qdrant <qdrant@users.noreply.github.com>
@@ -0,0 +1,94 @@
|
||||
---
|
||||
title: "Qdrant case study: bloop semantic code search"
|
||||
short_description: bloop is a fast code-search engine that combines semantic search, regex search and precise code navigation
|
||||
description: bloop is a fast code-search engine that combines semantic search, regex search and precise code navigation
|
||||
social_preview_image: /case_studies_data/bloop/social_preview.png
|
||||
preview_dir: /case_studies_data/bloop/preview
|
||||
date: 2023-02-28T11:48:00.000Z
|
||||
---
|
||||
|
||||
Founded in early 2021, [bloop](https://bloop.ai/) was one of the first companies to tackle semantic
|
||||
search for codebases. A fast, reliable Vector Search Database is a core component of a semantic
|
||||
search engine, and bloop surveyed the field of available solutions and even considered building
|
||||
their own. They found Qdrant to be the top contender and now use it in production.
|
||||
|
||||
This document is intended as a guide for people who intend to introduce semantic search to a novel
|
||||
field and want to find out if Qdrant is a good solution for their use case.
|
||||
|
||||
## About bloop
|
||||
|
||||

|
||||
|
||||
[bloop](https://bloop.ai/) is a fast code-search engine that combines semantic search, regex search
|
||||
and precise code navigation into a single lightweight desktop application that can be run locally. It
|
||||
helps developers understand and navigate large codebases, enabling them to discover internal libraries,
|
||||
reuse code and avoid dependency bloat. bloop’s chat interface explains complex concepts in simple
|
||||
language so that engineers can spend less time crawling through code to understand what it does, and
|
||||
more time shipping features and fixing bugs.
|
||||
|
||||

|
||||
|
||||
bloop’s mission is to make software engineers autonomous and semantic code search is the cornerstone
|
||||
of that vision. The project is maintained by a group of Rust and Typescript engineers and ML researchers.
|
||||
It leverages many prominent nascent technologies, such as [Tauri](http://tauri.app), [tantivy](https://docs.rs/tantivy),
|
||||
[Qdrant](http://qdrant.tech) and [Anthropic](https://www.anthropic.com/).
|
||||
|
||||
## About Qdrant
|
||||
|
||||

|
||||
|
||||
Qdrant is an open-source Vector Search Database written in Rust . It deploys as an API service providing
|
||||
a search for the nearest high-dimensional vectors. With Qdrant, embeddings or neural network encoders
|
||||
can be turned into full-fledged applications for matching, searching, recommending, and many more solutions
|
||||
to make the most of unstructured data. It is easy to use, deploy and scale, blazing fast and is accurate
|
||||
simultaneously.
|
||||
|
||||
Qdrant was founded in 2021 in Berlin by Andre Zayarni and Andrey Vasnestov with the mission to power the
|
||||
next generation of AI applications with advanced and high-performant vector similarity search technology.
|
||||
Their flagship product is the vector search database which is available as an open source
|
||||
https://github.com/qdrant/qdrant or managed cloud solution https://cloud.qdrant.io/.
|
||||
|
||||
## The Problem
|
||||
|
||||
Firstly, what is semantic search? It’s finding relevant information by comparing meaning, rather than
|
||||
simply measuring the textual overlap between queries and documents. We compare meaning by comparing
|
||||
*embeddings* - these are vector representations of text that are generated by a neural network. Each document’s
|
||||
embedding denotes a position in a *latent* space, so to search you embed the query and find its nearest document
|
||||
vectors in that space.
|
||||
|
||||

|
||||
|
||||
Why is semantic search so useful for code? As engineers, we often don’t know - or forget - the precise terms
|
||||
needed to find what we’re looking for. Semantic search enables us to find things without knowing the exact
|
||||
terminology. For example, if an engineer wanted to understand “*What library is used for payment processing?*”
|
||||
a semantic code search engine would be able to retrieve results containing “*Stripe*” or “*PayPal*”. A traditional
|
||||
lexical search engine would not.
|
||||
|
||||
One peculiarity of this problem is that the **usefulness of the solution increases with the size of the code
|
||||
base** – if you only have one code file, you’ll be able to search it quickly, but you’ll easily get lost in
|
||||
thousands, let alone millions of lines of code. Once a codebase reaches a certain size, it is no longer
|
||||
possible for a single engineer to have read every single line, and so navigating large codebases becomes
|
||||
extremely cumbersome.
|
||||
|
||||
In software engineering, we’re always dealing with complexity. Programming languages, frameworks and tools
|
||||
have been developed that allow us to modularize, abstract and compile code into libraries for reuse. Yet we
|
||||
still hit limits: Abstractions are still leaky, and while there have been great advances in reducing incidental
|
||||
complexity, there is still plenty of intrinsic complexity[^1] in the problems we solve, and with software eating
|
||||
the world, the growth of complexity to tackle has outrun our ability to contain it. Semantic code search helps
|
||||
us navigate these inevitably complex systems.
|
||||
|
||||
But semantic search shouldn’t come at the cost of speed. Search should still feel instantaneous, even when
|
||||
searching a codebase as large as Rust (which has over 2.8 million lines of code!). Qdrant gives bloop excellent
|
||||
semantic search performance whilst using a reasonable amount of resources, so they can handle concurrent search
|
||||
requests.
|
||||
|
||||
## The Upshot
|
||||
|
||||
[bloop](https://bloop.ai/) are really happy with how Qdrant has slotted into their semantic code search engine:
|
||||
it’s performant and reliable, even for large codebases. And it’s written in Rust(!) with an easy to integrate
|
||||
qdrant-client crate. In short, Qdrant has helped keep bloop’s code search fast, accurate and reliable.
|
||||
|
||||
#### Footnotes:
|
||||
|
||||
[^1]: Incidental complexity is the sort of complexity arising from weaknesses in our processes and tools, whereas
|
||||
intrinsic complexity is the sort that we face when trying to describe, let alone solve the problem.
|
||||
@@ -279,7 +279,7 @@ client.clear_payload(
|
||||
## Payload indexing
|
||||
|
||||
To search more efficiently with filters, Qdrant allows you to specify payload fields as indexed.
|
||||
For marked fields will Qdrant will build an index for the corresponding types of queries.
|
||||
For marked fields Qdrant will build an index for the corresponding types of queries.
|
||||
|
||||
The indexed fields also affect the vector index. See [Indexing](../indexing) for details.
|
||||
|
||||
|
||||
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 17 KiB |
|
After Width: | Height: | Size: 56 KiB |
|
After Width: | Height: | Size: 25 KiB |
|
After Width: | Height: | Size: 40 KiB |
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 87 KiB |
|
After Width: | Height: | Size: 519 KiB |
|
After Width: | Height: | Size: 409 KiB |
@@ -0,0 +1,10 @@
|
||||
{{- partial "header.html" . -}}
|
||||
|
||||
{{- partial "second_header.html" . -}}
|
||||
|
||||
<div id="content">
|
||||
{{ block "main" . }}{{ end }}
|
||||
</div>
|
||||
|
||||
{{ partial "contact-section" . }}
|
||||
{{- partial "footer.html" . -}}
|
||||
@@ -0,0 +1,2 @@
|
||||
{{ define "main" }}
|
||||
{{ end }}
|
||||
@@ -0,0 +1,34 @@
|
||||
{{ partial "header" . }}
|
||||
<div class="auto-container pt-3 pt-md-2 mb-5">
|
||||
<div class="row clearfix">
|
||||
<!-- Content Side -->
|
||||
<section class="col-lg-12 col-md-12 col-sm-12">
|
||||
{{ .Scratch.Set "scope" "single" }}
|
||||
<article class="article article_narrow article_bb mb-4">
|
||||
<div class="article__cover mt-lg-5 mb-4">
|
||||
<picture>
|
||||
<source srcset="{{ .Params.preview_dir }}/title.webp" type="image/webp">
|
||||
<img src="{{ .Params.preview_dir }}/title.jpg">
|
||||
</picture>
|
||||
</div>
|
||||
<h1>{{ .Title }}</h1>
|
||||
{{ .Content }}
|
||||
</article>
|
||||
</section>
|
||||
</div>
|
||||
</div>
|
||||
<div style="background: var(--brand-light);">
|
||||
<div class="auto-container pt-5 pb-5">
|
||||
<div class="row clearfix pt-4">
|
||||
{{ range where site.Pages "Section" "articles" | first 3 }}
|
||||
|
||||
<!-- Project Block -->
|
||||
<div class="d-flex col-md-4 col-sm-12">
|
||||
{{ partial "article-card" (dict "context" .) }}
|
||||
</div>
|
||||
{{ end }}
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
{{ partial "contact-section" . }}
|
||||
{{ partial "footer" . }}
|
||||
@@ -91,6 +91,20 @@
|
||||
}]
|
||||
}
|
||||
</script>
|
||||
{{ else if and (eq .Section "case-studies") .IsPage }}
|
||||
<script type="application/ld+json">
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "Article",
|
||||
"headline": "{{ .Params.title }}",
|
||||
"image": [
|
||||
{{ .Params.social_preview_image | absURL }},
|
||||
],
|
||||
"abstract": {{ .Params.description }},
|
||||
"datePublished": {{ .Params.date }},
|
||||
"dateModified": {{ .Params.date }}
|
||||
}
|
||||
</script>
|
||||
{{ end }}
|
||||
|
||||
{{ $url := urls.Parse .Site.BaseURL }}
|
||||
|
||||