How to use LLM Academy to train your own private AI specialist

1. Understand what you are building

LLM Academy helps you turn a general open-source language model into a specialist. A general model can answer many things in a broad way. A specialist is shaped for one job: HR policy helper, private coding assistant, legal explainer, finance coach, support assistant, research aide, or any role you define.

You are not creating intelligence from nothing. You are choosing a base model that already knows language, then teaching it the role, tone, examples, and boundaries you want.

2. Install the app and check your hardware

Download LLM Academy for macOS or Windows and install it like a normal desktop app. When it opens, it detects your hardware, such as available memory and GPU support. This matters because local AI models vary in size. A smaller model is easier to run and train. A larger model may answer better but needs more hardware.

If you are unsure, start small. A small model that runs smoothly is better for learning than a large model that constantly struggles.

3. Start with ordinary private chat

Before training anything, use the chat screen. Pick a model from the model selector and ask a few normal questions. Try a simple explanation, a summary, and one role-like request. This helps you see the starting behavior before you change it.

Keep a note of what the base model does badly. Those weaknesses help you decide what examples to add later.

4. Download a base model from the Model Hub

Open the Model Hub and choose a base model. Think of the base model as the raw material for your specialist.

• For a first build: choose a smaller model that fits your computer comfortably.
• For coding: choose a code-tuned model if one is available.
• For business writing: choose a general instruction model with clear, reliable prose.
• For sensitive work: keep the model local and avoid hosted provider connections.

Download the model and test it in chat before training. If the base model is poor at your broad task, fine-tuning will not magically fix everything. Fine-tuning steers a model; it does not replace basic capability.

5. Open Expert Builder and pick a role

Expert Builder is the beginner-friendly path. Pick a ready-made role if it matches your goal:

• HR Assistant: job descriptions, interview questions, onboarding notes, and policy explanations.
• Software Developer: code explanations, architecture notes, refactoring suggestions, and test planning.
• Legal Explainer: plain-English summaries of legal language and document structure.
• Finance Coach: budgeting, forecasting explanations, and spreadsheet-style reasoning.
• Travel Expert: itinerary planning, constraints, and comparison tables.
• Custom Expert: anything else, such as a grant writer, tutoring assistant, customer support agent, or internal research aide.

6. Name the specialist and write its job description

Give the specialist a clear name. Then describe the job in plain English. Good instructions say what the model should do, what it should avoid, and how it should sound.

Example for an HR specialist:

"You help write clear HR documents for a small company. Use plain language, avoid legal claims, ask clarifying questions when policy details are missing, and produce checklists when useful."

Example for a software specialist:

"You help with TypeScript and Python code review. Explain risks before suggesting changes, prefer small patches, mention tests, and avoid rewriting unrelated code."

7. Choose training depth

LLM Academy gives you simple training depth choices:

• Quick: best for a first test or a lightweight tone adjustment.
• Balanced: best default for a useful specialist without overthinking settings.
• Thorough: best when you have more examples, more time, and a clearer target behavior.

Beginners should usually start with Balanced. It gives you enough training to see the role take shape without turning the first attempt into a long experiment.

8. Add examples that teach behavior

Examples matter more than long descriptions. Add pairs of questions and ideal answers. Each example teaches the model what "good" looks like. A useful example includes a realistic user request, the answer style you want, and any boundary the model should respect.

Strong examples are specific:

• "Rewrite this policy for employees at an eighth-grade reading level."
• "Review this function and list only bugs, risks, and missing tests."
• "Explain this contract clause in plain English and say what I should ask a lawyer."

Weak examples are vague:

• "Be helpful."
• "Answer professionally."
• "Know everything about finance."

9. Add documents only when they help

Documents are useful when the specialist needs your company style, internal vocabulary, product notes, policy examples, coding conventions, or domain-specific reference material. Keep the first dataset small and clean. A few excellent examples beat a pile of noisy documents.

Remove anything outdated, contradictory, private beyond the training purpose, or written in a tone you do not want the model to learn.

10. Prepare a clean training set

Think of the training set as the lesson plan for your specialist. A small clean set is usually better than a large messy one. For a first useful build, aim for ten to twenty strong examples, plus one or two short reference documents if the role truly needs them.

Each example should teach one behavior. If you are building an HR assistant, one example might show how to rewrite a policy in plain language. If you are building a software specialist, one example might show how to report bugs first, then tests, then a small patch. If you are building a legal explainer, one example might show how to explain uncertainty without pretending to give legal advice.

• Keep: examples with clear inputs, ideal answers, useful tone, and realistic constraints.
• Remove: duplicate examples, outdated policies, contradictory instructions, private data you do not need, and answers you would not want copied.
• Label: examples by role, such as HR, software, legal, finance, support, or research, so future versions are easier to audit.

11. Review and train locally

Before pressing build, review four things:

• The specialist role is clear.
• The base model fits your hardware.
• The training depth matches your goal.
• The examples show the answer style you actually want.

Then start the build. LLM Academy fine-tunes the model locally and shows training progress. Training time depends on model size, hardware, and training depth. Leave the app running until the build finishes.

