Wenn Unternehmen künstliche Intelligenz erforschen, ist der erste ernsthafte Schritt normalerweise ein Proof of Idea (POC). Es handelt sich um eine strukturierte Methode, um zu testen, ob eine KI-Idee tatsächlich funktioniert, bevor viel Zeit und Price range in die umfassende Entwicklung investiert wird.

Aber es tauchen immer zwei Fragen auf:

• Wie viel kostet es?
• Wie stellen wir sicher, dass es gelingt?

Lassen Sie uns dies in praktischer Hinsicht aufschlüsseln.

Was ist ein KI-Proof of Idea?

Ein Proof of Idea ist ein kleines, fokussiertes Projekt, das darauf abzielt, zu testen, ob eine bestimmte KI-Idee technisch machbar ist und einen messbaren Wert liefern kann.

Es handelt sich nicht um ein fertiges Produkt. Es ist nicht für die vollständige Einführung beim Kunden gedacht. Stattdessen beantwortet es wichtige Fragen wie:

• Können unsere Daten diese Lösung unterstützen?
• Wird das Modell eine akzeptable Genauigkeit erreichen?
• Ist das erwartete Ergebnis realistisch?
• Lohnt es sich, weiter zu investieren?

Betrachten Sie es als ein strukturiertes Experiment mit Geschäftsabsicht.

Typische Kosten eines AI POC

Die Kosten für den Bau eines POC können je nach Komplexität erheblich variieren, die meisten Projekte liegen jedoch im Vergleich zur vollständigen Entwicklung in einem moderaten Investitionsbereich.

Im Allgemeinen werden die Kosten beeinflusst durch:

1. Datenbereitschaft

Wenn die Daten sauber, organisiert und zugänglich sind, geht das Projekt schneller voran und kostet weniger.
Wenn Daten bereinigt, gekennzeichnet oder umstrukturiert werden müssen, erhöht sich der Aufwand.

2. Komplexität des Issues

Ein einfaches Vorhersagemodell kostet weniger als ein System mit Pc Imaginative and prescient, Sprachmodellen oder mehreren Datenquellen.

3. Integrationsanforderungen

Wenn der POC isoliert getestet wird, bleiben die Kosten unter Kontrolle.
Wenn eine Verbindung zu Unternehmenssystemen, Sicherheitsebenen oder älteren Plattformen erforderlich ist, steigen die Kosten.

4. Infrastrukturbedarf

Cloud-Experimente sind in der Regel kostengünstig.
Hochleistungsrechnen oder GPU-lastige Arbeitslasten können die Kosten erhöhen.

Es ist auch wichtig zu bedenken, dass die Datenvorbereitung oft einen großen Teil des Aufwands in Anspruch nimmt – manchmal mehr als die Erstellung des Modells selbst.

So bauen Sie ein erfolgreiches KI-POC auf

Viele POCs scheitern nicht, weil die Idee schlecht ist, sondern weil der Ansatz unstrukturiert ist. Erfolg hängt mehr von Disziplin als von Technologie ab.

Beginnen Sie mit einem klaren Downside

Vermeiden Sie weitreichende Ambitionen wie „Betriebsabläufe mit KI verbessern“.
Definieren Sie stattdessen ein einziges messbares Ziel.

Zum Beispiel:

• Reduzieren Sie die Ausfallzeit der Ausrüstung um einen bestimmten Prozentsatz.
• Verbessern Sie die Prognosegenauigkeit über eine Basislinie hinaus.
• Bearbeitungszeit um einen definierten Betrag verkürzen.
• Klarheit verhindert spätere Verwirrung.

Bewerten Sie Daten frühzeitig

Bewerten Sie Ihre Daten ehrlich, bevor Sie Code schreiben.

Fragen:

• Gibt es genügend historische Daten?
• Ist es konsistent?
• Fehlen Felder?
• Ist es authorized verwendbar?

Schlechte Daten führen zu schlechten Ergebnissen.

Halten Sie das Zielfernrohr fest

Ein POC sollte einen fokussierten Anwendungsfall testen. Die Erweiterung des Umfangs mitten im Projekt erhöht die Kosten und verzögert die Ergebnisse.

Das Ziel ist Bestätigung, nicht Perfektion.

Alles messen

Definieren Sie Erfolgskennzahlen, bevor die Entwicklung beginnt.

• Verfolgen Sie während des POC Folgendes:
• Modellgenauigkeit
• Bearbeitungszeit
• Kosten professional Lauf
• Zuverlässigkeit unter verschiedenen Bedingungen

Ohne Kennzahlen können Sie den Wert nicht bewerten.

Planen Sie, was als nächstes kommt

Ein erfolgreicher POC sollte mehr als nur Ergebnisse liefern – er sollte Erkenntnisse liefern.

Am Ende des Prozesses sollten Sie Folgendes verstehen:

• Ob die Idee funktioniert
• Welche Verbesserungen nötig sind
• Was es braucht, um zu skalieren
• Die geschätzten Kosten für die vollständige Bereitstellung

Ein POC ist ein Entscheidungsinstrument.

5. Wählen Sie einen Companion mit praktischer Erfahrung

Die Zusammenarbeit mit erfahrenen Groups hilft, häufige Fallstricke zu vermeiden.

Bei Intellectyx beispielsweise kombinieren Groups Domänenverständnis mit praktischer KI-Ausführung, darunter:

• Anwendungsfallverfeinerung,
• Datenbereitschaftsbewertung,
• Prototypenentwicklung,
• Berichterstattung über messbare Ergebnisse.

Die Partnerschaft mit einem Anbieter, der technische Tiefe mit geschäftlichem Fokus in Einklang bringt, trägt dazu bei, dass Ziele effizient und ohne unnötige Kosten erreicht werden.

Häufige Fehler, die es zu vermeiden gilt

Beginn ohne klare Ziele

• Die Datenaufbereitung wird unterschätzt
• Ich versuche zu früh zu viel aufzubauen
• Überlegungen zur Skalierbarkeit werden ignoriert
• Messung des technischen Erfolgs, aber nicht der geschäftlichen Auswirkungen

Die erfolgreichsten Groups betrachten einen POC als geschäftliche Validierungsübung und nicht nur als technisches Experiment.

Letzte Gedanken

Ein AI Proof of Idea ist eine Investition in Klarheit. Es verringert die Unsicherheit, deckt verborgene Herausforderungen auf und schafft Vertrauen, bevor größere Entwicklungsanstrengungen unternommen werden.

Der wahre Wert eines POC besteht nicht nur darin, ob das Modell funktioniert, sondern in den gewonnenen Erkenntnissen über Machbarkeit, Kosten, Skalierbarkeit und potenzielle Auswirkungen.

Wenn ein POC mit klaren Zielen, diszipliniertem Umfang und messbaren Ergebnissen durchgeführt wird, wird er zur Grundlage für eine erfolgreiche KI-Einführung und nicht zu einem isolierten Experiment.

Wenn Sie nach einer budgetfreundlichen und zuverlässigen Choice für die KI-POC-Entwicklung suchen, kann die Partnerschaft mit Intellectyx eine praktische Möglichkeit sein, Ihre Idee zu validieren, die Kosten unter Kontrolle zu halten und fundierte Entscheidungen über Ihre KI-Investitionen zu treffen.

Viele Unternehmen verzögern Systemaktualisierungen, weil vorhandene Instruments funktionsfähig erscheinen. Berichte werden weiterhin generiert, Daten fließen weiterhin und tägliche Aufgaben werden erledigt. Finanzanalysen erzählen eine andere Geschichte. Wenn Führungskräfte über die oberflächliche Leistung hinausblicken, stellen sie oft fest, dass veraltete Systeme stillschweigend Ressourcen verbrauchen und verzerren Entscheidungsfindungund langsames Wachstum in einer Weise, die ohne tiefergehende Analyse schwer zu erkennen ist.

Der Produktivitätsverlust ist offensichtlich

Eine der häufigsten Erkenntnisse aus der Finanzanalyse ist Produktivitätsverlust. Ältere Systeme sind häufig auf manuelle Problemumgehungen angewiesen. doppelte Dateneingabeund tabellenbasierte Korrekturen. Diese Aufgaben verlängern die einzelnen Arbeitsabläufe um Minuten, aber Analysen zeigen, wie sich diese Minuten über Groups und Monate hinweg summieren.

