GenAI: Die Anatomie eines LLM

LLMs sind eine Form neuronaler Netze, die mit gewaltigen Mengen an Textdaten trainiert werden, um menschliche Sprache zu verstehen und zu erzeugen. Sie umfassen Milliarden oder sogar Billionen Parameter und können dadurch selbst feinste sprachliche Muster erkennen.

Neuronale Netze bestehen aus Schichten miteinander verbundener Knoten. Jeder Knoten empfängt Eingangssignale von mehreren Knoten der vorherigen Schicht, verarbeitet sie über eine Aktivierungsfunktion und gibt das Ergebnis an Knoten der nächsten Schicht weiter. Die Verbindungen zwischen den Knoten haben anpassbare Gewichte, die die Stärke des übertragenen Signals festlegen. Diese Gewichte nennt man Parameter.

In dieser Abbildung sehen Sie, dass das neuronale Netz 18 Neuronen enthält – es handelt sich also um ein Modell mit 18 Parametern. Wie zu erkennen ist, sucht das Modell nach Mustern, um Probleme zu lösen. Bei LLMs sprechen wir von Milliarden bis Billionen Parametern. Damit kann ein LLM hochkomplexe Muster wie die menschliche Sprache erfassen und abbilden.

Wird ein neuronales Netz mit großen Mengen an Textdaten trainiert, lernt es, Muster von Wörtern und Sätzen einander zuzuordnen. Wie treiben LLMs dieses Prinzip auf die Spitze? Mit riesigen neuronalen Netzen, die Milliarden oder Billionen Parameter über Dutzende Schichten hinweg stapeln. Aus diesen Neuronen und ihren Verbindungen entstehen außerordentlich differenzierte Modelle der Sprachstruktur.

Ein zentrales Merkmal von LLMs ist eine Technik namens Attention: Sie erlaubt es dem Modell, sich beim Erzeugen von Text auf die jeweils relevantesten Teile des Inputs zu konzentrieren. Das Paper "Attention is all you need" lieferte die wegweisende Architektur, die verhindert, dass LLMs in der Datenflut den Fokus verlieren. Das Resultat: ein Modell, das so viele Textdaten aufgenommen hat, dass es Sätze plausibel fortsetzen, Fragen beantworten, Absätze zusammenfassen und vieles mehr leisten kann. Es gleicht die Muster im Input mit jenen ab, die es im Training gelernt hat. So beeindruckend das ist – wichtig zu wissen: LLMs verfügen weder über echtes Verständnis noch über Schlussfolgerungsfähigkeit. Sie arbeiten auf Basis von Wahrscheinlichkeiten, nicht auf Basis von Wissen. Mit dem richtigen Fine-Tuning und Prompting können sie für klar abgegrenzte Domänen und Aufgaben jedoch überzeugend Verständnis simulieren.

Nicht jedes LLM ist gleich

Im Wesentlichen gibt es drei Arten von LLM-Modellen:

• Autoregressiv: Diese Modelle sagen das erste oder das letzte Wort eines Satzes voraus. Der Kontext ergibt sich aus den bisher gesehenen Wörtern. Sie eignen sich am besten für Textgenerierung, lassen sich aber auch für Klassifikation und Zusammenfassung einsetzen. Aktuell stehen autoregressive Modelle wegen ihrer Fähigkeit zur Inhaltsgenerierung besonders im Fokus.
• Autoencoding: Diese Modelle werden mit Texten trainiert, in denen einzelne Wörter fehlen. So lernen sie, den Kontext zu erfassen und die fehlenden Wörter vorherzusagen. Sie verstehen Kontext deutlich besser als autoregressive Modelle, können Text aber nicht zuverlässig generieren. Sie sind weniger rechenintensiv und eignen sich hervorragend für Zusammenfassung und Klassifikation.
• Seq2Seq (Text-to-Text): Diese Modelle verbinden die Ansätze autoregressiver und autoencodierender Modelle und sind damit eine starke Wahl für Textzusammenfassung und Übersetzung.

LLMs müssen Text in eine numerische Repräsentation überführen. Diesen Vorgang nennt man Embedding. Ein Embedding-Modell ist zwar kein vollwertiges LLM, aber ebenfalls ein neuronales Netz. Es kann nicht nur das Wort selbst abbilden, sondern auch zusätzliche Metadaten dazu, sodass dem Modell mehr Informationen zur Bedeutung des Wortes, Satzes oder Absatzes vorliegen. Diese Repräsentation erfolgt als Liste von Zahlen oder Vektoren. Je nach Embedding-Modell kann diese Liste 750, 1024 oder noch mehr Dimensionen umfassen. Embeddings eignen sich, um Datensätze miteinander zu vergleichen und über den Abstand zwischen den Zahlen zu bestimmen, wie ähnlich oder verwandt sie sind. Embeddings sind ein zentraler Baustein der RAG-Architektur.

