Spring-ai QuestionAnswerAdvisor should be able to inject the document id and metadata into the prompt.

QuestionAnswerAdvisor only inserts the contents of the Documents into the prompt. It would be helpful to be able to include the document id and metadata.

When inserting Documents into a PromptTemplate, the object's .toString() method is automatically, used which includes the id and metadata.

return "Document{id='" + this.id + "', metadata=" + this.metadata + ", content='" + this.content + "', media=" + this.media + "}";

However, with QuestionAnswerAdvisor, it's only possible to include the content:

String documentContext =(String)documents.stream().map(Content::getContent).collect(Collectors.joining(System.lineSeparator()));

It is frequently useful to include the Document id as well as the Document metadata in the prompt so the LLM can use that information. So, it would be helpful if there were a way to tell QAA to include that information.

For the time-being, I'm using a simple hack to make it happen:

Document tempDoc = new Document(uri, text, metadata);
return new Document(uri, tempDoc.toString(), metadata);

Comment From: ThomasVitale

Using the new (experimental) Modular RAG features, it's possible to customise the way context is added to the final prompt in a RAG flow. The QueryAugmenter interface can be used to implement a custom strategy. More info: https://docs.spring.io/spring-ai/reference/api/retrieval-augmented-generation.html#_query_augmentation

You can then pass your custom implementation when building the RetrievalAugmentationAdvisor:

``` Advisor retrievalAugmentationAdvisor = RetrievalAugmentationAdvisor.builder() .documentRetriever(VectorStoreDocumentRetriever.builder() .vectorStore(vectorStore) .build()) .queryAugmenter(new MyCustomQueryAugmenter()) .build();

String answer = chatClient.prompt() .advisors(retrievalAugmentationAdvisor) .user(question) .call() .content(); ```

The default ContextualQueryAugmenter will soon support customising the context with document IDs and metadata, so that it's not necessary to implement an entirely new QueryAugmenter. I'll comment down here when that's delivered.