Zeiterfassungs- und Kostenzuordnungsdaten zeigen oft, dass Mitarbeiter viel Zeit damit verbringen, Daten abzugleichen, Fehler zu korrigieren oder Informationen zwischen Systemen zu exportieren, die nicht intestine integriert sind. Die finanziellen Auswirkungen zeigen sich in höheren Arbeitskosten ohne entsprechende Produktionssteigerung, eine Lücke, die jahrelang unbemerkt bestehen bleiben kann.

Verzögerte Entscheidungen haben echtes finanzielles Gewicht

In datengesteuerten Umgebungen kommt es auf Geschwindigkeit an. Finanzanalysen verdeutlichen, wie veraltete Systeme den Zugriff auf genaue Informationen verlangsamen. Wenn die Erstellung von Berichten Tage statt Minuten dauert, basieren Entscheidungen auf historischen Momentaufnahmen und nicht auf aktuellen Bedingungen.

Diese Verzögerung wirkt sich auf die Preisgestaltung, die Bestandsverwaltung, den Investitionszeitpunkt und die Risikobewertung aus. Analysemodelle zeigen häufig verpasste Umsatzmöglichkeiten aufgrund verzögerter Erkenntnisse. Während diese Verluste selten als Einzelposten erscheinen, werden sie deutlich, wenn man Prognosegenauigkeit und Reaktionszeiten über Systemgenerationen hinweg vergleicht.

Fehlerraten und Compliance-Gefährdung

Bei älteren Plattformen mangelt es oft an automatisierter Validierung und Echtzeitüberwachung. Finanzanalysen können quantifizieren, wie die Fehlerraten steigen, wenn Systeme stark von manuellen Prozessen abhängen. Selbst kleine Ungenauigkeiten verursachen nachgelagerte Kosten durch Nacharbeiten, Audit-Anpassungen oder Compliance-Überprüfungen.

Für regulierte Branchen werden diese Risiken immer gravierender. Analytics-Dashboards kennzeichnen häufig Muster wie wiederkehrende Korrekturen oder verspätete Einreichungen, die auf Systemeinschränkungen zurückzuführen sind. Die Kosten für die Lösung dieser Probleme übersteigen in der Regel die Modernisierungskosten, bleiben jedoch verborgen, bis sie direkt gemessen werden.

Opportunitätskosten begrenzter Skalierbarkeit

Wenn Unternehmen wachsen, fällt es älteren Systemen schwer, sich zu skalieren. Finanzanalysen helfen dabei, die Kosten von Wachstumsreibungen zu isolieren. Dazu gehören ein langsameres Onboarding neuer Kunden, eine verzögerte Marktexpansion oder die Unfähigkeit, neue Dienste zu unterstützen.

Wenn Analytics die Leistung verschiedener Geschäftsbereiche mithilfe verschiedener Instruments vergleicht, wird die Lücke deutlich. Moderne Plattformen unterstützen erweiterte Prognosen, Automatisierung und Szenarioanalysen, mit denen ältere Systeme nicht mithalten können. Diese Unterschiede führen zu einer schnelleren Ausführung und einer besseren Kapitalnutzung.

Fragmentierte Daten verringern die strategische Klarheit

Getrennte Systeme erzeugen fragmentierte Datenansichten. Die Finanzanalyse zeigt, wie diese Fragmentierung die strategische Planung schwächt. Führungskräfte sehen möglicherweise Umsatztrends bei einem Device und Kostentreiber bei einem anderen, ohne eine einheitliche Perspektive zu haben.

Integrierte Plattformen, einschließlich Datenlösungen für die Vermögensverwaltungermöglichen es Unternehmen, Finanz-, Betriebs- und Kundendaten in einer einzigen Umgebung zu verbinden. Analysen aus diesen Systemen liefern klarere Einblicke in Rentabilitätstreiber und langfristige Leistungstrends, die isolierte Instruments verdecken.

Messung der tatsächlichen Kosten einer Verzögerung

Die tatsächlichen Kosten, die entstehen, wenn das System nicht gewechselt wird, erscheinen selten als einzelne Zahl. Finanzanalysen führen diese versteckten Kosten zusammen, indem sie verlorene Zeit, verpasste Chancen, erhöhte Risiken und langsameres Wachstum quantifizieren. Insgesamt überwiegen die Kosten einer Verzögerung oft die für die Änderung erforderlichen Investitionen.

Unternehmen, die sich zur Bewertung der Systemleistung auf Analysen verlassen, erhalten ein klareres Bild davon, wo der Wert sinkt. Mit dieser Transparenz können Führungskräfte über Annahmen hinausgehen und fundierte Entscheidungen zur Modernisierung treffen, die Genauigkeit, Agilität und langfristige Belastbarkeit unterstützen. Weitere Informationen finden Sie in der Infografik unten.

Das Downside der „schlechten Daten“ – im Jahr 2025 schärfer

Ihre KI-Roadmap könnte auf Folien großartig aussehen – bis sie mit der Realität kollidiert. Die meisten Entgleisungen sind auf Daten zurückzuführen: falsch beschriftete Stichproben, verzerrte Verteilungen, veraltete Datensätze, fehlende Metadaten, schwache Abstammung oder brüchige Auswertungssätze. Da LLMs von der Pilotphase zur Produktion übergehen und die Regulierungsbehörden die Messlatte höher legen, sind Datenintegrität und Beobachtbarkeit nun Themen auf Vorstandsebene und nicht mehr nur technische Fußnoten.

Shaip berichtete bereits vor Jahren darüber und warnte, dass „schlechte Daten“ die KI-Ambitionen sabotieren.

Diese Aktualisierung im Jahr 2025 bringt diesen Kerngedanken mit praktischen, messbaren Schritten voran, die Sie jetzt umsetzen können.

Wie „schlechte Daten“ in der echten KI-Arbeit aussehen

„Schlechte Daten“ sind nicht nur schmutzige CSVs. In der Produktions-KI wird es wie folgt angezeigt:

• Etikettenrauschen und niedrige IAA: Kommentatoren sind anderer Meinung; Anweisungen sind vage; Randfälle werden nicht behandelt.
• Klassenungleichgewicht und schlechte Abdeckung: Häufige Fälle dominieren, während seltene Hochrisikoszenarien fehlen.
• Veraltete oder abweichende Daten: Muster in der realen Welt ändern sich, Datensätze und Eingabeaufforderungen jedoch nicht.
• Schräglage und Leckage: Trainingsverteilungen stimmen nicht mit der Produktion überein; verfügt über Leckzielsignale.
• Fehlende Metadaten und Ontologien: Inkonsistente Taxonomien, undokumentierte Versionen und schwache Abstammung.
• Schwache Qualitätssicherungstore: Keine Goldsätze, Konsensprüfungen oder systematischen Prüfungen.

Dabei handelt es sich um branchenweit intestine dokumentierte Fehlermodi, die durch bessere Anweisungen, Goldstandards, gezielte Stichproben und Qualitätssicherungsschleifen behoben werden können.

Wie schlechte Daten KI (und Budgets) zerstören

Schlechte Daten verringern die Genauigkeit und Robustheit, lösen Halluzinationen und Abweichungen aus und erhöhen den MLOps-Arbeitsaufwand (Umschulungszyklen, Umbenennung, Pipeline-Debugging). Es zeigt sich auch in Geschäftskennzahlen: Ausfallzeiten, Nacharbeiten, Compliance-Gefährdung und geschwächtes Kundenvertrauen. Behandeln Sie dies als Datenvorfälle – nicht nur als Modellvorfälle – und Sie werden sehen, warum Beobachtbarkeit und Integrität wichtig sind.

• Modellleistung: Rubbish in führt immer noch zu Rubbish out – insbesondere bei datenhungrigen Deep-Studying- und LLM-Systemen, die vorgelagerte Fehler verstärken.
• Betriebswiderstand: Alarmmüdigkeit, unklare Eigentümerschaft und fehlende Abstammung machen die Reaktion auf Vorfälle langsam und teuer. Beobachtbarkeitspraktiken verkürzen die durchschnittliche Erkennungs- und Reparaturzeit.
• Risiko & Compliance: Vorurteile und Ungenauigkeiten können zu fehlerhaften Empfehlungen und Strafen führen. Datenintegritätskontrollen reduzieren die Gefährdung.

Ein praktischer 4-Stufen-Rahmen (mit Bereitschafts-Checkliste)