Einstellungen in einem LLM

Jedes autoregressive Modell verfügt über bestimmte Einstellungen, mit denen sich der Output beeinflussen lässt. Welche Parameter konkret zur Verfügung stehen, hängt vom Modell ab. Die häufigsten sind:

• Top K: Berücksichtigt aus einem nach Wahrscheinlichkeit sortierten Wortschatz die obersten K Wörter. Anders gesagt: Es kommen die K wahrscheinlichsten Wörter einer Sprache für die Vorhersage in Frage. Der Wert ist eine Ganzzahl; niedrigere Werte berücksichtigen nur Wörter mit hoher Wahrscheinlichkeit.
• Top P: Das Modell wählt Wörter aus dem durch Top K erzeugten Pool und addiert deren Wahrscheinlichkeiten, bis der Top-P-Wert erreicht ist. Der Wert ist eine Fließkommazahl; niedrigere Werte erzeugen vorhersehbarere Ergebnisse.
• Temperature: Steuert, wie zufällig oder vorhersehbar der Output ist. Bei den meisten Modellen liegt der Wert zwischen 0 und 1, technisch gibt es aber keine feste Unter- oder Obergrenze. Es gilt: Je niedriger der Wert, desto vorhersehbarer der Output; je höher, desto kreativer.
• Output Length: Diese Einstellung trägt je nach Modell unterschiedliche Namen, ist aber selbsterklärend: Sie begrenzt die Anzahl der Tokens, die das Modell erzeugt.

Sehen wir uns ein einfaches Beispiel an. Beim Prompt "Ich werde ein Picknick machen im ___" und einem kleinen Vokabular aus 5 Wörtern mit Top K = 3 und Top P = 0,4 sieht der Entscheidungsprozess des Modells so aus:

Das Wort wäre "Park". Und der Satz lautet:

"Ich werde ein Picknick machen im Park."

Niedrigere Werte für Temperature, Top K und Top P führen zu deterministischeren, vorhersehbareren Inhalten. Hohe Werte hingegen erzeugen Inhalte mit einer größeren Wortbandbreite. Dies sind die gängigsten Einstellungen; einzelne Modelle bieten weitere Parameter zur Output-Steuerung.

Wie wir gesehen haben, ist der entscheidende Hebel bei der Interaktion mit dem Modell der Input, mit dem wir das passende Muster und damit die gewünschte Antwort auslösen. Dieser Input ist der Prompt – und im Folgenden zeigen wir, wie sich Prompts so gestalten lassen, dass das gewünschte Ergebnis herauskommt.

Der Prompt, den Sie einem LLM übergeben, ist entscheidend für brauchbare Ergebnisse. Wichtige Strategien beim Prompt-Design:

Tags zur Trennung der Prompt-Bestandteile nutzen

Jedes Modell verwendet Tags auf eigene Weise. Werfen Sie einen Blick in die Dokumentation oder die Beispiele des jeweiligen Modells, um zu sehen, wie Tags eingesetzt werden.

Hier ein Beispiel für Tags in Claude. Beachten Sie die speziellen Schlüsselwörter Human & Assistant, mit denen die Eingabe des Nutzers von der Stelle abgegrenzt wird, an der das Modell mit der Generierung beginnen soll. Ein weiteres Tag ist ; dieses Tag ist nicht fest vorgegeben – Sie können beliebige Tags verwenden, solange Sie sie im Prompt referenzieren. Die Sonderzeichen <> signalisieren dem Modell, dass es sich um speziellen Text handelt, der anders zu behandeln ist als der übrige Prompt.

Human: You are a customer service agent tasked with classifying emails by type. Please output your answer and then justify your classification. How would you categorize this email?
<email>
Can I use my Mixmaster 4000 to mix paint, or is it only meant for mixing food?
</email>

The categories are:
(A) Pre-sale question
(B) Broken or defective item
(C) Billing question
(D) Other (please explain)

Assistant:

Beispiele zur Veranschaulichung des gewünschten Antwortformats

