# Putting the co.embed API response directly as Qdrant method input
qdrant_client.upsert(
    collection_name="collection",
    points=rest.Batch(
        ids=[...],
        vectors=cohere_client.embed(...).embeddings,
        payloads=[...],
    ),
)

```

Both tools are easy to combine, so you can start working with semantic search in a few minutes, not days.

And what if your needs are so specific that you need to fine-tune a general usage model? Co.embed API goes beyond
pre-trained encoders and allows providing some custom datasets to
[customize the embedding model with your own data](https://docs.cohere.com/docs/finetuning).
As a result, you get the quality of domain-specific models, but without worrying about infrastructure.

## [Anchor](https://qdrant.tech/articles/qa-with-cohere-and-qdrant/\#system-architecture-overview) System architecture overview

In real systems, answers get vectorized and stored in an efficient vector search database. We typically don’t
even need to provide specific answers, but just use sentences or paragraphs of text and vectorize them instead.
Still, if a bit longer piece of text contains the answer to a particular question, its distance to the question
embedding should not be that far away. And for sure closer than all the other, non-matching answers. Storing the
answer embeddings in a vector database makes the search process way easier.

![Building the database of possible answers. All the texts are converted into their vector embeddings and those embeddings are stored in a vector database, i.e. Qdrant.](https://qdrant.tech/articles_data/qa-with-cohere-and-qdrant/vector-database.png)

## [Anchor](https://qdrant.tech/articles/qa-with-cohere-and-qdrant/\#looking-for-the-correct-answer) Looking for the correct answer

Once our database is working and all the answer embeddings are already in place, we can start querying it.
We basically perform the same vectorization on a given question and ask the database to provide some near neighbours.
We rely on the embeddings to be close to each other, so we expect the points with the smallest distance in the latent
space to contain the proper answer.

![While searching, a question gets vectorized by the same neural encoder. Vector database is a component that looks for the closest answer vectors using i.e. cosine similarity. A proper system, like Qdrant, will make the lookup process more efficient, as it won’t calculate the distance to all the answer embeddings. Thanks to HNSW, it will be able to find the nearest neighbours with sublinear complexity.](https://qdrant.tech/articles_data/qa-with-cohere-and-qdrant/search-with-vector-database.png)

## [Anchor](https://qdrant.tech/articles/qa-with-cohere-and-qdrant/\#implementing-the-qa-search-system-with-saas-tools) Implementing the QA search system with SaaS tools

We don’t want to maintain our own service for the neural encoder, nor even set up a Qdrant instance. There are SaaS
solutions for both — Cohere’s [co.embed API](https://docs.cohere.ai/reference/embed)
and [Qdrant Cloud](https://qdrant.to/cloud), so we’ll use them instead of on-premise tools.

### [Anchor](https://qdrant.tech/articles/qa-with-cohere-and-qdrant/\#question-answering-on-biomedical-data) Question Answering on biomedical data

We’re going to implement the Question Answering system for the biomedical data. There is a
_[pubmed\_qa](https://huggingface.co/datasets/pubmed_qa)_ dataset, with it _pqa\_labeled_ subset containing 1,000 examples
of questions and answers labelled by domain experts. Our system is going to be fed with the embeddings generated by
co.embed API and we’ll load them to Qdrant. Using Qdrant Cloud vs your own instance does not matter much here.
There is a subtle difference in how to connect to the cloud instance, but all the other operations are executed
in the same way.

```python
from datasets import load_dataset