Verwenden Sie ein datenzentriertes Betriebsmodell, das aus Prävention, Erkennung und Beobachtbarkeit, Korrektur und Kuration sowie Governance und Risiko besteht. Nachfolgend finden Sie das Wesentliche für jede Part.

1. Prävention (Daten entwerfen, bevor sie kaputt gehen)

• Aufgabendefinitionen verschärfen: Spezifische, beispielreiche Anweisungen schreiben; Randfälle und „Beinaheunfälle“ aufzählen.
• Goldstandards und Kalibrierung: Bauen Sie ein kleines, originalgetreues Goldset. Annotatoren darauf kalibrieren; Ziel-IAA-Schwellenwerte professional Klasse.
• Gezielte Probenahme: Überbeprobung seltener, aber schwerwiegender Fälle; Stratifizieren Sie nach Geografie, Gerät, Benutzersegment und Schäden.
• Model alles: Datensätze, Eingabeaufforderungen, Ontologien und Anweisungen erhalten alle Versionen und Änderungsprotokolle.
• Datenschutz und Einwilligung: Zustimmung/Zweckbeschränkungen in Sammlungs- und Speicherpläne integrieren.

2. Erkennung und Beobachtbarkeit (Wissen, wann Daten schief gehen)

• Daten-SLAs und SLOs: Definieren Sie akzeptable Frische, Nullraten, Driftschwellenwerte und erwartete Volumina.
• Automatisierte Kontrollen: Schematests, Verteilungsdrift-Erkennung, Etikettenkonsistenzregeln und Referenzintegritätsmonitore.
• Vorfall-Workflows: Routing, Schweregradklassifizierung, Playbooks und Überprüfungen nach Vorfällen für Datenprobleme (nicht nur Modellprobleme).
• Abstammungs- und Wirkungsanalyse: Verfolgen Sie, welche Modelle, Dashboards und Entscheidungen das beschädigte Phase verbraucht haben.

Datenbeobachtbarkeitspraktiken – lange Zeit Normal in der Analytik – sind jetzt für KI-Pipelines unerlässlich, da sie Datenausfallzeiten reduzieren und das Vertrauen wiederherstellen.

3. Korrektur und Kuration (systematische Korrektur)

• Umetikettierung mit Leitplanken: Nutzen Sie Entscheidungsebenen, Konsensbewertung und Expertenprüfer für mehrdeutige Klassen.
• Aktives Lernen und Fehlersuche: Priorisieren Sie Proben, die das Modell unsicher findet oder die in der Produktion fehlerhaft sind.
• De-Dup und Rauschunterdrückung: Beinahe-Duplikate und Ausreißer entfernen; Taxonomiekonflikte in Einklang bringen.
• Arduous-Damaging-Mining und Augmentation: Schwachstellen im Stresstest; Fügen Sie Gegenbeispiele hinzu, um die Verallgemeinerung zu verbessern.

Diese datenzentrierten Schleifen übertreffen oft reine algorithmische Optimierungen, um reale Vorteile zu erzielen.

4. Governance & Risiko (Maintain it)

• Richtlinien und Genehmigungen: Änderungen der Ontologie, Aufbewahrungsregeln und Zugriffskontrollen dokumentieren; erfordern Genehmigungen für risikoreiche Schichten.
• Bias- und Sicherheitsaudits: Über geschützte Attribute und Schadenskategorien hinweg bewerten; Führen Sie Prüfpfade durch.
• Lebenszykluskontrollen: Einwilligungsverwaltung, PII-Handhabung, Arbeitsabläufe für den Zugriff auf Personen und Playbooks für Sicherheitsverletzungen.
• Sichtbarkeit der Führungskräfte: Vierteljährliche Überprüfungen zu Datenvorfällen, IAA-Tendencies und Modellqualitäts-KPIs.

Behandeln Sie die Datenintegrität als erstklassigen QS-Bereich für KI, um versteckte Kosten zu vermeiden, die sich stillschweigend ansammeln.

Readiness-Checkliste (schnelle Selbsteinschätzung)

• Klare Anweisungen mit Beispielen? Gold-Set gebaut? IAA-Ziel professional Klasse festgelegt?
• Stratifizierter Probenahmeplan für seltene/regulierte Fälle?
• Datensatz-/Eingabeaufforderungs-/Ontologieversionierung und -herkunft?
• Automatisierte Prüfungen auf Drift, Nullen, Schema und Etikettenkonsistenz?
• Definierte SLAs, Eigentümer und Playbooks für Datenvorfälle?
• Häufigkeit und Dokumentation von Bias-/Sicherheitsaudits?

Beispielszenario: Von lauten Etiketten zu messbaren Erfolgen

Kontext: Ein Help-Chat-Assistent eines Unternehmens hat Halluzinationen und übersieht Edge-Absichten (Rückerstattungsbetrug, Anfragen zur Barrierefreiheit). Anmerkungsrichtlinien sind vage; Der IAA beträgt ~0,52 für Minderheitenabsichten.

Intervention (6 Wochen):

• Anweisungen mit positiven/negativen Beispielen und Entscheidungsbäumen umschreiben; 150-teiliges Goldset hinzufügen; Trainieren Sie Annotatoren auf ≥0,75 IAA.
• Aktiv – lernen Sie 20.000 unsichere Produktionsausschnitte; mit Experten urteilen.
• Fügen Sie Driftmonitore hinzu (Absichtsverteilung, Sprachmischung).
• Erweitern Sie die Bewertung um harte Damaging (knifflige Rückerstattungsketten, kontroverse Formulierungen).

Ergebnisse:

• F1 +8,4 Punkte insgesamt; Rückruf aufgrund von Minderheitsabsichten +15,9 Punkte.
• Tickets im Zusammenhang mit Halluzinationen −32 %; MTTR für Datenvorfälle –40 % dank Observability und Runbooks.
• Nach dem Hinzufügen von Zustimmungs- und PII-Prüfungen wird die Compliance auf −25 % gesetzt.

Schnelle Gesundheitschecks: 10 Anzeichen dafür, dass Ihre Trainingsdaten nicht bereit sind

1. Doppelte/quick doppelte Elemente erhöhen das Vertrauen.
2. Etikettenrauschen (niedriger IAA) bei Schlüsselklassen.
3. Schweres Klassenungleichgewicht ohne Ausgleich von Bewertungsabschnitten.
4. Fehlende Randfälle und kontradiktorische Beispiele.
5. Datensatzdrift im Vergleich zum Produktionsverkehr.
6. Voreingenommene Stichprobe (Geografie, Gerät, Sprache).
7. Merkmalsleckage oder sofortige Kontamination.
8. Unvollständige/instabile Ontologie und Anweisungen.
9. Schwache Herkunft/Versionierung über Datensätze/Eingabeaufforderungen hinweg.
10. Fragile Bewertung: kein Goldsatz, keine harten Damaging.

Wo Shaip passt (leise)

Wenn Sie Skalierbarkeit und Wiedergabetreue benötigen:

• Beschaffung im großen Maßstab: Mehrdomänenübergreifende, mehrsprachige, einvernehmliche Datenerfassung.
• Expertenkommentar: Domänen-KMU, mehrschichtige Qualitätssicherung, Entscheidungsworkflows, IAA-Überwachung.
• Voreingenommenheits- und Sicherheitsaudits: Strukturierte Überprüfungen mit dokumentierten Abhilfemaßnahmen.
• Sichere Pipelines: Compliance-bewusster Umgang mit sensiblen Daten; nachvollziehbare Herkunft/Versionierung.

Wenn Sie die ursprüngliche Shaip-Leitlinie für 2025 modernisieren, wird sie sich folgendermaßen weiterentwickeln – von einem warnenden Rat zu einem messbaren, geregelten Betriebsmodell.

Abschluss

KI-Ergebnisse werden weniger von modernsten Architekturen als vielmehr vom Zustand Ihrer Daten bestimmt. Im Jahr 2025 werden die Organisationen, die mit KI gewinnen, diejenigen sein, die Datenprobleme verhindern, erkennen und beheben – und dies mit Governance beweisen. Wenn Sie bereit sind für diesen Wandel, lassen Sie uns gemeinsam Ihre Trainingsdaten und Ihre QA-Pipeline einem Stresstest unterziehen.

Kontaktieren Sie uns noch heute, um Ihre Datenanforderungen zu besprechen.