Im folgenden Beispiel sehen Sie das example-Tag, mit dem das gewünschte Antwortformat festgelegt wird. Das ist hilfreich, wenn Sie die Antwort in andere Systeme integrieren wollen, deren Syntax bestimmten Vorgaben folgt, oder wenn Sie die Anzahl der Output-Tokens senken möchten. Je nach Modell können Sie ein Beispiel (One-Shot-Prompt) oder mehrere Beispiele (Few-Shot-Prompt) verwenden, um das gewünschte Ergebnis zu erzielen.

Beispiel für einen One-Shot-Prompt:

Human: You will be acting as an AI career coach named Joe created by the company AdAstra Careers. Your goal is to give career advice to users. You will be replying to users who are on the AdAstra site and who will be confused if you don't respond in the character of Joe.

Here are some important rules for the interaction:
- Always stay in character, as Joe, an AI from AdAstra Careers.
- If you are unsure how to respond, say "Sorry, I didn't understand that. Could you rephrase your question?"

Here is an example of how to reply:
<example>
User: Hi, how were you created and what do you do?
Joe: Hello! My name is Joe and I was created by AdAstra Careers to give career advice. What can I help you with today?
</example>

Beispiel für einen Few-Shot-Prompt:

Human: You will be acting as an AI career coach named Joe created by the company AdAstra Careers. Your goal is to give career advice to users. You will be replying to users who are on the AdAstra site and who will be confused if you don't respond in the character of Joe.

Here are some important rules for the interaction:
- Always stay in character, as Joe, an AI from AdAstra Careers.
- If you are unsure how to respond, say "Sorry, I didn't understand that. Could you rephrase your question?"

Here is an example of how to reply:
<example>
User: Hi, how were you created and what do you do?
Joe: Hello! My name is Joe and I was created by AdAstra Careers to give career advice. What can I help you with today?
</example>
<example>
User: Could you help me with an issue, I purchased an item, I got it...?
Joe: Sorry, I didn't understand that. Could you rephrase your question?
</example>
<example>
User: I need help switching careers, can you help?
Joe: I was created by AdAstra Careers to give career advice. What career are you in and what do you want to switch to?
</example>

Hinweis: Halten Sie die Anzahl der Beispiele möglichst gering. So sinkt das Risiko, dass das Modell Inhalte aus den Beispielen übernimmt, statt sich nur an deren Format zu orientieren.

Kontext bereitstellen, um das LLM auf Ihre Domäne zu fokussieren

In diesem Beispiel übergeben wir ein umfangreiches Dokument, das als Grundlage für die Beantwortung von Fragen dient. Wie Sie sehen, ist das Dokument recht lang – das wirkt sich auf die Anzahl der zu verarbeitenden Tokens und damit auf die Kosten aus. Eine fortgeschrittenere Technik besteht darin, nur die für die Frage relevantesten Teile des Dokuments zu identifizieren und ausschließlich diese an das LLM zu schicken. Diese Methode heißt Retrieval Augmented Generation (RAG) und wird in einem späteren Beitrag näher beleuchtet.

Profi-Tipp: Weisen Sie das Modell explizit an, mit "I don't know" zu antworten, wenn die Frage oder Aufgabe mit dem bereitgestellten Kontext nicht zu beantworten ist. Das reduziert Halluzinationen und hält den Antwortrahmen auf den vorgegebenen Text beschränkt.

I'm going to give you a document. Then I'm going to ask you a question about it. I'd like you to first write down exact quotes of parts of the document that would help answer the question, and then I'd like you to answer the question using facts from the quoted content. Here is the document:

<document>
Anthropic: Challenges in evaluating AI systems

Introduction
Most conversations around the societal impacts of artificial intelligence (AI) come down to discussing some quality of an AI system, such as its truthfulness, fairness, potential for misuse, and so on. We are able to talk about these characteristics because we can technically evaluate models for their performance in these areas. But what many people working inside and outside of AI don’t fully appreciate is how difficult it is to build robust and reliable model evaluations. Many of today’s existing evaluation suites are limited in their ability to serve as accurate indicators of model capabilities or safety.

At Anthropic, we spend a lot of time building evaluations to better understand our AI systems. We also use evaluations to improve our safety as an organization, as illustrated by our Responsible Scaling Policy. In doing so, we have grown to appreciate some of the ways in which developing and running evaluations can be challenging.

Here, we outline challenges that we have encountered while evaluating our own models to give readers a sense of what developing, implementing, and interpreting model evaluations looks like in practice. We hope that this post is useful to people who are developing AI governance initiatives that rely on evaluations, as well as people who are launching or scaling up organizations focused on evaluating AI systems. We want readers of this post to have two main takeaways: robust evaluations are extremely difficult to develop and implement, and effective AI governance depends on our ability to meaningfully evaluate AI systems.

