Finetuning updates to the QnA RAG Demo

[tybritten]

Provide a clear and concise description of the content changes you're proposing. List all the changes you are making
to the content.

• Updated QnA RAG Demo Section with the finetuning code for the embedding model as well as a notebook to run through.

Checklist:

• I have checked that my enhancements are not duplicates of existing content changes or additions.
• I have tested the changes in a working environment to ensure they function as intended.
• I have followed the style guide outlined in the contribution guidelines.

Reviewer's Tasks (for maintainers reviewing this PR):

• Verify that the tutorial functions correctly in a live environment.
• Verify that the updated content aligns with the style guide in the contribution guidelines.
• Check for consistency, grammar, and clarity throughout the updated content.
• Check that the related GitHub issue is up-to-date.

[tybritten]

@AlexanderOllman any changes to the notebook for the finetuning?

[dpoulopoulos]

Hey @tybritten,

Thank you for submitting this PR; it's concise and to the point—well done. Here's my feedback. Please make the necessary amendments, so we can proceed with merging:

• Ensure each commit is a release candidate, meaning the demo should run as expected when any commit is checked out. In your initial commit, you included a few "experiment files" which appear to be non-functional, as they are corrected in your subsequent commit. I recommend merging these two commits into one for coherence and to ensure each commit presents a functional state of the project.

• Consider the relevance of committing the Notebook separately. Since the Notebook is essential for running the experiment, it might be more practical to include it within the same commit as the related code. If you prefer organizing your contributions into multiple commits, ensure they are logically divided, such as keeping the Dockerfile separate. This approach facilitates targeted amendments, for example, exclusively updating the Dockerfile if necessary and referencing this commit.

• Before submitting, clear all outputs from the Notebook in accordance with our contribution guidelines, available at: https://github.com/HPEEzmeral/ezua-tutorials/blob/develop/CONTRIBUTING.md. This step is crucial as the outputs of a Notebook can blow up the memory used from an .ipynb. file.

• Aim for more informative commit messages. Your initial commit introduces six files and a few hundred lines of code without a clear description of their purpose. As it may become challenging to recall the specifics of these files in the future, it is important to provide a summary of the commit's content using an imperative tone. For instance, a descriptive commit message could start with:

  demos/rag: Introduce embeddings fine-tuning
  
  Include the Embeddings fine-tuning experiment files ...
  

[tybritten]

I'm not sure I'm following on the commit content/messages approach. Normally the PR is squashed and merged resulting in all the changes in a single commit.

[dpoulopoulos]

A PR may consist of varying numbers of commits, depending on the scope of the feature it addresses. For minor bug fixes, a single commit might suffice. However, the introduction of a significant new feature could involve dozens of commits.

However, this is orthogonal to the commit message. Regardless of whether your PR comprises a single commit or multiple, the commit message(s) should always be descriptive, clearly outlining the changes made. Thus, it's entirely feasible to consolidate your changes into a single, well-documented commit this time.

My suggestion is to squash everything into a single commit, document in the commit message what this demo is about, and force push it. Then, we can merge it.