Große Sprachmodelle (LLMs) wie ChatGPT können quick sofort einen Aufsatz schreiben oder ein Menü planen. Aber bis vor Kurzem conflict es auch leicht, sie zu überlisten. Die Modelle, die auf Sprachmustern basieren, um auf Benutzeranfragen zu reagieren, scheiterten oft bei mathematischen Problemen und waren nicht intestine im komplexen Denken. Plötzlich sind sie jedoch in diesen Dingen viel besser geworden.

Eine neue Era von LLMs, sogenannte Reasoning-Modelle, wird trainiert, um komplexe Probleme zu lösen. Wie Menschen brauchen sie etwas Zeit, um über Probleme wie diese nachzudenken – und bemerkenswerterweise haben Wissenschaftler am McGovern Institute for Mind Analysis des MIT herausgefunden, dass die Arten von Problemen, die die meiste Verarbeitung durch Argumentationsmodelle erfordern, genau die gleichen Probleme sind, mit denen sich Menschen Zeit lassen müssen. Mit anderen Worten, sie berichten heute im Journal PNASDie „Denkkosten“ für ein Argumentationsmodell ähneln den Denkkosten für einen Menschen.

Die Forscher unter der Leitung von Evelina Fedorenkoaußerordentlicher Professor für Gehirn- und Kognitionswissenschaften und Forscher am McGovern Institute, kommt zu dem Schluss, dass Argumentationsmodelle in mindestens einer wichtigen Hinsicht einen menschenähnlichen Denkansatz haben. Sie weisen darauf hin, dass dies nicht beabsichtigt sei. „Menschen, die diese Modelle bauen, ist es egal, ob sie es wie Menschen machen. Sie wollen einfach nur ein System, das unter allen möglichen Bedingungen zuverlässig funktioniert und korrekte Reaktionen liefert“, sagt Fedorenko. „Die Tatsache, dass es eine gewisse Konvergenz gibt, ist wirklich ziemlich bemerkenswert.“

Argumentationsmodelle

Wie viele Formen der künstlichen Intelligenz sind die neuen Argumentationsmodelle künstliche neuronale Netze: Rechenwerkzeuge, die lernen, Informationen zu verarbeiten, wenn ihnen Daten und ein zu lösendes Drawback gegeben werden. Künstliche neuronale Netze waren bei vielen Aufgaben, die die neuronalen Netze des Gehirns intestine erledigen, sehr erfolgreich – und in einigen Fällen haben Neurowissenschaftler herausgefunden, dass diejenigen, die die besten Leistungen erbringen, bestimmte Aspekte der Informationsverarbeitung im Gehirn gemeinsam haben. Dennoch argumentierten einige Wissenschaftler, dass künstliche Intelligenz nicht bereit sei, komplexere Aspekte der menschlichen Intelligenz zu übernehmen.

„Bis vor kurzem gehörte ich zu den Leuten, die sagten: ‚Diese Modelle sind wirklich intestine in Dingen wie Wahrnehmung und Sprache, aber es wird noch ein langer Weg sein, bis wir neuronale Netzwerkmodelle haben, die schlussfolgern können“, sagt Fedorenko. „Dann entstanden diese großen Denkmodelle, und sie scheinen bei vielen dieser Denkaufgaben, wie dem Lösen mathematischer Probleme und dem Schreiben von Computercode, viel besser zu sein.“

Andrea Gregor de Varda, a Ok. Lisa Yang ICoN Middle Fellow und Postdoktorand in Fedorenkos Labor erklärt, dass Argumentationsmodelle Probleme Schritt für Schritt lösen. „Irgendwann wurde den Leuten klar, dass Modelle mehr Platz benötigen, um die eigentlichen Berechnungen durchzuführen, die zur Lösung komplexer Probleme erforderlich sind“, sagt er. „Die Leistung wurde viel, viel besser, wenn man die Modelle die Probleme in Teile zerlegen ließ.“

Um Modelle zu ermutigen, komplexe Probleme in Schritten zu bearbeiten, die zu richtigen Lösungen führen, können Ingenieure Reinforcement Studying einsetzen. Während ihres Trainings werden die Modelle für richtige Antworten belohnt und für falsche bestraft. „Die Modelle erkunden den Problemraum selbst“, sagt de Varda. „Die Handlungen, die zu positiven Belohnungen führen, werden verstärkt, sodass sie häufiger zu richtigen Lösungen führen.“

Auf diese Weise trainierte Modelle sind viel wahrscheinlicher als ihre Vorgänger, dass sie zu den gleichen Antworten kommen wie ein Mensch, wenn ihnen eine Denkaufgabe gestellt wird. Ihre schrittweise Problemlösung bedeutet zwar, dass Reasoning-Modelle etwas länger brauchen können, um eine Antwort zu finden als die LLMs davor – aber da sie die richtigen Antworten erhalten, wo die vorherigen Modelle versagt hätten, lohnt sich das Warten auf ihre Antworten.

Dass die Modelle eine gewisse Zeit benötigen, um komplexe Probleme zu lösen, weist bereits auf eine Parallele zum menschlichen Denken hin: Wenn man von einer Individual verlangt, ein schwieriges Drawback sofort zu lösen, würde sie wahrscheinlich ebenfalls scheitern. De Varda wollte diesen Zusammenhang systematischer untersuchen. Additionally gab er Denkmodellen und menschlichen Freiwilligen die gleichen Aufgaben und verfolgte nicht nur, ob sie die richtigen Antworten bekamen, sondern auch, wie viel Zeit oder Mühe sie brauchten, um dorthin zu gelangen.

Zeit versus Token

Das bedeutete, dass auf die Millisekunde genau gemessen wurde, wie lange es dauerte, bis die Leute auf jede Frage antworteten. Für die Modelle verwendete Varda eine andere Metrik. Es machte keinen Sinn, die Verarbeitungszeit zu messen, da diese mehr von der Computerhardware abhängt als vom Aufwand, den das Modell für die Lösung eines Issues aufwendet. Stattdessen verfolgte er Token, die Teil der internen Gedankenkette eines Modells sind. „Sie produzieren Token, die nicht dazu gedacht sind, dass der Benutzer sie sieht und bearbeitet, sondern nur, um einen Überblick über die internen Berechnungen zu haben, die sie durchführen“, erklärt de Varda. „Es ist, als würden sie mit sich selbst reden.“

Sowohl Menschen als auch Denkmodelle wurden gebeten, sieben verschiedene Arten von Problemen zu lösen, darunter numerische Arithmetik und intuitives Denken. Für jede Problemklasse wurden ihnen viele Aufgaben gestellt. Je schwieriger ein bestimmtes Drawback conflict, desto länger brauchten die Leute, um es zu lösen – und je länger die Leute brauchten, um ein Drawback zu lösen, desto mehr Token generierte ein Argumentationsmodell, als es zu seiner eigenen Lösung kam.

Ebenso waren die Problemklassen, für deren Lösung Menschen am längsten brauchten, die gleichen Problemklassen, die die meisten Token für die Modelle erforderten: Rechenaufgaben waren am wenigsten anspruchsvoll, während eine Gruppe von Problemen, die als „ARC-Herausforderung“ bezeichnet werden und bei denen Paare von farbigen Gittern eine Transformation darstellen, die abgeleitet und dann auf ein neues Objekt angewendet werden muss, sowohl für Menschen als auch für Modelle am kostspieligsten conflict.

De Varda und Fedorenko sagen, dass die auffällige Übereinstimmung bei den Denkkosten zeigt, wie Argumentationsmodelle wie Menschen denken. Das bedeutet jedoch nicht, dass die Modelle menschliche Intelligenz nachbilden. Die Forscher wollen noch wissen, ob die Modelle ähnliche Informationsdarstellungen wie das menschliche Gehirn verwenden und wie diese Darstellungen in Problemlösungen umgewandelt werden. Sie sind auch neugierig, ob die Modelle in der Lage sein werden, Probleme zu bewältigen, die Weltwissen erfordern, das in den für das Modelltraining verwendeten Texten nicht dargelegt ist.

Die Forscher weisen darauf hin, dass Argumentationsmodelle zwar beim Lösen von Problemen interne Monologe erzeugen, sie aber nicht unbedingt die Sprache zum Denken verwenden. „Wenn man sich die Ausgabe ansieht, die diese Modelle beim Denken erzeugen, enthält sie häufig Fehler oder einige unsinnige Teile, selbst wenn das Modell letztendlich zu einer richtigen Antwort kommt. Die eigentlichen internen Berechnungen finden additionally wahrscheinlich in einem abstrakten, nicht-sprachlichen Darstellungsraum statt, ähnlich wie Menschen keine Sprache zum Denken verwenden“, sagt er.