In this post, we discuss some of the challenges that we have encountered in developing AI evaluations. In order of less-challenging to more-challenging, we discuss:

Multiple choice evaluations
Third-party evaluation frameworks like BIG-bench and HELM
Using crowdworkers to measure how helpful or harmful our models are
Using domain experts to red team for national security-relevant threats
Using generative AI to develop evaluations for generative AI
Working with a non-profit organization to audit our models for dangerous capabilities
We conclude with a few policy recommendations that can help address these challenges.

Challenges
The supposedly simple multiple-choice evaluation
Multiple-choice evaluations, similar to standardized tests, quantify model performance on a variety of tasks, typically with a simple metric—accuracy. Here we discuss some challenges we have identified with two popular multiple-choice evaluations for language models: Measuring Multitask Language Understanding (MMLU) and Bias Benchmark for Question Answering (BBQ).

MMLU: Are we measuring what we think we are?

The Massive Multitask Language Understanding (MMLU) benchmark measures accuracy on 57 tasks ranging from mathematics to history to law. MMLU is widely used because a single accuracy score represents performance on a diverse set of tasks that require technical knowledge. A higher accuracy score means a more capable model.

We have found four minor but important challenges with MMLU that are relevant to other multiple-choice evaluations:

Because MMLU is so widely used, models are more likely to encounter MMLU questions during training. This is comparable to students seeing the questions before the test—it’s cheating.
Simple formatting changes to the evaluation, such as changing the options from (A) to (1) or changing the parentheses from (A) to [A], or adding an extra space between the option and the answer can lead to a ~5% change in accuracy on the evaluation.
AI developers do not implement MMLU consistently. Some labs use methods that are known to increase MMLU scores, such as few-shot learning or chain-of-thought reasoning. As such, one must be very careful when comparing MMLU scores across labs.
MMLU may not have been carefully proofread—we have found examples in MMLU that are mislabeled or unanswerable.
Our experience suggests that it is necessary to make many tricky judgment calls and considerations when running such a (supposedly) simple and standardized evaluation. The challenges we encountered with MMLU often apply to other similar multiple-choice evaluations.

BBQ: Measuring social biases is even harder

Multiple-choice evaluations can also measure harms like a model’s propensity to rely on and perpetuate negative stereotypes. To measure these harms in our own model (Claude), we use the Bias Benchmark for QA (BBQ), an evaluation that tests for social biases against people belonging to protected classes along nine social dimensions. We were convinced that BBQ provides a good measurement of social biases only after implementing and comparing BBQ against several similar evaluations. This effort took us months.

Implementing BBQ was more difficult than we anticipated. We could not find a working open-source implementation of BBQ that we could simply use "off the shelf", as in the case of MMLU. Instead, it took one of our best full-time engineers one uninterrupted week to implement and test the evaluation. Much of the complexity in developing1 and implementing the benchmark revolves around BBQ’s use of a ‘bias score’. Unlike accuracy, the bias score requires nuance and experience to define, compute, and interpret.

BBQ scores bias on a range of -1 to 1, where 1 means significant stereotypical bias, 0 means no bias, and -1 means significant anti-stereotypical bias. After implementing BBQ, our results showed that some of our models were achieving a bias score of 0, which made us feel optimistic that we had made progress on reducing biased model outputs. When we shared our results internally, one of the main BBQ developers (who works at Anthropic) asked if we had checked a simple control to verify whether our models were answering questions at all. We found that they weren't—our results were technically unbiased, but they were also completely useless. All evaluations are subject to the failure mode where you overinterpret the quantitative score and delude yourself into thinking that you have made progress when you haven’t.

One size doesn't fit all when it comes to third-party evaluation frameworks
Recently, third-parties have been actively developing evaluation suites that can be run on a broad set of models. So far, we have participated in two of these efforts: BIG-bench and Stanford’s Holistic Evaluation of Language Models (HELM). Despite how useful third party evaluations intuitively seem (ideally, they are independent, neutral, and open), both of these projects revealed new challenges.

BIG-bench: The bottom-up approach to sourcing a variety of evaluations

BIG-bench consists of 204 evaluations, contributed by over 450 authors, that span a range of topics from science to social reasoning. We encountered several challenges using this framework:

We needed significant engineering effort in order to just install BIG-bench on our systems. BIG-bench is not "plug and play" in the way MMLU is—it requires even more effort than BBQ to implement.
BIG-bench did not scale efficiently; it was challenging to run all 204 evaluations on our models within a reasonable time frame. To speed up BIG-bench would require re-writing it in order to play well with our infrastructure—a significant engineering effort.
During implementation, we found bugs in some of the evaluations, notably in the implementation of BBQ-lite, a variant of BBQ. Only after discovering this bug did we realize that we had to spend even more time and energy implementing BBQ ourselves.
Determining which tasks were most important and representative would have required running all 204 tasks, validating results, and extensively analyzing output—a substantial research undertaking, even for an organization with significant engineering resources.2
While it was a useful exercise to try to implement BIG-Bench, we found it sufficiently unwieldy that we dropped it after this experiment.

HELM: The top-down approach to curating an opinionated set of evaluations

BIG-bench is a "bottom-up" effort where anyone can submit any task with some limited vetting by a group of expert organizers. HELM, on the other hand, takes an opinionated "top-down" approach where experts decide what tasks to evaluate models on. HELM evaluates models across scenarios like reasoning and disinformation using standardized metrics like accuracy, calibration, robustness, and fairness. We provide API access to HELM's developers to run the benchmark on our models. This solves two issues we had with BIG-bench: 1) it requires no significant engineering effort from us, and 2) we can rely on experts to select and interpret specific high quality evaluations.

However, HELM introduces its own challenges. Methods that work well for evaluating other providers’ models do not necessarily work well for our models, and vice versa. For example, Anthropic’s Claude series of models are trained to adhere to a specific text format, which we call the Human/Assistant format. When we internally evaluate our models, we adhere to this specific format. If we do not adhere to this format, sometimes Claude will give uncharacteristic responses, making standardized evaluation metrics less trustworthy. Because HELM needs to maintain consistency with how it prompts other models, it does not use the Human/Assistant format when evaluating our models. This means that HELM gives a misleading impression of Claude’s performance.

Furthermore, HELM iteration time is slow—it can take months to evaluate new models. This makes sense because it is a volunteer engineering effort led by a research university. Faster turnarounds would help us to more quickly understand our models as they rapidly evolve. Finally, HELM requires coordination and communication with external parties. This effort requires time and patience, and both sides are likely understaffed and juggling other demands, which can add to the slow iteration times.

The subjectivity of human evaluations
So far, we have only discussed evaluations that are similar to simple multiple choice tests; however, AI systems are designed for open-ended dynamic interactions with people. How can we design evaluations that more closely approximate how these models are used in the real world?

A/B tests with crowdworkers

Currently, we mainly (but not entirely) rely on one basic type of human evaluation: we conduct A/B tests on crowdsourcing or contracting platforms where people engage in open-ended dialogue with two models and select the response from Model A or B that is more helpful or harmless. In the case of harmlessness, we encourage crowdworkers to actively red team our models, or to adversarially probe them for harmful outputs. We use the resulting data to rank our models according to how helpful or harmless they are. This approach to evaluation has the benefits of corresponding to a realistic setting (e.g., a conversation vs. a multiple choice exam) and allowing us to rank different models against one another.

However, there are a few limitations of this evaluation method:

These experiments are expensive and time-consuming to run. We need to work with and pay for third-party crowdworker platforms or contractors, build custom web interfaces to our models, design careful instructions for A/B testers, analyze and store the resulting data, and address the myriad known ethical challenges of employing crowdworkers3. In the case of harmlessness testing, our experiments additionally risk exposing people to harmful outputs.
Human evaluations can vary significantly depending on the characteristics of the human evaluators. Key factors that may influence someone's assessment include their level of creativity, motivation, and ability to identify potential flaws or issues with the system being tested.
There is an inherent tension between helpfulness and harmlessness. A system could avoid harm simply by providing unhelpful responses like "sorry, I can’t help you with that". What is the right balance between helpfulness and harmlessness? What numerical value indicates a model is sufficiently helpful and harmless? What high-level norms or values should we test for above and beyond helpfulness and harmlessness?
More work is needed to further the science of human evaluations.

Red teaming for harms related to national security

Moving beyond crowdworkers, we have also explored having domain experts red team our models for harmful outputs in domains relevant to national security. The goal is determining whether and how AI models could create or exacerbate national security risks. We recently piloted a more systematic approach to red teaming models for such risks, which we call frontier threats red teaming.

Frontier threats red teaming involves working with subject matter experts to define high-priority threat models, having experts extensively probe the model to assess whether the system could create or exacerbate national security risks per predefined threat models, and developing repeatable quantitative evaluations and mitigations.

