| >>Relying on such LLMs without understanding their internal logic creates a significant reliability risk. To build tools that work consistently, developers must understand the core principles that govern how the models process information and generate results. By mastering how a model processes information and how its internal settings influence the result, developers can move away from a trial-and-error approach toward a more precise one to ensure the AI tool handles complex data reliably. This is staggering bullshitp. In what way does understanding a transformer allow you to solve the core problem of LLM's that no frontier lab has managed to resolve? >>To fix the problem, retrieval-augmented generation (RAG) forces AI to look up information in a trusted source such as a company’s database. This also is bullshit. Yes, RAG helps and reduces errors, but NOOOO! it does not fix hallucinations... >>Prioritizing data security. When using AI with proprietary code, security is a major concern. Engineers must learn how to set up “private” instances of the models to ensure that sensitive company data stays within a secure cloud environment and is not used to train public versions. This is somewhat true, but really the motive is providing a soverign instance that cannot be withdrawn for arbitary reasons. Fundamentally the big providers are not going to steal your data, they may change the license to allow them to use it in the future, but then all their big customers will leave. So, they won't be able to, probably. What might well happen (and has happened) is that the USA might withdraw access with no notice leaving you high and dry. I want to learn to build a real LLM so I looked at https://allenai.org/olmo where there are instructions and ingredients. But, unfortunately I can't afford the required compute resource so I will have to wait for a bit I guess. |