eine erhebliche Anzahl von Aufgaben zu automatisieren. Seit der Veröffentlichung von ChatGPT im Jahr 2022 sehen wir immer mehr KI-Produkte auf dem Markt, die LLMs nutzen. Es gibt jedoch noch viele Verbesserungsmöglichkeiten bei der Artwork und Weise, wie wir LLMs nutzen. Die Verbesserung Ihrer Eingabeaufforderung mit einem LLM-Eingabeaufforderungsverbesserer und die Verwendung zwischengespeicherter Token sind beispielsweise zwei einfache Techniken, mit denen Sie die Leistung Ihrer LLM-Anwendung erheblich verbessern können.

In diesem Artikel bespreche ich mehrere spezifische Techniken, die Sie bei der Erstellung und Strukturierung Ihrer Eingabeaufforderungen anwenden können, um Latenz und Kosten zu reduzieren und auch die Qualität Ihrer Antworten zu erhöhen. Ziel ist es, Ihnen diese spezifischen Techniken vorzustellen, damit Sie sie sofort in Ihre eigene LLM-Anwendung implementieren können.

Warum Sie Ihre Eingabeaufforderung optimieren sollten

In vielen Fällen verfügen Sie möglicherweise über eine Eingabeaufforderung, die mit einem bestimmten LLM funktioniert und angemessene Ergebnisse liefert. Allerdings haben Sie in vielen Fällen nicht viel Zeit damit verbracht, die Eingabeaufforderung zu optimieren, sodass noch viel Potenzial offen bleibt.

Ich behaupte, dass Sie mit den spezifischen Techniken, die ich in diesem Artikel vorstelle, ohne großen Aufwand sowohl die Qualität Ihrer Antworten verbessern als auch die Kosten senken können. Nur weil ein Immediate und LLM funktionieren, heißt das nicht, dass es optimum funktioniert, und in vielen Fällen können Sie mit sehr geringem Aufwand große Verbesserungen feststellen.

Spezifische Techniken zur Optimierung

In diesem Abschnitt werde ich die spezifischen Techniken behandeln, die Sie zur Optimierung Ihrer Eingabeaufforderungen verwenden können.

Behalten Sie statische Inhalte immer frühzeitig bei

Die erste Technik, die ich behandeln werde, besteht darin, statische Inhalte immer früh in Ihrer Eingabeaufforderung beizubehalten. Mit statischen Inhalten beziehe ich mich auf Inhalte, die gleich bleiben, wenn Sie mehrere API-Aufrufe durchführen.

Der Grund, warum Sie den statischen Inhalt frühzeitig beibehalten sollten, liegt darin, dass alle großen LLM-Anbieter wie Anthropic, Google und OpenAI zwischengespeicherte Token verwenden. Zwischengespeicherte Token sind Token, die bereits in einer vorherigen API-Anfrage verarbeitet wurden und kostengünstig und schnell verarbeitet werden können. Es variiert von Anbieter zu Anbieter, aber zwischengespeicherte Eingabe-Tokens kosten normalerweise etwa 10 % der normalen Eingabe-Tokens.

Zwischengespeicherte Token sind Token, die bereits in einer vorherigen API-Anfrage verarbeitet wurden und verarbeitet werden können günstiger und schneller als normale Token

Das heißt, wenn Sie denselben Immediate zweimal hintereinander einsenden, kosten die Enter-Tokens des zweiten Prompts nur 1/10 der Enter-Tokens des ersten Prompts. Dies funktioniert, weil die LLM-Anbieter die Verarbeitung dieser Eingabe-Tokens zwischenspeichern, was die Bearbeitung Ihrer neuen Anfrage günstiger und schneller macht.

---

In der Praxis werden Eingabetokens zwischengespeichert, indem Variablen am Ende der Eingabeaufforderung beibehalten werden.

Wenn Sie beispielsweise eine lange Systemaufforderung mit einer Frage haben, die von Anfrage zu Anfrage unterschiedlich ist, sollten Sie etwa so vorgehen:

immediate = f"""
{lengthy static system immediate}

{consumer immediate}
"""

Zum Beispiel:

immediate = f"""
You're a doc professional ...
It is best to at all times reply on this format ...
If a consumer asks about ... you need to reply ...

{consumer query}
"""

Hier haben wir zuerst den statischen Inhalt der Eingabeaufforderung, bevor wir zuletzt den variablen Inhalt (die Benutzerfrage) einfügen.

---

In manchen Szenarien möchten Sie Dokumentinhalte einspeisen. Wenn Sie viele verschiedene Dokumente verarbeiten, sollten Sie den Dokumentinhalt am Ende der Eingabeaufforderung beibehalten:

# if processing completely different paperwork
immediate = f"""
{static system immediate}
{variable immediate instruction 1}
{doc content material}
{variable immediate instruction 2}
{consumer query}
"""

Angenommen, Sie verarbeiten dieselben Dokumente mehrmals. In diesem Fall können Sie sicherstellen, dass auch die Tokens des Dokuments zwischengespeichert werden, indem Sie zuvor sicherstellen, dass keine Variablen in die Eingabeaufforderung eingefügt werden:

# if processing the identical paperwork a number of occasions
immediate = f"""
{static system immediate}
{doc content material} # maintain this earlier than any variable directions
{variable immediate instruction 1}
{variable immediate instruction 2}
{consumer query}
"""

Beachten Sie, dass zwischengespeicherte Token normalerweise nur aktiviert werden, wenn die ersten 1024 Token in zwei Anfragen gleich sind. Wenn Ihre statische Systemaufforderung im obigen Beispiel beispielsweise kürzer als 1024 Token ist, werden Sie keine zwischengespeicherten Token verwenden.

# do NOT do that
immediate = f"""
{variable content material} < --- this removes all utilization of cached tokens
{static system immediate}
{doc content material}
{variable immediate instruction 1}
{variable immediate instruction 2}
{consumer query}
"""

Ihre Eingabeaufforderungen sollten immer zuerst mit den statischsten Inhalten (der Inhalt variiert von Anfrage zu Anfrage) und dem dynamischsten Inhalt (der Inhalt variiert am meisten von Anfrage zu Anfrage) erstellt werden.

1. Wenn Sie eine lange System- und Benutzeraufforderung ohne Variablen haben, sollten Sie diese zunächst beibehalten und die Variablen am Ende der Eingabeaufforderung hinzufügen
2. Wenn Sie beispielsweise Textual content aus Dokumenten abrufen und dasselbe Dokument zweimal verarbeiten, sollten Sie dies tun

Könnte der Inhalt eines Dokuments sein, oder wenn Sie eine lange Eingabeaufforderung haben -> nutzen Sie Caching

Frage zum Schluss

Eine weitere Technik, die Sie zur Verbesserung der LLM-Leistung nutzen sollten, besteht darin, die Benutzerfrage immer am Ende Ihrer Eingabeaufforderung zu platzieren. Idealerweise organisieren Sie es so, dass Ihre Systemaufforderung alle allgemeinen Anweisungen enthält und die Benutzeraufforderung einfach nur aus der Benutzerfrage besteht, wie zum Beispiel unten:

system_prompt = "<basic directions>"

user_prompt = f"{user_question}"

In den Immediate-Engineering-Dokumenten von Anthropic kann der Standing, der die Benutzeraufforderung am Ende enthält, die Leistung um bis zu 30 % verbessern, insbesondere wenn Sie lange Kontexte verwenden. Durch das Einfügen der Frage am Ende wird dem Modell klarer, welche Aufgabe es erfüllen möchte, und es führt in vielen Fällen zu besseren Ergebnissen.

Verwendung eines Immediate-Optimierers

Wenn Menschen Eingabeaufforderungen schreiben, werden diese häufig unordentlich, inkonsistent, enthalten redundante Inhalte und weisen keine Struktur auf. Daher sollten Sie Ihre Eingabeaufforderung immer über einen Eingabeaufforderungsoptimierer einspeisen.

Der einfachste Immediate-Optimierer, den Sie verwenden können, besteht darin, einen LLM dazu aufzufordern Verbessere diese Eingabeaufforderung {immediate}, und Sie erhalten eine strukturiertere Eingabeaufforderung mit weniger redundanten Inhalten usw.