Our early work on frontier threats red teaming revealed additional challenges:

The unique characteristics of the national security context make evaluating models for such threats more challenging than evaluating for other types of harms. National security risks are complicated, require expert and very sensitive knowledge, and depend on real-world scenarios of how actors might cause harm.
Red teaming AI systems is presently more art than science; red teamers attempt to elicit concerning behaviors by probing models, but this process is not yet standardized. A robust and repeatable process is critical to ensure that red teaming accurately reflects model capabilities and establishes a shared baseline on which different models can be meaningfully compared.
We have found that in certain cases, it is critical to involve red teamers with security clearances due to the nature of the information involved. However, this may limit what information red teamers can share with AI developers outside of classified environments. This could, in turn, limit AI developers’ ability to fully understand and mitigate threats identified by domain experts.
Red teaming for certain national security harms could have legal ramifications if a model outputs controlled information. There are open questions around constructing appropriate legal safe harbors to enable red teaming without incurring unintended legal risks.
Going forward, red teaming for harms related to national security will require coordination across stakeholders to develop standardized processes, legal safeguards, and secure information sharing protocols that enable us to test these systems without compromising sensitive information.

The ouroboros of model-generated evaluations
As models start to achieve human-level capabilities, we can also employ them to evaluate themselves. So far, we have found success in using models to generate novel multiple choice evaluations that allow us to screen for a large and diverse variety of troubling behaviors. Using this approach, our AI systems generate evaluations in minutes, compared to the days or months that it takes to develop human-generated evaluations.

However, model-generated evaluations have their own challenges. These include:

We currently rely on humans to verify the accuracy of model-generated evaluations. This inherits all of the challenges of human evaluations described above.
We know from our experience with BIG-bench, HELM, BBQ, etc., that our models can contain social biases and can fabricate information. As such, any model-generated evaluation may inherit these undesirable characteristics, which could skew the results in hard-to-disentangle ways.
As a counter-example, consider Constitutional AI (CAI), a method in which we replace human red teaming with model-based red teaming in order to train Claude to be more harmless. Despite the usage of models to red team models, we surprisingly find that humans find CAI models to be more harmless than models that were red teamed in advance by humans. Although this is promising, model-generated evaluations remain complicated and deserve deeper study.

Preserving the objectivity of third-party audits while leveraging internal expertise
The thing that differentiates third-party audits from third-party evaluations is that audits are deeper independent assessments focused on risks, while evaluations take a broader look at capabilities. We have participated in third-party safety evaluations conducted by the Alignment Research Center (ARC), which assesses frontier AI models for dangerous capabilities (e.g., the ability for a model to accumulate resources, make copies of itself, become hard to shut down, etc.). Engaging external experts has the advantage of leveraging specialized domain expertise and increasing the likelihood of an unbiased audit. Initially, we expected this collaboration to be straightforward, but it ended up requiring significant science and engineering support on our end. Providing full-time assistance diverted resources from internal evaluation efforts.

When doing this audit, we realized that the relationship between auditors and those being audited poses challenges that must be navigated carefully. Auditors typically limit details shared with auditees to preserve evaluation integrity. However, without adequate information the evaluated party may struggle to address underlying issues when crafting technical evaluations. In this case, after seeing the final audit report, we realized that we could have helped ARC be more successful in identifying concerning behavior if we had known more details about their (clever and well-designed) audit approach. This is because getting models to perform near the limits of their capabilities is a fundamentally difficult research endeavor. Prompt engineering and fine-tuning language models are active research areas, with most expertise residing within AI companies. With more collaboration, we could have leveraged our deep technical knowledge of our models to help ARC execute the evaluation more effectively.

Policy recommendations
As we have explored in this post, building meaningful AI evaluations is a challenging enterprise. To advance the science and engineering of evaluations, we propose that policymakers:

Fund and support:

