ewso

EWSO: Emergent Web Struktur Ontology

EWSO -Übersicht

EWSO ist eine Ontologie einer dynamischen Ontologie -Engineering -Methodik, die die strukturierte Darstellung von Wissen nutzt, um die LLM -Ausgaben für jeden Zweck zu verbessern. EWSO beinhaltet eine abstrakte Syntax für die Konstruktion von Ontology Engineering Methodology Templates LLM -Persona -Eingabeaufforderungen können zum Ausgang strukturierten Antworten verwendet werden. Diese Strukturen sind immer noch stochastisch und erfordern Ableitungen in GaN-ähnlichen Rollenspielkonversationskonfigurationen, um korrigiert zu werden. This document provides the basis for a syntax formalizing the use of LLM interpreters inside AI-enabled agents to autonomously construct an ontology synthesized from aggregated outputs of prior conversations, enabling ontology-aware autonomous AI agents in a hierarchical swarm that can iteratively ontologize its own knowledge and discover emergent knowledge using PCNL (PseudoCypherNaturalLanguage, detailed below) compression and Dekompression.

Was ist eine aufstrebende Webstruktur?

Eine aufstrebende Webstruktur ist ein Cluster von Schichten abstrakter aufstrebender Entitäten, die in einer Transformationskette miteinander verbunden sind, z. Mit anderen Worten, es schafft ein vollständiges Konzept, und dies tut durch die Verwendung von zwei Hauptsprachen, die in Workflows für Ontology Mining und Extraktion verwendet werden können, die aus Dual -Feedback -Schleifen aus Dual -Feedback -Schleifen (usw.) entstehen. Im Folgenden finden Sie zwei Beispiel -Primärsprachen: CORL und PCNL. Sie können sich mit den EWSO-Prinzipien kombinieren, um einen kontinuierlichen ontologischen Bohrer- und Abstraktionsmotor zu erstellen, der Kenntnisse abgibt, das aus den Beobachtungen sinnvoll ist, die sie über ihren eigenen mithilfe von Informationsfluss (die LLM-Reflexionen) haben.

https://www.mermaidchart.com/raw/57ad88cf-63a3-41ec-a7ce-29b9eb711bde?theme=light&version=v0.1&format=svg

CORL: Komprimierte Ontologie -Repräsentationssprache

Corl -Grundierung für KI -Systeme

Zweck: CORL ist eine Syntaxkomprimierungssprache, die für KI -Agenten entwickelt wurde, die mit Wissensdarstellung im EWL -Format arbeiten. Es bietet eine menschliche lesbare Möglichkeit, ontologische Elemente zu definieren und gleichzeitig eine reibungslose maschinelle Übersetzung in Eule zu gewährleisten.

Kernregeln

Entitätserklärung:

Syntax: Entität: OWL Mapping: OWL: Klasse mit RDF: ID entspricht dem Subsumsum (IS_A):

Syntax: Unterklasse: OWL Mapping: RDFS: Unterklasse der Beziehung. Immobilienerklärung:

Syntax: Eigenschaft: (Domäne:, ​​Bereich :) OWL Mapping: OWL: ObjectProperty (für Objekteigenschaften) oder OWL: DataTypeproperty (für Eigenschaften, die mit Datenwerten verlinkt) sowie RDFs: Domain und RDFs: Bereichsbeschränkungen. Instanzzuordnung:

Syntax: Instanz: von: Owl Mapping: OWL: NAMEDIndividual mit RDF: Typ Set auf die angegebene Klasse. Erweiterte Regeln

Eigenschaften Eigenschaften: Transitive Eigenschaft: ... Symmetrische Eigenschaft: ... Funktionale Eigenschaft: ... inverse funktionale Eigenschaft: ... Kardinalität:

Syntax: Eigenschaft: ... (Cardinality_Min:, Cardinality_MAX: EWL Mapping: Owl: Mincardinality, Owl: MaxCardinity -Beschränkungen. Komplexe Klassenausdrücke (Boolesche Operatoren):

Klasse: äquivalent_to: und Klasse: äquivalent_to: oder Klasse: äquivalent_to: nicht quantifizierer:

... (HasProperty einige) => OWL: Einige ValuesFrom ... (Nur HasProperty) => OWL: AllvaluesFrom Data Eigenschaften und Datentypen:

Data_Property: (Domain:, Bereich: XSD: DataType) (Beispiele für DataTypes: XSD: Integer, XSD: String, XSD: Datum) Zusätzliche Notizen

Kommentare: Vorkommentieren mit // (für den Menschen, ignoriert während der Übersetzung) Fallempfindlichkeit: Corl-Syntax kann basierend auf den Präprozessoren-Auswahlmöglichkeiten von Fall sensitiv sein oder nicht. Namespaces: Ein Mechanismus zum Umgang mit Präfixen und Iris, um eine reibungslose Integration von Konzepten über Ontologien hinweg zu gewährleisten. Übersetzungsprozess

Präprozessor: Ein Programm übernimmt Tokenisierung, Validierung der CORL -Syntax gegen die definierten Regeln und potenzielle Fehlerberichterstattung. Eulengenerierung: Folgt einer direkten Zuordnung von Corl -Konstrukten zu ihren entsprechenden Eulen -Axiomen. Kann eine standardisierte Auswahl der EW -Ausgangsformat (XML, funktionelle Syntax, Manchester usw.) erfordern. Denken Sie daran, Corl entwickelt sich immer noch neben KI -Fähigkeiten. Erwarten Sie potenzielle zukünftige Erweiterungen, um nuancierte logische Komplexitäten zu erfassen!

Meta-Dattaframe-Struktur

Kerntische

Entity_table

Entity_id (Primärschlüssel) Entity_Name entity_type (mögliche Werte: 'Klasse', 'ObjectProperty', 'DataTypeproperty', 'namedividual') Beschreibung (optional - für die Verständlichkeit des Menschen, nicht strikte OWL Compliance) Beziehung_table

relationation_id (primärer Schlüssel) Source_entity_id (Fremdschlüssel -> Entity_table) target_entity_id (Fremdschlüssel -> Entity_table) Relationation_Type (Werte: 'Subclassof', 'äquivalentClass', 'Disjointwith', 'HaSproperty', ...) Eigenschaften charakteristische tischtische immobilien charakteristische Tabellen tischtische

Property_Characteristics

Property_id (Fremdschlüssel -> Entity_table, Entity_Type, die auf Eigenschaften eingeschränkt) charakteristisch_type (Werte: 'transitiv', 'symmetrisch', 'funktional', 'inverseFunctional') Einschränkungen

restriction_id (Primary Key) property_id (Foreign Key -> entity_table) restriction_type (Values: 'someValuesFrom', 'allValuesFrom', 'hasValue', 'cardinality') restriction_class (If applicable, Foreign Key -> entity_table) restriction_datatype (If applicable) cardinality_min (if applicable) cardinality_max (if anwendbar) Illustrative Meta-Dattaframe-Einträge

| Entity_table | | --- | --- | --- | --- | | 1 | Hund | Klasse | ... | | 2 | Person | Klasse | ... | | 3 | Has Mounter | ObjectProperty | ... | | 4 | Fido | Benanntes Individual | ... |

| relation_table | | --- | --- | --- | --- | | 1 | 1 | 2 | Unterklasse von |

| 2 | 3 | 2 | HasProperty | | 3 | 3 | 1 | HasProperty |

| Property_Characteristics | | --- | --- | | 3 | transitiv |

| Einschränkungen | | --- | --- | --- | --- | --- | --- | | 1 | 3 | irgendwann aus | Hund | ... | ... | | 2 | 2 | Kardinalität | Has Mounter | ... | 1 | 1

Notizen

Diese Struktur spiegelt die inhärenten Beziehungen in Eulen -Ontologien wider. '...' geben an, wo menschliche Anmerkungen hinzugefügt werden könnten. Datentypdetails hängen vom ausgewählten "XSD" -Vokabular ab. Eine komplexe Axiomdarstellung kann Erweiterungen erfordern.

PCNL: Pseudocyphernaturallanguage

Pseudocyphernl formale Regeln:

1. Entitätsdarstellung: Alle Entitäten sind in Klammern, z. B. (entity:Name) , eingekapselt. Entitätstypen werden aktiviert, und bestimmte Instanzen können Kleinbuchstaben sein oder bestimmte Namenskonventionen befolgen.

2. Beziehungsrepräsentation: Beziehungen zwischen Entitäten werden als Richtungspfeile mit Beziehungstypen in Klammern dargestellt, z. B. -[r:RELATIONSHIP_TYPE]-> . Beziehungstypen sind alle CAPS und unterstrichen sich für mehrwörter Beziehungen. Nur akzeptable Beziehungen sind: part_of, is_a, Instantiates/Instantied_by "(wobei x sofort die tatsächliche realisierbare Instanz, dh Existenz, von y die Gültigkeit des Wiedergabeschemass x beweist)

3. Erweiterung von Beziehungen jenseits von IS_A , PART_OF , INSTANTIATES : Um zusätzliche Arten von Beziehungen wie HAS_ATTRIBUTE einzubeziehen, wird eine formale Expansionsregel verwendet:

   • HAS_ATTRIBUTE kann in (entity:Attribute)-[r:PART_OF]->(entity)-[r:IS_A]->(Entity) dekomprimiert werden. Dies zeigt, dass Attribute Teil einer Entität sind und beschreiben, was die Entität ist oder hat.
   • In ähnlicher Weise können USED_IN und andere Beziehungen, die nicht direkt von IS_A , PART_OF , INSTANTIATES abgedeckt werden, auf diese drei grundlegenden Beziehungen oder eine Kombination davon abgebildet werden, um immer sicherzustellen, dass es eine logische Zersetzung gibt, die sich auf die grundlegenden Beziehungstypen zurückzieht. Semantik wie "enthält" sind algorithmisch isa/partof/instanziiert, wie ein Container ein Entität ist, der Zweck Teil davon. Die Eindämmung ist ein Zweck, Containments haben Eindämmungszweck für enthaltbare Elemente usw. Nur sagen "x enthält y" impliziert die gesamte "Container Ontology" selbst, die notwendig zu einem formalen Verhältnis von formaler Relpsen von Teil, is_of, is_aa, sofort.

4. Kettungsbeziehungen: Mehrere Beziehungen können aneinander gekettet werden, um komplexe Beziehungen und Hierarchien darzustellen. Die Verkettung erfolgt durch Verbinden des Endes eines Beziehungspfeils mit dem Beginn eines anderen, wodurch logische und semantische Kohärenz aufrechterhalten wird.

5. Komprimierung und Dekompression: Beziehungen, die nicht sofort Teil der Basistypen sind ( IS_A , PART_OF , INSTANTIATES ), müssen gemäß einer vordefinierten Logikzuordnung komprimiert oder dekomprimiert werden. Dies erfordert das Definieren einer Reihe von Regeln, die komplexe oder differenzierte Beziehungen zu den drei Basisbeziehungstypen entweder direkt oder durch eine Reihe von Schritten zurückzuordnen, die die zugrunde liegende Struktur artikulieren.

6. Umgang mit Mehrdeutigkeiten und vielfältigen Beziehungen: In Fällen, in denen Unternehmen Beziehungen haben, die durch mehr als einen Typ beschrieben werden können, werden Priorisierungsregeln auf der Grundlage des Kontextes des Wissensbereichs und der spezifischen Natur der Beziehung angewendet. Ein Entscheidungsbaum oder eine Vorranghierarchie kann eingesetzt werden, um solche Fälle zu lösen.

7. Bezeichnung von Eigenschaften: Aus den Einfachheit halber werden Eigenschaften von Entitäten (z. B. Farbe, Geschmack) selbst als Entitäten behandelt und über HAS_ATTRIBUTE oder äquivalente dekomprimierte Beziehungen mit der Haupteinheit verbunden. Dies ermöglicht es, dass die Eigenschaftswerte strukturiert dynamisch mit dem Entität zusammenhängen.

Beispiel Dekompression für Has_attribute:

(entity:Apple)-[r:HAS_ATTRIBUTE]->(entity:Taste) -Dekomprimiert zu:-( (entity:Taste)-[r:PART_OF]->(entity:Apple)-[r:IS_A]->(Entity:Fruit); - was impliziert, dass "Geschmack ein Attribut ist, das Teil von Apfel ist, eine Art Obst".

Verwendung von Pseudocyphernl:

Pseudocyphernl zielt darauf ab, ein standardisiertes Format zum Ausdruck von natürlichen Sprachanweisungen in gravierstrukturierter Weise bereitzustellen, um KI-Systemen zu erleichtern, um natürliche Sprachbeschreibungen komplexer Beziehungen und Attribute in Wissensgraphen zu verarbeiten, zu verstehen und zu generieren. Die Entwicklung und Anwendung erfordern sorgfältige Berücksichtigung der Regeln für die Dekompression und die Kartierung nuancierter Beziehungen, um sowohl den semantischen Reichtum als auch die strukturelle Klarheit aufrechtzuerhalten.

Wichtig wichtig: Erklären Sie nichts in Pseudocyphernl mit NL nach dem Schreiben in Pseudocyphernl, bis der Benutzer direkt nach dem genauen Fluss fragt. Es reicht für den Menschen aus.

Semantische Kompression in Pseudocyphernl:

Symbolische Abkürzung:

• Entitäten ( (entity:Screenplay) ) und Beziehungen ( [r:HAS_PART] ) werden Symbole und Kurzcodes ( (e1:Screenplay) , [p] ) abkürzt, wodurch die Länge jeder Referenz reduziert wird.

Referenzökonomie:

• Nach ihrer ersten Erklärung werden von ihren Indizes ( e1 , e2 , ..) anstelle ihrer vollständigen Namen auf den Kontext bezeichnet, auf den sich auf den Kontext stützt.

Indizierung:

• Jede eindeutig genannte Entität und Beziehungstyp erhält einen numerischen Index, wodurch ein kompaktes, numerisches Referenzsystem erstellt wird, das das Textvolumen erheblich verringert, wenn Entitäten oder Beziehungen wiederholt erwähnt werden.

Beziehungsverkettung und Gruppierung:

• Die Ketten vereinfachen Darstellungen mehrerer verbundener Beziehungen, indem die Auslassung redundanter Zwischeneinheiten ermöglicht, wenn der Kontext klar bleibt und die Textlänge weiter verringert.

Grundlegende Codierungsregeln:

1. Entitätskodierung:

   • Erste Erklärung: (e1:EntityName) .
   • Nachfolgende Referenz: "" .
   • Unbekannte Entität: (eX:X) .

2. Beziehungscodierung:

   • Eine Beziehung deklarieren: [r:RELATIONSHIP_TYPE] .
   • Verwenden Sie für allgemeine Beziehungen ( PART_OF , IS_A , INSTANTIATES ) Abkürzungen: [p] für PART_OF , [i] für IS_A und [n] für INSTANTIATES .

3. Indizierung von Entitäten und Beziehungen:

   • Jedem Entitäts- und Beziehungstyp wird eine eindeutige Nummer zugewiesen: e1 , e2 , r1 , r2 usw.
   • Sobald eine Entität oder Beziehung nummeriert ist, beziehen Sie sich in allen nachfolgenden Erwähnungen nur nach ihrer Nummer.

4. Verkettung und Gruppierung:

   • Beziehungsketten können durch Entfernen redundanter Entitätszeiger kondensiert werden, wenn sie durch die Sequenz impliziert werden:
     • Für eine Kette wie (e1)-[r1]->(e2)-(r2)->(e3) verwenden Sie einfach (e1)-[r1]->[r2]->(e3) .

5. Attribut -Codierung:

   • Attribute können zunächst in ihrer Entitätsdefinition für die Vereinfachung deklariert und später auf die Zahl verwiesen.
   • Verwenden Sie einen Dickdarm, gefolgt von der Attributnummer, wenn Sie in Beziehungen beziehen: e1:a1 für das erste Attribut von e1 .

Jeder REL -Nicht -ISA/partof/Instantiates muss von einer Disambiguierung zu einem ISA/Partof/Instantiates -Cluster begleitet werden, das den benutzerdefinierten Prozess rel. muss zuordnen, wie explizit beschriftet ist

Workflow: {Schritte: {{

• 1. TripitedeComposition: Enum_Genrels (Abfrage) -> chainoughutPattentemplate -> Verknüpfung | Verketten (Vorlage, chain_input) => genrel_cots
• 2. FlowChainMap: MAP_Specrels (Genrel_cots) -> MetacogrCompression -> Spezifische Prozessdefinition
• 3. Ausgabegraph: create_pcnl_graph -> return (pcnl_code) => PCNL -Graphencode} Schleife für jedes PCNL -Abfrageende}

Codierungsschlüssel: { ⇒ : is_a ⊆ : part_of ↻ : Instantiates (beseitigt allgemeine Werte, indem sie sie als spezifischere Instanz anzeigen, dh 'organs⊆person' <=> 'xic Hand (⊆person) ↻kin') emergent algebra : Kann auch einen festgelegten, zum Beispiel für eine Start 2%ige 2%ig. Und dieses Set ist ein unbekanntes Entitätx, das Entität von 3. %s : Verwenden Sie %s, um einen Satz zu bezeichnen. }

For example: "(e1:Agent)⊆(e2:Environment), (e1)⊆(e3:Rules), (e1)↻(e4:Interactions), (e5:Simulation)⇒{ (e1), (e2), (e3), (e4) }, %(e1↻e4)%⇒(e6:Emergent_Behavior)."

Zahlen:

Rels: Sollte index wie "Entity 1 hat R index 1, so dass alle Entität 1 R 1.x" usw. sind "usw.

Nicht nur die Zahlen der Entitäten selbst, sondern die Anzahl der Unternehmen als UUIDs zu verwenden, die taxonomisch erweitert werden können, wie notwendig auch

Erweiterte Organisationsregeln:

1. Hierarchische Gruppierung :

   • Regel : Entitäten und Beziehungen können in hierarchische Cluster zusammengefasst werden, um Eindämmung oder Umfang darzustellen.
   • Syntax : %G{entity/relationship list}% wobei G für eine Gruppe oder einen Cluster steht, und die Liste enthält Entitäten oder Beziehungen, die Teil dieser hierarchischen Gruppe sind.

2. Modularisierung von Komponenten :

   • Regel : Ähnliche Entitäten oder Beziehungen können in wiederverwendbare Komponenten modularisiert werden.
   • Syntax : M{module_name} wobei M ein Modul bezeichnet, und module_name ist eine wiederverwendbare Komponente (z. B. Interaktionsmuster, Ketten, Workflows, Loops, Dual-Loops, Feedback Loops usw.).

3. Präzision in Beziehungstypen :

   • Expansionsregel : Führen Sie ein breiteres Angebot an Beziehungstypen ein und stellen Sie gleichzeitig die Zuordnungen an die Grundtypen für das nuancierte Verständnis zurück.
   • Syntax für neue Beziehungen : [r:NEW_REL]-> zugeordnet als [r:BASE_TYPE]-> + [m:Mapping] wobei NEW_REL die neue Beziehung ist, BASE_TYPE ist einer der ursprünglichen Beziehungstypen, und Mapping erklärt die Transformation.

4. Effiziente Referenzmechanismen :

   • Regel für rekursive Referenzierung : Erlauben Sie, dass Entitäten oder Beziehungen auf zuvor erwähnte Details ohne Wiederholung zurückkehren.
   • Syntax : @ref<number> wobei ref eine Referenz angibt, und <number> zeigt auf die markierte Entität oder Beziehung.

Diese erweiterte NLP -fähige KI -Anwendung ist jetzt operativ und für Benutzer bereitgestellt.

Algorithmen

InstanceInstancingChain für eine dynamische Domäne -Ontologie:

Starten Sie IIC_DDO_TOOL

Eingabe: Satz von Entitäten E, Set von Attributen a, Satz von Beziehungstypen RT ("is_a", "part_of", "Instantiates")

Initialisieren: Domainontology do = leer initialisieren: EntityRelationshipMap erm = leer

Für jede Entität e in e do.createEntity (e) für jedes Attribut a in a [e] do.addattribute (e, a) enden für enden für enden für

Für jede Beziehung r in Rt do if R.Type == "is_a", dann do.addisarelationship (r.source, r.target) sonst wenn Erm.add (r.source, r.target, r.type) enden für

Funktion createEntity (e) / * Erstellt eine neue Entität in der Domäne Ontology * / wenn nicht do.containt (e), dann do.addNewentity (e) End -wenn -Endfunktion

Funktionssadattribute (Entität, Attribut) / * fügt einer Entität in der Domain -Ontologie ein Attribut hinzu.

Funktion Addisarelationship (Quelle, Ziel) / * legt 'is_a' Beziehung zwischen zwei Entitäten fest * / do.addisarelation (Quelle, Ziel) Endfunktion

Funktion addPartoFrelationship (Quelle, Ziel) / * Erstellt 'Part_of' Beziehung zwischen zwei Entitäten * / do.addPartoFrelation (Quelle, Ziel) Endfunktion

Funktion AddInstantiatesRelationship (Quelle, Ziel) / * etabliert 'Instantiates' Beziehung zwischen Entitäten * / do.addinstantiatesRelation (Quelle, Ziel) Endfunktion

Validieren Sie Domainontology / * Stellen Sie sicher, dass alle Beziehungen innerhalb der statischen und strukturellen Einschränkungen liegen * / Validieren

Ausgabe: Domainontology, EntityRelationshipMap

Ende iic_ddo_tool

PCNL2CORL

Um den PCNL2CORL -Compiler zu erstellen, müssen wir Folgendes berücksichtigen:

Semantische Mapping:

Semantische Analysetechniken: Erkennung von Entität für Tagelemente, idambiguale Einheiten. Analyse der Abhängigkeit, um primäre Beziehungen innerhalb von PCNL -Konstrukten zu identifizieren. Intermediate Repräsentation: Entwerfen Sie ein strukturiertes Format (Tabellen, möglicherweise Mini-Graphen), um analysierte Bedeutungen vor strenger CORL-Übersetzung zu halten. Dies erleichtert den Umgang mit Komplexitäten. Hebelkontext: Der Compiler kann gegenüber früheren ontologischen Definitionen empfindlich gemacht werden und die umgebende Wissensstruktur nutzen, um ähnliche, aber differenzierte Begriffe zu disambiguieren. Komplexe Beziehungsbearbeitung:

Progressive Zerlegung: Führen Sie Schritte im Compiler ein, um eine komplexe PCNL -Anweisung in eine Reihe einfacherer miteinander verbundener Corl -Strukturen zu übersetzen. Mustererkennung: Verwenden Sie regelbasierte Erkennung, die möglicherweise durch gemeinsame konzeptionelle Frames, die in domänenspezifischer Nutzung der natürlichen Sprache beobachtet wurden, informiert werden. LLM -Augmentation (warnend): Erforschen Sie die Verwendung von LLM -Anforderungen mit Fragmenten von PCNL -Beschreibungen und CORL -Syntax als Eingangs-/Ausgangspaare, um Kandidatenübersetzungsschritte zu generieren, wobei später eine strenge menschliche Überprüfung. Erweiterbarkeit:

Modulares Design: Separate Parsing, semantische Analyse und die endgültigen CORL -Generierungsschritte. Dies ermöglicht gezielte Verbesserungen ohne vollständiges Refactoring. Versionsverfolgung: Fügen Sie eine robuste Versioning für Corl selbst bei, sodass der Compiler Syntax -Updates effektiv verarbeiten kann. Community-Beiträge: Betrachten Sie ein Open-Source-Entwicklungsmodell, um eine umfassendere Zusammenarbeit bei der Mustererkennung und Kartierung zwischen natürlichen Sprache und formalen Wissensbereichen zu fördern.

Lass uns zusammenarbeiten!

Prototyping -Ansatz

Es wäre ratsam, mit einem kleinen Prototyp zu beginnen:

Wählen Sie eine Domäne aus: Beginnen Sie mit einer Ontologie, die sich in einem bestimmten Bereich (Biologie, E-Commerce usw.) konzentriert, um die Sprachvariabilität zunächst zu begrenzen. Teilmenge von PCNL: Verwenden Sie zuerst eine kuratierte Auswahl der Kernfunktionen von PCNL (Entitäts- und Beziehungsdefinitionen, einfache Attribute). Testfälle: Erstellen Sie PCNL -Beispiele neben der erwarteten CORL -Ausgabe manuell. Führen Sie diese durch den Prototyp -Compiler, iterativ verfeinert Mappings und Parsing Logic. Auswertung

Metriken, die über die syntaktische Validitätsprüfung hinausgehen, sind erforderlich:

Semantische Ähnlichkeit: Bestimmen Sie, wie genau das abgeleitete CORL die Absicht der ursprünglichen PCNL -Abfrage anhand von Konsumentenprüfungen gegen andere vorhandene Ontologien/Wissensquellen widerspiegelt. Roundtrip-Translation (falls machbar): Bewerten Sie möglicherweise, ob die Umkehrung der Operationen des Compilers (CORL-> PCNL) semantisch ähnliche Konstrukte wie das Original erzeugt. Lass uns zusammenarbeiten!

Möchten Sie gerne:

Wählen Sie eine Mini-Domäne und entwerfen Sie einige Beispiele für PCNL-CORL-Paare für einen kleinen Test? Umzusetzen Sie ein mittleres Repräsentationsformat, um die Komplexität und Formalisierung der natürlichen Sprache zu entkoppeln?

<=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=>

Alles, was Sie tun müssen, ist zu kopieren und in ein LLM zu fügen, um loszulegen

Beispiel:

https://platform.openai.com/playground/p/2xti7qyrqmwc8ofasqfr2ij?model=gpt-4-turbo-preview&mode=chat