Ein noch besserer Ansatz besteht jedoch darin, einen bestimmten Immediate-Optimierer zu verwenden, wie er beispielsweise in den Konsolen von OpenAI oder Anthropic zu finden ist. Bei diesen Optimierern handelt es sich um LLMs, die speziell zur Optimierung Ihrer Eingabeaufforderungen erstellt und erstellt wurden und in der Regel bessere Ergebnisse liefern. Darüber hinaus sollten Sie darauf achten, Folgendes einzubeziehen:

• Particulars zu der Aufgabe, die Sie erreichen möchten
• Beispiele für Aufgaben, bei denen die Eingabeaufforderung erfolgreich conflict, sowie für die Eingabe und Ausgabe
• Beispiel für Aufgaben, bei denen die Eingabeaufforderung fehlgeschlagen ist, mit Eingabe und Ausgabe

Die Bereitstellung dieser zusätzlichen Informationen führt in der Regel zu weitaus besseren Ergebnissen und Sie erhalten am Ende eine viel bessere Eingabeaufforderung. In vielen Fällen benötigen Sie nur etwa 10 bis 15 Minuten und erhalten am Ende eine wesentlich leistungsfähigere Eingabeaufforderung. Dies macht die Verwendung eines Immediate-Optimierers zu einem der Ansätze mit dem geringsten Aufwand zur Verbesserung der LLM-Leistung.

Benchmark-LLMs

Das von Ihnen verwendete LLM hat auch erhebliche Auswirkungen auf die Leistung Ihrer LLM-Anwendung. Verschiedene LLMs eignen sich für unterschiedliche Aufgaben, daher müssen Sie die verschiedenen LLMs in Ihrem spezifischen Anwendungsbereich ausprobieren. Ich empfehle, zumindest einen Zugang zu den größten LLM-Anbietern wie Google Gemini, OpenAI und Anthropic einzurichten. Die Einrichtung ist ganz einfach und der Wechsel Ihres LLM-Anbieters dauert nur wenige Minuten, wenn Sie bereits Anmeldeinformationen eingerichtet haben. Darüber hinaus können Sie auch das Testen von Open-Supply-LLMs in Betracht ziehen, obwohl diese in der Regel einen höheren Aufwand erfordern.

Sie müssen nun einen spezifischen Benchmark für die Aufgabe festlegen, die Sie erreichen möchten, und herausfinden, welches LLM am besten funktioniert. Darüber hinaus sollten Sie die Modellleistung regelmäßig überprüfen, da die großen LLM-Anbieter ihre Modelle gelegentlich aktualisieren, ohne unbedingt eine neue Model herauszubringen. Natürlich sollten Sie auch bereit sein, neue Modelle der großen LLM-Anbieter auszuprobieren.

Abschluss

In diesem Artikel habe ich vier verschiedene Techniken behandelt, mit denen Sie die Leistung Ihrer LLM-Anwendung verbessern können. Ich habe die Verwendung zwischengespeicherter Token, die Frage am Ende der Eingabeaufforderung, die Verwendung von Eingabeaufforderungsoptimierern und die Erstellung spezifischer LLM-Benchmarks besprochen. Diese sind alle relativ einfach einzurichten und durchzuführen und können zu einer erheblichen Leistungssteigerung führen. Ich glaube, dass es viele ähnliche und einfache Techniken gibt, und Sie sollten immer versuchen, nach ihnen Ausschau zu halten. Diese Themen werden normalerweise in verschiedenen Blogbeiträgen beschrieben, wobei Anthropic einer der Blogs ist, der mir am meisten dabei geholfen hat, die LLM-Leistung zu verbessern.

Finden Sie mich in den sozialen Netzwerken:

Abonnieren Sie meinen E-newsletter

Nehmen Sie Kontakt auf

LinkedIn

X / Twitter

Medium

Sie können auch einige meiner anderen Artikel lesen:

Fühlen Sie, wenn alles scheint Um intestine zu arbeiten, bis Sie unter die Motorhaube schauen und feststellen, dass Ihr System 10 × mehr Kraftstoff verbrennt, als es nötig ist?

Wir hatten ein Consumer -Skript, das Anfragen abfeuerte, um unsere Eingabeaufforderungen zu validieren, die mit asynchronen Python -Code erstellt und in einem Jupyter -Notizbuch reibungslos ausgeführt wurden. Sauber, einfach und schnell. Wir haben es regelmäßig durchgeführt, um unsere Modelle zu testen und Bewertungsdaten zu sammeln. Keine roten Fahnen. Keine Warnungen.

Aber unter dieser polierten Oberfläche lief etwas leise schief.

Wir sahen keine Misserfolge. Wir bekamen keine Ausnahmen. Wir haben nicht einmal Langsamkeit bemerkt. Aber unser System leistete viel mehr Arbeit als nötig, und wir haben es nicht bemerkt.

In diesem Beitrag gehen wir durch, wie wir das Downside entdeckt haben, was es verursacht hat und wie a Einfache strukturelle Veränderung in unserem asynchronisierten Code reduzierte den LLM -Verkehr und die Kosten um 90%, um 90%. mit praktisch ohne Geschwindigkeits- oder Funktionsverlust.

Nun, faire Warnung, Das Lesen dieses Beitrags wird Ihre LLM -Kosten nicht auf magische Weise um 90% senken. Aber das Mitnehmen hier ist breiter: Kleine, übersehene Entwurfsentscheidungen, manchmal nur wenige Codezeilen, können zu massiven Ineffizienzen führen. Wenn Sie beabsichtigt, wie Ihr Code ausgeführt wird, können Sie auf lange Sicht Zeit, Geld und Frustration sparen.

Die Repair selbst könnte zuerst Nische fühlen. Es beinhaltet die Feinheiten von Pythons asynchronem Verhalten, wie Aufgaben geplant und versandt werden. Wenn Sie mit Python vertraut sind und async/awaitSie werden mehr aus den Code -Beispielen herausholen, aber selbst wenn dies nicht der Fall ist, gibt es immer noch viel zu genießen. Denn in der wahren Geschichte hier geht es nicht nur um LLMs oder Python, sondern um Verantwortungsbewusst, effizientes Engineering.

Lass uns eingraben.

Das Setup

Um die Validierung zu automatisieren, verwenden wir einen vordefinierten Datensatz und lösen unser System über ein Consumer -Skript aus. Die Validierung konzentriert sich auf a Kleine Untergruppe des Datensatzes, so wird der Clientcode erst nach Erhalt einer bestimmten Anzahl von Antworten aufhört.

Hier ist eine vereinfachte Model unseres Kunden in Python:

import asyncio
from aiohttp import ClientSession
from tqdm.asyncio import tqdm_asyncio

URL = "http://localhost:8000/instance"
NUMBER_OF_REQUESTS = 100
STOP_AFTER = 10

async def fetch(session: ClientSession, url: str) -> bool:
    async with session.get(url) as response:
        physique = await response.json()
        return physique("worth")

async def most important():
    outcomes = ()

    async with ClientSession() as session:
        duties = (fetch(session, URL) for _ in vary(NUMBER_OF_REQUESTS))

        for future in tqdm_asyncio.as_completed(duties, whole=NUMBER_OF_REQUESTS, desc="Fetching"):
            response = await future
            if response is True:
                outcomes.append(response)
                if len(outcomes) >= STOP_AFTER:
                    print(f"n Stopped after receiving {STOP_AFTER} true responses.")
                    break

asyncio.run(most important())

Dieses Skript liest Anfragen von einem Datensatz, feuert sie gleichzeitig aus und stoppt, sobald wir genug gesammelt haben true Antworten für unsere Bewertung. In der Produktion ist die Logik komplexer und basiert auf der Vielfalt der Antworten, die wir benötigen. Aber die Struktur ist die gleiche.

Verwenden wir einen Dummy -Fastapi -Server, um das echte Verhalten zu simulieren:

import asyncio
import fastapi
import uvicorn
import random

app = fastapi.FastAPI()

@app.get("/instance")
async def instance():
    sleeping_time = random.uniform(1, 2)
    await asyncio.sleep(sleeping_time)
    return {"worth": random.alternative((True, False))}

if __name__ == "__main__":
    uvicorn.run(app, host="0.0.0.0", port=8000)

