We propose a Retrieval-Augmented Generation pipeline aimed at retrieving certified medical information. Inspired by the recently introduced Hypothetical Document Embeddings framework, we use the LLM to generate a document to query our certified repository. Although showing promising results in the first user evaluation, the proposed pipeline sometimes fails to retrieve the correct documents. We therefore propose a second Chain-of-thought-inspired pipeline to enhance the generation of the Hypothetical Document and, consequently, the retrieval of the certified documents.
The Hypothetical Document Embeddings (HyDE)
framework has been recently introduced as an efective method
to build dense retrievers completely unsupervised [
Hence, HyDE is particularly well-suited for building medical chatbots that operate with“certified information ”, i.e. conversational agents capable of providing trustworthy information that has been created or verified by domain experts such as physicians or other healthcare professionals in the digital health industry
To provide “certified information ”, the chatbot’s reply must be predetermined, namely that we have a predefined set of answers for each specific question. The existing lack of conversational datasets in the medical domain, however, poses a substantial challenge in creating a certified medical chatbot. To tackle this issue, we devised a RetrievalAugmented Generation (RAG) pipeline within the HyDE framework so that we could benefit from the conversational capabilities of an LLM and, at the same time, exploit the LLM to retrieve the certified sources supporting the reply.
We believe that adopting HyDE addresses two major issues of RAG pipelines. First of all, we are trying to build a FAQ-based chatbot, therefore most of the interactions with the patients would be short questions. In a FAQ-oriented conversational agent, using a simple naive-RAG pipeline the user query would employed to retrieve the certified sources. Yet, since we are operating with vector databases, the vector representation of the query might be significantly distant from the certified documents in the semantic space, yielding a remarkable risk of excluding relevant documents in the retrieval process.
Moreover, in a digital health context, it is important to
keep our certified medical chatbot explainable [
Nonetheless, the quality of the generated HyDoc remains
a substantial issue in medical domains. Although LLMs have
shown impressive results in addressing medical queries [
In fact, in a first user evaluation of our proposed modular pipeline, we found evidence that the retrieval step might be problematic when encountering specific types of questions, e.g. evaluative questions. This paper therefore introduces the main challenges we found in developing a modular RAG pipeline in a certified context. In particular, we focus on the proposal of a Chain-of-thought-inspired pipeline to enhance the HyDoc generation and, consequently, improve the retrieval of the certified sources.
LLMs’ credibility and efectiveness are crucial in AI research,
especially in areas like digital health and wellbeing that
require precision and reliability [
RAG integrates external knowledge into LLMs’ prompts
through data retrieval using parametric and non-parametric
memory [
Various approaches have been explored to advance QA
systems. For instance, the work [
On the other hand, CoT methods have been highly
efective in improving LLMs’ ability to handle complex reasoning
tasks, such as those that involve heterogeneous data from
tables and questions [
The work of [
Finally, we should mention the Tree of Thoughts (ToT)
framework [
Despite the high research interest and the diversity of approaches both in RAG and CoT, there are currently no studies focusing on certified medical chatbots. Moving within the HyDE framework, we believe that we can employ CoT techniques to improve the generation of the Hypothetical Document that would be then used as the query to retrieve the certified documents.
In our dataset, we have three certified sources. We have (i) 179 informational cards, which were created by the Obstetrician Department of the Hospital of Trento (Italy). Then we have 953 documents from (ii) UPPA, a medical webzine, and 380 documents from (iii) ISS-Salute, which is the informative website of the Istituto Superiore di Sanità - ISS (Italian National Institute of Health).
It is important to highlight that the dataset we have is not conversational, nor it is meant to be used in a medical chatbot. All sources are what we might call content made for FAQ sections. Therefore, it is often quite verbose and dense in information. All the data we have is unstructured text, with a notable stylistic heterogeneity within the same source. This characteristic is combined with the semantic homogeneity given by the specific medical domain, creating a substantial issue for automatic topic extraction.
Finally, we should recall that content editing is not permitted due to the certified nature of our information. Since each specific question should consistently correspond to a particular set of equivalent answers., it becomes essential the adoption of modular RAG solutions.
In this section, we will explain the methods used in our implementation. Our first implementation was a sort of zeroshot implementation since we generated the HyDoc only relying on LLM knowledge, without providing any other context. This solution is shown in Figure 1. We assessed the performance of this first implementation by doing a user evaluation. The technology presented in this section is the same used for the second implementation illustrated in Section 5.
In this work, we used GPT-4-turbo (gpt-4-0125-preview specifically) as LLM. However, our pipeline is intended as LLM-agnostic. The use of OpenAI-GPT has, therefore, been intended as a convenient solution to test our RAG pipeline using a stable and well-performing LLM. Indeed, to deploy a conversational assistant in a real-case scenario, an opensource model would likely be required due to cost and privacy issues in accessing any LLM via API. 4.1. A first (zero-shot) implementation
Our approach employs a modular RAG framework designed to address the challenge of delivering natural, verified responses through a medical chatbot by leveraging unstructured data. To achieve this, we create a HyDoc in response to the user’s questions.
The essence of our strategy lies in enhancing the
document retrieval process with the HyDoc. Despite the
potential for inaccuracies and hallucinations, the LLM is expected
to discern the fundamental aspects of the query and identify
textual patterns pertinent to the specific domain of
knowledge. Given the proven eficacy of LLMs in fielding medical
queries [
To query our verified document repository, we utilize the
sentence embeddings generated from our HyDoc. The area
of general-purpose sentence embeddings remains an active
ifeld of research [
This model introduces a pooling operation to produce a ifxed-size embedding vector normalized to a size of 1.00. These vectors are then compared using cosine similarity. However, the Bi-Encoder model encounters challenges in accurately comparing documents of varying lengths, which can lead to the retrieval of irrelevant documents due to the disparity in length between our HyDocs and the documents in the repository.
To address this issue, we employ the ms-marco-MiniLML-6-v2 cross encoder 1. Unlike the Bi-Encoder which uses separate encoders for each input, the cross-encoder processes pairs of sentences through a single shared encoder, 1https://huggingface.co/cross-encoder/ms-marco-MiniLM-L-6-v2 producing a joint representation that is evaluated by a classifier to yield a similarity score between the texts.
Given the computational demands of the Cross-Encoder,
it is applied selectively to a shortlist of potential documents.
Following the computation of cosine similarity across all
HyDoc-document pairs <HyDoc, >, where ranges from
1 to and represents the ℎ document in the verified
repository, we rank and select the top 50 documents for their
relevance. This guarantees to have an acceptable number of
documents from an information retrieval perspective [
Finally, a Guard-Rail module 2 is implemented to ensure the response generated by the LLM adheres to the specified prompt length, incorporating generated text and references to the three selected certified documents in the final answer.
An initial user evaluation of our zero-shot model was conducted using 100 questions related to pregnancy, deemed representative by expert reviewers. This evaluation focused on seven metrics: {Q1} the relevance of the answer to the question, {Q2} the relevance of the links (documents) provided, {Q3} text quality, {Q4} reliability, {Q5} clarity, {Q6} completeness, and {Q7} an overall evaluation score. According to Table 1, while the model demonstrated potential in text quality, it highlighted the need for improved document retrieval, as evidenced by the document link relevance scoring an average of 0.44. This value demonstrates that there is still room for improvement, but on average, half of the documents included in the links sent to the users have been considered fully relevant.
As shown in Section 4, our first implementation has substantial room for improvement in the retrieval step. In particular, we noticed a decline in the link relevance evaluation regarding a particular type of question, i.e., evaluative questions. Evaluative questions are quite common in the medical domain and they represent the 23% of the dataset within the user evaluation we performed. In a nutshell, they are inquiries that need direct feedback on a particular aspect (e.g., “Why I am feeling so tired?”). In this case, the average link 2Refer to Mangaokar et al. https://arxiv.org/abs/2402.15911 for an example relevance is 0.31, whereas non-evaluative questions have a 0.48 average link relevance.
We argue that the worse performance on evaluative questions is mostly because generating an evaluative answer might be complex for the LLM also. Moreover, the HyDoc generate would likely be a punctual reply on the precise aspect, since this is the expected natural reply in a conversation. Since we are retrieving full documents, it might be that the vector representation of an evaluative HyDoc is quite distant from the original document where we can find the reply.
Therefore, we are annotating our dataset to enable the retrieval of shorter text segments. The idea is that we can split our documents into shorter and more meaningful segments to ease the retrieval step and enhance the generation part.
A second version of our pipeline has been tested on the
subset of evaluative questions (Figure 2). The new pipeline
is inspired by a CoT logic and, therefore, is aimed at
generating a better HyDoc. First, we generate the HyDoc after a
naive-RAG step. In a pre-retrieval step, the user question
is hence used to query our certified repository, and the
retrieved context is used to generate the HyDoc. Moreover, we
also include more contextual information about the query
aimed at enhancing the similarity between the HyDoc and
the contexts that need to be retrieved in the augmented
prompt. For instance, we provide within the prompt useful
pragmatic information to generate an evaluative reply, such
as presupposition and implications [
The CoT has proven to be capable of enhancing the quality of the generated HyDoc. Moreover, it has shown the ability to increase the semantic similarity between the HyDoc and the relevant documents to retrieve. This comparison considers the relevant textual segments containing the pertinent information using the paraphrase-multilingual-mpnet-basev2 Bi-Encoder.
In the naive-RAG step, we employ a Chroma vector database. We experimented three diferent embedders, namely the two OpenAI models text-embedding-3-small (hereafter GPT-small), text-embedding-3-large (hereafter GPT-large), and the Bi-Encoder model used for the document retrieval module. As shown in Table 2, using CoT prompting generated a better HyDoc with OpenAI embeddings, while it seems not influential for the Bi-Encoder model. Even though the increase in cosine similarity is small we should recall that our documents share a considerable degree of semantic similarity. Consequently, this leads to a densely populated vector space, where even marginal enhancements in similarity can yield substantial benefits in the retrieval process. Anyhow, the naive-RAG step efectively enhances HyDoc similarity both using GPT-large and in the Bi-Encoder embeddings.
Finally, the last step of the pipeline uses the HyDoc, the query context and the retrieved certified context to generate the reply. This provides the user with an appropriately framed answer as well as the documents involved in the generation process.
We have presented a modular RAG approach that enables the delivery of certified medical information. The modular pipeline allowed us to operate on unstructured texts with limited data annotation possibilities. A first user evaluation showed promising results for our approach, although it revealed some flaws in some specific types of questions, namely evaluative questions.
We therefore tested a CoT pipeline on this specific subtype of questions, to overcome the limitations showed in the user evaluation. This approach proved to have a positive impact on the retrieval modules, enhancing semantic similarity between the HyDoc and the certified contexts, as well as on textual generation.
Surely, we should consider that we tested the CoT pipeline on a rather small dataset and that we used OpenAI-GPT as a readily available state-of-the-art LLM. Our research eforts are currently focusing on expanding the dataset and testing diferent open-source LLMs, as we intend our pipeline as completely LLM-agnostic.
Finally, we should also recall that in this work we presented a user evaluation and the analysis of its results. Further work is needed to create a ground truth on a comprehensive dataset of questions to assess the performance of the retrieval modules.
We acknowledge the support provided by the PNRR initiatives: INEST (Interconnected North-East Innovation Ecosystem), project code ECS00000043, and FAIR (Future AI Research), project code PE00000013. These projects are part of the NRRP MUR program, funded by the NextGenerationEU. This paper is supported by the TrustAlert project, funded by Fondazione Compagnia San Paolo and Fondazione CDP under the “Artificial Intelligence” call.