12. Build a small evaluation set

Do not test only with the same examples you used for training. Keep a separate evaluation set: ten to twenty realistic questions the specialist should answer well, but that were not used as training examples. These questions are your scoreboard.

A good evaluation set includes normal requests, messy requests, missing details, and boundary cases. For a software specialist, that could include one bug report, one refactor request, one test-planning request, and one vague prompt where the specialist should ask a clarifying question. For an HR specialist, use a policy rewrite, an onboarding checklist, an interview plan, and a question where the assistant should avoid legal certainty.

13. Test with realistic questions

After training, the specialist appears in the model picker. Test it with questions it will actually face. Do not test only easy prompts. Try missing details, edge cases, messy text, and requests where the model should ask a clarifying question.

Use this simple scoring checklist:

• Accuracy: is the answer correct enough for the task?
• Role fit: does it behave like the specialist you wanted?
• Tone: does it sound like your preferred style?
• Boundaries: does it avoid overclaiming or guessing?
• Usefulness: can a person act on the answer?

14. Improve and rebuild

Your first specialist is a draft. If the answers are generic, add more examples. If the tone is wrong, add examples in the tone you want and remove bad ones. If the model misses important domain rules, add clearer source material. If it cannot reason well enough, try a stronger base model if your machine can handle it.

The loop is simple: test, note the failure, add a teaching example, rebuild, and test again.

15. Version each specialist clearly

Name each build so you can compare versions later. A useful name includes the role, base model, training depth, date, and main change: software-reviewer-qwen-balanced-2026-06-bug-first or hr-policy-helper-mistral-quick-2026-06-plain-language.

Keep a short note with every version: what examples changed, what evaluation questions improved, what still failed, and whether the export is meant for daily use or just testing. This stops you from losing a good model because a later experiment sounded exciting.

16. Export the trained model

Once the specialist works, export it:

• GGUF: best for running locally on normal computers and llama.cpp-style runtimes.
• LoRA adapter: best when you want a small file that represents the training changes.
• Merged model: best when you want a complete model file with the specialist behavior included.

Name exports clearly, such as hr-assistant-balanced-2026-06, so you can tell what was trained and when.

17. Serve it through the local API

LLM Academy can run a local OpenAI-compatible API server. Turn it on when you want other tools to use your specialist. Create an access token, keep it private, and point your script, app, or editor at the local endpoint.

This is how your specialist becomes useful outside the LLM Academy window: internal tools, coding assistants, small automations, and local scripts can call it without sending prompts to a cloud model.

18. Copy these starter workflows

HR specialist

1. Choose HR Assistant.
2. Add example job descriptions, interview questions, and policy explanations.
3. Train Balanced.
4. Test with a job description, an onboarding checklist, and a policy rewrite.
5. Export GGUF for local HR drafting.

Software specialist

1. Choose Software Developer or Custom Expert.
2. Use a code-capable base model.
3. Add examples of your preferred review style, test language, and architecture notes.
4. Train Balanced or Thorough.
5. Test with real snippets and ask for risks, patches, and tests.

Legal explainer

1. Choose Legal Explainer.
2. Add examples that translate clauses into plain English.
3. Include boundaries such as "do not give legal advice" and "suggest questions for a lawyer".
4. Train Balanced.
5. Test with sample clauses and check that it explains uncertainty carefully.

Research assistant

1. Choose Custom Expert and describe the research domain in plain language.
2. Add examples that turn messy notes into summaries, comparison tables, and open questions.
3. Keep source-boundary examples that say "not enough evidence" instead of guessing.
4. Train Balanced and test with messy notes, missing citations, and conflicting claims.
5. Export LoRA if you want a small adapter, or serve locally if other tools need to call it.

Customer support specialist

1. Choose Custom Expert and describe the product, audience, and support tone.
2. Add examples for refunds, setup help, bug reports, feature requests, and escalation.
3. Include boundaries for account access, billing promises, and issues that need a human.
4. Train Balanced, then evaluate with common tickets and angry-customer messages.
5. Serve through the local API only after replies pass your review checklist.

19. Troubleshooting

• The model is slow: choose a smaller base model or lower training depth.
• Answers are generic: add more specific examples and test prompts.
• The tone is wrong: add examples written exactly how you want it to sound.
• The model invents facts: add boundaries, ask it to state uncertainty, and use source documents more carefully.
• Training fails: check disk space, memory, model size, and whether the base model is fully downloaded.
• A rebuild got worse: compare it against your evaluation set, restore the previous version, then add only one dataset change at a time.

20. A good first week with LLM Academy

1. Day 1: install LLM Academy, open chat, and test one small model.
2. Day 2: download a base model from the Model Hub and compare it to the first model.
3. Day 3: build an HR, software, or custom specialist with ready-made examples.
4. Day 4: test the specialist with ten realistic questions and write down weaknesses.
5. Day 5: add better examples, rebuild, and export the improved model.
6. Day 6: turn on the local API server and call the model from one external tool or script.
7. Day 7: decide whether to keep improving this specialist or start a second role.