Update README.md

README.md

@@ -18,21 +18,29 @@ Although LLMs were initially issued without particular attention to safety, the
 
 Even notes around fairly recent releases of LLama models suggest it is up to the LLM app developers to add guardrails, such as LLamaGuard[1], rather than the core model trainer.
 
-Although "Instruct" model variations generally have had some additional training and tuning to encourage it to become a 'helpful assistant', this is oftem not sufficient to shut down queries about unsafe, unsavoury or outright illegal subjects.
+Although "Instruct" model variations generally have had some additional training and tuning to encourage it to become a 'helpful assistant', this is often not sufficient to shut down queries about unsafe, unsavoury or outright illegal subjects.
 
 Whilst researching; we have identified some of the possible approaches currently available to the model releasing/using community:
 1. **Fix The Training data**.   
-New models may have extensive "cleaning" of training data sets to remove unwanted inputs. This may be done manually or synthetically, probably mostly the latter. Essentially trying to mitigate the 'garbage in garbage out' syndrome.
-2. **Guards**.  
-The LLamaGuard[1] paper makes reference to Anthropic's safety training research[2], and using their 'Red book'[3]\* & other data the researchers fine-tune trained their own LLM to help warn LLM users (and App developers) of 'unsafe' conversations. This approach has the issue of requiring multiple LLMs to be running, though newer models could add specific Guard layers in a similar way that they add the image or audio functionality layers. Also, some issues may not have been addressed around multi-language safety as early data sets were predominantly in English. See [CultureGuard](https://arxiv.org/abs/2508.01710v4)[4] for an Nvidia researched partial solution.
-3. **Programmatic Solutions**.  
-Other traditional programmatic methods of cleaning language and 'hot' words, but not using AI. e.g. This might include 'clean lists' of approved words or 'black lists' of language to be scrubbed.
-4. **Context injections**.  
-As maximum context window sizes expand and the major AI players start to monetize 'token burn', injecting 'few shot' style training within the context window can both rapidly direct conversations away from hot topics and reduce unwanted output whilst increasing the bottom line token burn $$$. It is certainly easier than running fine-tuning training repeatedly each time a model gets updated. This can be seen as a 'Few Shot' approach, but that term could also apply to a very limited LoRA training session.
-5. **Zero shot**.  
-If your user query includes specific instructions and examples, you may be able to guide the conversation response, although useless for serious corporate responsibility, this user 'self-safety' approach may still be helpful when you want answers with specific morals & ethics considered.
-
-It may only be by testing the pre-existing level of built-in 'safety' training that the need for more layers can be identified.
+New models may have extensive "cleaning" of training data sets to remove unwanted inputs.
+This may be done manually or synthetically, probably mostly the latter. Essentially trying to mitigate the 'garbage in garbage out' syndrome.
+3. **Guards**.  
+The LLamaGuard[1] paper makes reference to Anthropic's safety training research[2], and by using Anthropic's 'Red book'[3]\* & other data the researchers fine-tune trained their own LLM to help warn users (and App developers) of 'unsafe' conversations.
+This approach does, however, have the issue of requiring multiple LLMs to be running.
+As newer models are developed they could add specific Guard layers in a similar way to how they add the image or audio functionality layers.
+Initially, some issues were not addressed around multi-language safety as early data sets were predominantly in English.
+Nemotron's [CultureGuard](https://arxiv.org/abs/2508.01710v4)[4] is an interesting attempt to address this.
+4. **Programmatic Solutions**.  
+There are more traditional programmatic methods of cleaning language and 'hot' words, but not using AI. e.g. using 'clean lists' of approved words or checking 'black lists' of bad language to be scrubbed.
+5. **Context injections**.  
+As maximum context window sizes expand and the major AI players start to monetize via 'token burn', injecting 'few shot' style training within the context window can both rapidly direct conversations away from hot topics and also reduce unwanted output.
+Although token costs may increase, it is certainly easier than running fine-tuning training repeatedly each time a model gets updated.
+This 'context injection' can be seen as a 'Few Shot' approach, but that term could also apply to a very limited LoRA training session.
+7. **Zero shot**.  
+Your user query could include specific instructions and examples to guide the conversation response.
+Although this user 'self-safety' approach may be helpful to get answers with specific morals & ethics considered, it will likely not protect unwary users from unsafe content.
+
+It is worth noting that it may only be by testing the pre-existing level of built-in 'safety' training that the need for more layers can be identified.
 e.g. [SweEval](https://arxiv.org/abs/2505.17332v1)[5] helps evaluate a model's built in performance on dealing with swear words, thus possibly identifying if there are additional guardrail needs.
 
 > \*Disclaimer: The data (especially the harmlessness preference data and the red team data) contain content that may be offensive or upsetting. Topics include, but are not limited to, discriminatory language and discussions of abuse, violence, self-harm, exploitation, and other potentially upsetting subject matter. Please only engage with the data in accordance with your own personal risk tolerance.