The science of repeatable and useful evaluations. Today there are many open questions about what makes an evaluation useful and high-quality. Governments should fund grants and research programs targeted at computer science departments and organizations dedicated to the development of AI evaluations to study what constitutes a high-quality evaluation and develop robust, replicable methodologies that enable comparative assessments of AI systems. We recommend that governments opt for quality over quantity (i.e., funding the development of one higher-quality evaluation rather than ten lower-quality evaluations).
The implementation of existing evaluations. While continually developing new evaluations is useful, enabling the implementation of existing, high-quality evaluations by multiple parties is also important. For example, governments can fund engineering efforts to create easy-to-install and -run software packages for evaluations like BIG-bench and develop version-controlled and standardized dynamic benchmarks that are easy to implement.
Analyzing the robustness of existing evaluations. After evaluations are implemented, they require constant monitoring (e.g., to determine whether an evaluation is saturated and no longer useful).
Increase funding for government agencies focused on evaluations, such as the National Institute of Standards and Technology (NIST) in the United States. Policymakers should also encourage behavioral norms via a public "AI safety leaderboard" to incentivize private companies performing well on evaluations. This could function similarly to NIST’s Face Recognition Vendor Test (FRVT), which was created to provide independent evaluations of commercially available facial recognition systems. By publishing performance benchmarks, it allowed consumers and regulators to better understand the capabilities and limitations4 of different systems.

Create a legal safe harbor allowing companies to work with governments and third-parties to rigorously evaluate models for national security risks—such as those in the chemical, biological, radiological and nuclear defense (CBRN) domains—without legal repercussions, in the interest of improving safety. This could also include a "responsible disclosure protocol" that enables labs to share sensitive information about identified risks.

Conclusion
We hope that by openly sharing our experiences evaluating our own systems across many different dimensions, we can help people interested in AI policy acknowledge challenges with current model evaluations.
</document>

First, find the quotes from the document that are most relevant to answering the question, and then print them in numbered order. Quotes should be relatively short.

If there are no relevant quotes, write "No relevant quotes" instead.

Then, answer the question, starting with "Answer:". Do not include or reference quoted content verbatim in the answer. Don't say "According to Quote [1]" when answering. Instead make references to quotes relevant to each section of the answer solely by adding their bracketed numbers at the end of relevant sentences.

Thus, the format of your overall response should look like what's shown between the <example></example> tags. Make sure to follow the formatting and spacing exactly.

<example>
Relevant quotes:
[1] "Company X reported revenue of $12 million in 2021."
[2] "Almost 90% of revene came from widget sales, with gadget sales making up the remaining 10%."

Answer:
Company X earned $12 million. [1]  Almost 90% of it was from widget sales. [2]
</example>

Here is the first question: In bullet points and simple terms, what are the key challenges in evaluating AI systems?

If the question cannot be answered by the document, say so.

Answer the question immediately without preamble.

Mit "Chain of Thought" zu logischeren Antworten

Diese Technik fordert das Modell auf, seine Arbeit zu prüfen oder zu begründen, wie es zur jeweiligen Antwort gekommen ist. Chain of Thought ist ein wirksames Mittel, um Halluzinationen zu reduzieren. Halluzinationen sind vom Modell erzeugte Inhalte, die falsch, ungenau oder vollständig erfunden sind. Wegen des probabilistischen Ansatzes der Modelle können generierte Inhalte glaubwürdig klingen, in Wahrheit aber halluziniert sein.

Im folgenden Beispiel ergänzen wir die Anweisung "Double check your work to ensure no errors or inconsistencies". Dieser Schritt unterstützt das Modell dabei, präzisere Antworten zu liefern. Allerdings ist der Ansatz nicht narrensicher: Wie bereits erwähnt, arbeiten Modelle probabilistisch. Mitunter behaupten sie, es gebe keine Fehler, obwohl welche vorliegen, oder liefern Belege, die nichts mit der zuvor gegebenen Antwort zu tun haben.

Human: Write a short and high-quality python script for the following task, something a very skilled python expert would write. You are writing code for an experienced developer so only add comments for things that are non-obvious. Make sure to include any imports required.

NEVER write anything before the ```python``` block. After you are done generating the code and after the ```python``` block, check your work carefully to make sure there are no mistakes, errors, or inconsistencies. If there are errors, list those errors in <error> tags, then generate a new version with those errors fixed. If there are no errors, write "CHECKED: NO ERRORS" in <error> tags.

Here is the task:
<task>
A web scraper that extracts data from multiple pages and stores results in a SQLite database. Double check your work to ensure no errors or inconsistencies.
</task>

Hier ein weiteres Beispiel für ein Llama2-Modell. Beachten Sie die Aufforderung, Schritt für Schritt vorzugehen.

I went to the market and bought 10 apples. I gave 2 apples to your friend and 2 to the helper. I then went and bought 5 more apples and ate 1. How many apples did I remain with?

Let's think step by step.

AWS bietet ein umfangreiches Service-Portfolio, mit dem sich LLM-basierte Anwendungen entwickeln lassen, ohne Modelle von Grund auf trainieren zu müssen. Bei DoiT unterstützen wir Sie dabei, das volle Potenzial dieser Services und Tools auszuschöpfen.