Lassen Sie uns nun diesen Dummy -Server anfeuern und den Consumer ausführen. Sie werden so etwas aus dem Consumer -Terminal sehen:

Können Sie das Downside erkennen?

Hübsch! Schnell, sauber und… warte alles wie erwartet?

An der Oberfläche, es scheint Wie der Kunde das Richtige tut: Anfragen zu senden, 10 zu erhalten true Antworten, dann anhalten.

Aber ist es?

Fügen wir unserem Server ein paar Druckanweisungen hinzu, um zu sehen, was er tatsächlich unter der Haube tut:

import asyncio
import fastapi
import uvicorn
import random

app = fastapi.FastAPI()

@app.get("/instance")
async def instance():
    print("Bought a request")
    sleeping_time = random.uniform(1, 2)
    print(f"Sleeping for {sleeping_time:.2f} seconds")
    await asyncio.sleep(sleeping_time)
    worth = random.alternative((True, False))
    print(f"Returning worth: {worth}")
    return {"worth": worth}

if __name__ == "__main__":
    uvicorn.run(app, host="0.0.0", port=8000)

Jetzt alles erneut ausführen.

Sie werden anfangen, solche Protokolle zu sehen:

Bought a request
Sleeping for 1.11 seconds
Bought a request
Sleeping for 1.29 seconds
Bought a request
Sleeping for 1.98 seconds
...
Returning worth: True
Returning worth: False
Returning worth: False
...

Schauen Sie sich die Serverprotokolle genauer an. Sie werden etwas Unerwartetes bemerken: Anstatt nur 14 Anfragen zu verarbeiten, wie wir in der Fortschrittsleiste sehen, übernimmt der Server alle 100. Obwohl der Kunde nach Erhalt 10 anhält true Antworten, es sendet immer noch jede Anfrage im Voraus. Infolgedessen muss der Server alle verarbeiten.

Es ist ein einfacher Fehler zu verpassenVor allem, weil alles aus der Sicht des Kunden korrekt zu funktionieren scheint: Antworten kommen schnell ein, die Fortschrittsbalken sind Fortschritte und das Skript verlässt früh. Aber hinter den Kulissen werden alle 100 Anfragen sofort gesendet, unabhängig davon, wann wir uns entscheiden, nicht mehr zuzuhören. Dies führt zu 10 × mehr Verkehr als nötig, steigern Sie die Kosten, die Erhöhung der Final und die Risikobeschränkungen.

Die Hauptfrage lautet additionally: Warum passiert das und wie können wir sicherstellen, dass wir nur die Anfragen senden, die wir tatsächlich benötigen? Die Antwort stellte sich als eine kleine, aber mächtige Veränderung heraus.

Die Wurzel des Issues liegt darin, wie die Aufgaben geplant sind. In unserem ursprünglichen Code erstellen wir eine Liste von 100 Aufgaben auf einmal:

duties = (fetch(session, URL) for _ in vary(NUMBER_OF_REQUESTS))

for future in tqdm_asyncio.as_completed(duties, whole=NUMBER_OF_REQUESTS, desc="Fetching"):
    response = await future

Wenn Sie eine Liste von Coroutinen an übergeben as_completedPython wickelt sofort jede Coroutine in a Job und plant es auf der Occasion -Schleife. Dies geschieht, bevor Sie über den Schleifenkörper iteriert werden. Sobald eine Coroutine zu einer wird JobDie Ereignisschleife wird sofort im Hintergrund ausgeführt.

as_completed selbst kontrolliert die Parallelität nicht, es einfach wartet darauf, dass die Aufgaben beendet werden und sie nacheinander in der Reihenfolge, die sie erledigen. Betrachten Sie es als Iterator über abgeschlossene Futures, nicht als Verkehrscontroller. Dies bedeutet, dass zu dem Zeitpunkt, an dem Sie beginnen, zu schleifen, Alle 100 Anfragen sind bereits im Gange. Nach 10 ausbrechen true Die Ergebnisse hinderen Sie daran, den Relaxation zu verarbeiten, aber es hindert sie nicht daran, gesendet zu werden.

Um dies zu beheben, haben wir vorgestellt A Semaphor Genauigkeit einschränken. Das Semaphor fügt ein leichtes Schloss im Inneren hinzu fetch so dass nur eine feste Anzahl von Anforderungen gleichzeitig beginnen kann. Der Relaxation bleibt im Pause und wartet auf einen Slot. Sobald wir unseren Stoppzustand erreicht haben, erwerben die Pautenaufgaben nie das Schloss, so dass sie ihre Anfragen nie senden.

Hier ist die angepasste Model:

import asyncio
from aiohttp import ClientSession
from tqdm.asyncio import tqdm_asyncio

URL = "http://localhost:8000/instance"
NUMBER_OF_REQUESTS = 100
STOP_AFTER = 10

async def fetch(session: ClientSession, url: str, semaphore: asyncio.Semaphore) -> str:
    async with semaphore:
        async with session.get(url) as response:
            physique = await response.json()
            return physique("worth")

async def most important():
    outcomes = ()
    semaphore = asyncio.Semaphore(int(STOP_AFTER * 1.5))

    async with ClientSession() as session:
        duties = (fetch(session, URL, semaphore) for _ in vary(NUMBER_OF_REQUESTS))

        for future in tqdm_asyncio.as_completed(duties, whole=NUMBER_OF_REQUESTS, desc="Fetching"):
            response = await future
            if response:
                outcomes.append(response)
                if len(outcomes) >= STOP_AFTER:
                    print(f"n Stopped after receiving {STOP_AFTER} true responses.")
                    break

asyncio.run(most important())

Mit dieser Änderung definieren wir immer noch 100 Anfragen im Voraus, aber aber Nur eine kleine Gruppe darf gleichzeitig laufen15 in diesem Beispiel. Wenn wir unseren Stoppzustand frühzeitig erreichen, stoppt die Occasion -Schleife, bevor wir weitere Anfragen gestartet haben. Dadurch reagiert das Verhalten und reduziert gleichzeitig unnötige Anrufe.

Jetzt werden die Serverprotokolle nur etwa 20 angezeigt "Bought a request/Returning response" Einträge. Auf der Kundenseite erscheint die Fortschrittsleiste mit dem Unique identisch.

Mit dieser Änderung sahen wir sofortige Auswirkungen: 90% Reduzierung des Anforderungsvolumens und LLM -Kostenohne merkwürdige Verschlechterung der Kundenerfahrung. Es verbesserte auch den Durchsatz im gesamten Staff, reduzierte die Warteschlange und beseitigte die Charge-Restrict-Probleme unserer LLM-Anbieter.

Diese kleine strukturelle Anpassung machte unsere Validierungspipeline dramatisch effizienter, ohne dem Code viel Komplexität zu verleihen. Es ist eine gute Erinnerung daran, dass sich der Steuerfluss in asynchronen Systemen nicht immer so verhalten, wie Sie es annehmen, es sei denn, Sie sind explizit darüber, wie Aufgaben geplant sind und wann sie ausgeführt werden sollten.

Bonus Perception: Schließen der Ereignisschleife

Wenn wir den ursprünglichen Clientcode ohne ausgeführt hätten asyncio.runWir hätten das Downside vielleicht früher bemerkt.
Wenn wir beispielsweise so ein manuelles Occasion -Loop -Administration wie folgt verwendet hatten:

loop = asyncio.get_event_loop()
loop.run_until_complete(most important())
loop.shut()

Python hätte Warnungen gedruckt wie:

Diese Warnungen erscheinen, wenn das Programm beendet wird, während noch unvollendete asynchronen Aufgaben in der Schleife geplant sind. Wenn wir einen Bildschirm voller Warnungen gesehen hätten, hätte er wahrscheinlich viel früher eine rote Fahne ausgelöst.

Warum haben wir diese Warnung bei der Verwendung nicht gesehen? asyncio.run()?

Weil asyncio.run() Kümmert sich um die Reinigung hinter den Kulissen. Es wird nicht nur Ihre Coroutine und Ihren Ausgang ausgeführt, sondern auch alle verbleibenden Aufgaben abgebaut, bis sie fertig ist, und erst dann die Ereignisschleife abschließt. Dieses integrierte Sicherheitsnetz verhindert, dass diese „anhängigen Aufgaben“ Warnungen angezeigt werden, auch wenn Ihr Code leise mehr Aufgaben eröffnet hat, als er nötig struggle.

