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>
This commit is contained in:
Kacper Łukawski
2023-02-28 11:59:22 +01:00
committed by GitHub
co-authored by qdrant
parent fe571ff1ad
commit 3691f76889
16 changed files with 155 additions and 1 deletions
@@ -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
![](/case_studies_data/bloop/screenshot.png)
[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.
![](/case_studies_data/bloop/bloop-logo.png)
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
![](/case_studies_data/bloop/qdrant-logo.png)
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.
![](/case_studies_data/bloop/vector-space.png)
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.
Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 56 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 25 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 40 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 87 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 519 KiB

Binary file not shown.

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 }}