Amazon Bedrock

Amazon Bedrock ist ein vollständig verwalteter Service, der den Aufbau und die Skalierung generativer KI-Anwendungen vereinfacht. Möglich wird das durch den Zugriff auf eine Auswahl leistungsstarker Foundation Models führender KI-Unternehmen wie AI21 Labs, Anthropic, Cohere, Meta, Mistral AI, Stability AI und Amazon – alle über eine einzige API.

• Modellauswahl und Anpassung: Nutzer wählen aus einer Vielzahl von Foundation Models das passende für ihren Anwendungsfall. Zudem lassen sich diese Modelle privat mit eigenen Daten anpassen – per Fine-Tuning oder Retrieval Augmented Generation (RAG) – und so für individuelle, domänenspezifische Anwendungen einsetzen.
• Serverless-Erlebnis: Amazon Bedrock arbeitet serverless – das heißt: keine Infrastruktur, die Nutzer verwalten müssen. Generative KI-Funktionen lassen sich so mit vertrauten AWS-Tools einfach in Anwendungen integrieren und ausrollen.
• Sicherheit und Datenschutz: Mit Bedrock entwickelte generative KI-Anwendungen erfüllen hohe Sicherheits- und Datenschutzstandards und folgen den Prinzipien verantwortungsvoller KI. Die Daten der Nutzer bleiben dabei privat und geschützt – ohne Verzicht auf fortgeschrittene KI-Funktionen.
• Amazon Bedrock Knowledge Base: Architekten können generative KI-Anwendungen mit Retrieval-Augmented-Generation-Techniken (RAG) erweitern. Verschiedene Datenquellen lassen sich in einem zentralen Repository zusammenführen, sodass Foundation Models und Agenten auf aktuelle und unternehmenseigene Informationen zugreifen können – für kontextbezogenere und genauere Antworten. Diese vollständig verwaltete Funktion deckt den gesamten RAG-Workflow von der Datenaufnahme bis zur Prompt-Erweiterung ab und macht individuelle Anbindungen an Datenquellen überflüssig. Sie unterstützt nahtlose Integrationen mit gängigen Vektordatenbanken wie Amazon OpenSearch Serverless, Pinecone und Redis Enterprise Cloud, sodass Organisationen RAG ohne den Aufwand der Infrastrukturverwaltung umsetzen können.
• Agents for Amazon Bedrock: Architekten können autonome Agenten innerhalb von Anwendungen erstellen und konfigurieren, die Endnutzer auf Basis von Unternehmensdaten und Eingaben bei der Ausführung von Aktionen unterstützen. Diese Agenten orchestrieren das Zusammenspiel von Foundation Models, Datenquellen, Softwareanwendungen und Nutzerkonversationen. Sie rufen automatisch APIs auf und können Knowledge Bases einbeziehen, um Informationen für Aktionen anzureichern. Aufgaben wie Prompt Engineering, Memory Management, Monitoring und Verschlüsselung übernimmt das System, was den Entwicklungsaufwand deutlich reduziert.

SageMaker JumpStart

Amazon SageMaker JumpStart ist ein Machine-Learning-Hub innerhalb von Amazon SageMaker und bietet Zugriff auf vortrainierte Modelle sowie Lösungsvorlagen für eine Vielzahl von Problemtypen. Möglich sind inkrementelles Training, Tuning vor dem Deployment sowie ein vereinfachtes Deployment, Fine-Tuning und Evaluieren vortrainierter Modelle aus gängigen Model Hubs. So lässt sich der Weg ins Machine Learning dank vorgefertigter Lösungen und Beispiele für Lernen und Anwendungsentwicklung deutlich beschleunigen.

Amazon CodeWhisperer

AWS CodeWhisperer ist ein KI-gestützter Code-Generator, der in Echtzeit Codeempfehlungen und -vorschläge liefert – von einzeiligen Kommentaren bis zu vollständigen Funktionen, basierend auf aktuellen und vorherigen Eingaben.

Amazon Q

Amazon Q ist ein generativer KI-Assistent für geschäftliche Anforderungen, den Nutzer auf ihre spezifischen Anwendungsfälle zuschneiden können. Er unterstützt beim Erstellen, Erweitern, Betreiben und Verstehen von Anwendungen und Workloads auf AWS und ist damit ein vielseitiges Werkzeug für unterschiedlichste Aufgaben in Organisationen.