Infolgedessen es unterdrückt diese Warnungen für „ausstehende Aufgaben“ Wenn Sie die Schleife manuell schließen mit loop.shut() nach run_until_complete()Alle übrig gebliebenen Aufgaben, die nicht erwartet wurden, werden immer noch herumhängen. Python erkennt, dass Sie die Schleife gewaltsam abschließen, während die Arbeiten noch geplant sind, und warnt Sie davor.

Dies kann nicht heißen, dass jedes asynchrische Python -Programm vermeiden sollte asyncio.run() oder immer benutzen loop.run_until_complete() mit einem Handbuch loop.shut(). Aber es zeigt etwas Wichtiges: Sie sollten sich bewusst sein, welche Aufgaben noch ausgeführt werden, wenn Ihr Programm austritt. Zumindest ist es eine gute Idee, vor dem Abschalten ausstehende Aufgaben zu überwachen oder zu protokollieren.

Letzte Gedanken

Indem wir den Kontrollfluss zurücktreten und überdenken konnten, konnten wir unseren Validierungsprozess dramatisch effizienter gestalten – Nicht durch Hinzufügen von mehr Infrastruktur, sondern indem wir das verwendeten, was wir bereits sorgfältiger hatten. Ein paar Zeilen der Codeänderung führten zu a 90% Kostenreduzierung ohne zusätzliche Komplexität. Es löste Charge-Restrict-Fehler, reduzierte Systemlast auf und ermöglichte es dem Staff, Bewertungen häufiger durchzuführen, ohne Engpässe zu verursachen.

Es ist eine wichtige Erinnerung daran„Clear“ asynchronisierter Code bedeutet nicht immer effizienter Code, es ist entscheidend, die Verwendung von Systemressourcen beabsichtigt zu sein, wie wir Systemressourcen verwenden. Verantwortungsbewusstes, effizientes Engineering ist mehr als nur das Schreiben von Code, der funktioniert. Es geht darum, Systeme zu entwerfen, die Zeit, Geld und gemeinsame Ressourcen respektieren, insbesondere in kollaborativen Umgebungen. Wenn Sie Compute als gemeinsames Vermögenswert anstelle eines unendlichen Swimming pools behandeln, profitieren alle davon: Systemsskala besser, Groups bewegen sich schneller und die Kosten bleiben vorhersehbar.

Egal, ob Sie LLM -Anrufe tätigen, Kubernetes -Jobs starten oder Daten in Stapeln verarbeiten, innehalten und sich fragen: Verwende ich nur das, was ich Wirklich brauchen?

Oft sind die Antwort und die Verbesserung nur eine Codezeile entfernt.

Benutzeranalysen und Benchmark-Exams zeigen ein geteiltes Urteil zwischen Deepseek R1 und O3-Mini, wobei Entwickler und Unternehmen unterschiedliche Stärken der KI-Modellleistung, der Preisgestaltung und der Barrierefreiheit priorisieren. Das Suggestions der Menschen zeigt die Kosteneffizienz von Deepseek R1 und die technische Innovation gegen die Zuverlässigkeit und die Integration von Ökosystemen von O3-Mini. Weitere dazu unten…

Openai O3-Mini gegen Deepseek-R1: Was ist besser?

Leistungsbenchmarks zeigen unterschiedliche Stärken

Deepseek R1 Erzählte 79,8% für den Aime-Mathematik-Benchmark und 93% bei Math-500, was Konkurrenten bei komplexen Argumentationsaufgaben übertrifft. Benutzer lobten seine transparente „Kette der Gedankenkette“, die Forscher und Akademiker für die Replikation der Ergebnisse als wertvoll empfinden. Tester stellten jedoch Inkonsistenzen in Multi-Flip-Gesprächen und gelegentlichem Sprachmischen in Antworten fest.

o3-mini Laut realen Nutzerberichten zeigten schnellere Inferenzgeschwindigkeiten und stabilere Leistung in strukturierten Dialogen mit mehreren Turns. Während es Deepseek R1 in spezialisierten mathematischen Benchmarks verfolgt, bezeichneten die Entwickler es für Routineaufgaben wie Codegenerierung und Datenanalyse als „vorhersehbar und poliert“.

Kostenvergleich hebt die Marktstörung hervor

Deepseek R1 ist die erschwinglichste Possibility in den aktuellen KI-Modellvergleiche, die OpenAs O3-Mini-, O1-Mini- und O1-Modelle durch signifikante Margen unterbinden. Preisdaten zeigen starke Unterschiede in den Token -Kosten in Wettkämpfen.

OpenAI -Modellpreisstufen

O3-mini kostet 1,10 USD professional Million Eingangs-Token und 4,40 USD professional Million Output-Token, was einem Rabatt von 63% gegenüber O1-Mini und einer Reduzierung von 93% gegenüber den Preisen des vollständigen O1-Modells entspricht. Ein 50% iger Cache-Rabatt senkt die wirksamen Tarife von O3-Mini für berechtigte Benutzer weiter.

Deepseeks aggressive Preisstrategie

Deepseek R1 berechnet 0,14 USD professional Million Enter-Token und 0,55 USD professional Million Output-Token-ca. 87% billiger als die Grundsätze von O3-Mini. Dies macht R1:

• 96% billiger als die äquivalente Preisgestaltung von O1-Mini
• 99% billiger als die ursprünglichen Kosten des vollständigen O1 -Modells

Die Preislücke bleibt auch bei der Anwendung von O3-Mini-Cache-Rabatt bestehen: Bei 0,55 USD/2,20 USD professional Million Token (Enter/Output) bleibt O3-Mini quick 4x teurer als die nicht erfassten Raten von R1. Entwickler von X nannten es einen „Recreation-Changer“ für Startups und akademische Projekte, die eine leistungsstarke KI ohne Lizenzgebühren erfordern.

Die Preisgestaltung von O3-Mini entspricht den kommerziellen Modellen von OpenAI, beinhaltet jedoch den Zugriff auf die Enterprise-Instruments von Chatgpt, einschließlich SOC 2 Compliance und granuläre Nutzungskontrollen. Enterprise-Benutzer rechtfertigen die höheren Kosten, indem sie die Komplexität der reduzierten Bereitstellungen und integrierte Sicherheitsfunktionen zitieren.

Benutzerfreundlichkeit: Barrierefreiheit gegen Anpassung

O3-mini dominiert in der Benutzerfreundlichkeit mit seiner Schnittstelle im Chatgpt-Stil, der kostenlosen Stufe für grundlegende Benutzer und API, die minimales Codierungskompetenz erfordern. Nichttechnische Tester haben die Integration in weniger als 30 Minuten abgeschlossen und sein „intuitives Design“ für schnelles Prototyping gelobt.

Deepseek R1 erfordert technische Kenntnisse für die Bereitstellung und fordert die Benutzer, Infrastruktur- und Feinabstimmung Modelle über Code zu verwalten. Während Entwickler ihre Flexibilität zu schätzen wissen, geben kleine Groups an, „Stunden Fehlerbehebungskonfigurationen“ auszugeben, um die Ausgaben zu optimieren.

Neighborhood -Reaktionen zeigen gespaltene Präferenzen

X -Benutzer unterstreichen die Erschwinglichkeit und Transparenz von Deepseek R1. Kritiker zitieren „umständliche Formatierung“ und eine schwächere Leistung bei kreativen Schreibaufgaben im Vergleich zu O3-Mini.

O3-Mini loben sich für Zuverlässigkeit, aber Skeptiker argumentieren, dass ihre Kosten die Skalierung verbieten, während einige Entwickler im Vergleich zu Alternativen Open-Supply-Alternativen eine begrenzte Kontrolle über das Modellverhalten beklagen.

Endgültiges Urteil: Spezialisten gegen Generalisten

Technische Groups bevorzugen trotz steilerer Lernkurven Deepseek R1 für seine mathematischen Fähigkeiten, den Open-Supply-Code und die radikalen Kosteneinsparungen. Unternehmen und Gelegenheitsbenutzer bevorzugen die Plug-and-Play-Funktionalität von O3-Mini und nahtlose Integration in vorhandene OpenAI-Workflows.

Neighborhood-Diskussionen unterstreichen eine wachsende Kluft: Deepseek R1 zieht Forscher und Entwickler an, die die Rohleistung priorisieren, während O3-Mini Unternehmen und Einzelpersonen, die die Stabilität und Einfache der Adoption bewerten, behält.