Utilisation de Claude Sonnet d'Anthropic pour générer des rapports

Génération de rapports à l'aide du Sonnet Claude 3.5 d'Anthropic : Comparaison de deux méthodes

Bonjour à tous ! Je m'appelle Raphael, co-fondateur et CTO de la société immobilière brésilienne Pilar. Pilar fournit des logiciels et des services aux agents immobiliers et aux sociétés de courtage, en utilisant un modèle de frais de réussite faibles. Au lieu de facturer des frais initiaux élevés, nous prélevons une petite commission sur chaque transaction réussie, liant directement notre succès à celui de nos clients. Notre équipe de 20 technologues innove constamment et le dernier produit est Pilar Homes, un nouveau portail immobilier conçu pour offrir la meilleure expérience aux acheteurs de maison et aux agents immobiliers.

Dans cet article, je partagerai notre expérience d'utilisation de l'intelligence artificielle pour générer des rapports, en particulier le Sonnet Claude 3.5 d'Anthropic, et comparerai deux méthodes différentes.

Notre philosophie de gestion des tâches sera détaillée dans un prochain article (restez connectés !), mais bref, ces tâches finissent sur le tableau « Tech Help Desk » sous forme de tickets Jira. La génération de rapports est l'une de ces tâches, la plupart des tâches prenant environ 30 minutes aux ingénieurs, les rapports complexes prenant rarement plus de quelques heures. Mais les choses changent. Les marques de boutique que nous avons démarrées avec un ou deux partenaires se développent dans de plus grandes agences et nous signons davantage de contrats avec des acteurs établis du secteur. Même si l'augmentation du nombre d'heures d'ingénieur pourrait répondre aux besoins croissants en matière de reporting, j'ai vu une opportunité d'explorer les agents d'IA et d'apprendre des modèles architecturaux dans des environnements réels.

Méthode 1 : Laisser l'IA gérer entièrement et atteindre la limite de max_tokens

Dans notre approche initiale, nous avons exposé l'outil au modèle Sonnet 3.5 de Claude, lui permettant d'effectuer des requêtes de base de données, de convertir les documents récupérés au format CSV et d'écrire ses résultats dans un fichier .csv.

Voici notre structure, fortement inspirée du billet de blog ci-dessus :

<code># 每个collection对象描述一个MongoDB集合及其字段
# 这有助于Claude理解我们的数据模式
COLLECTIONS = [
    {
        'name': 'companies',
        'description': 'Companies are the real estate brokerages. If the user provides a code to filter the data, it will be a company code. The _id may be retrieved by querying the company with the given code. Company codes are not used to join data.',
        'fields': {
            '_id': 'The ObjectId is the MongoDB id that uniquely identifies a company document. Its JSON representation is \"{"$oid": "the id"}\"',
            'code': 'The company code is a short and human friendly string that uniquely identifies the company. Never use it for joining data.',
            'name': 'A string representing the company name',
        }
    },
    # 此处之后描述了更多集合，但思路相同...
]

# 这是client.messages.create的“system”参数
ROLE_PROMPT = "You are an engineer responsible for generating reports in CSV based on a user's description of the report content"

# 这是“user”消息
task_prompt = f"{report_description}.\nAvailable collections: {COLLECTIONS}\nCompany codes: {company_codes}\n.Always demand a company code from the user to filter the data -- the user may use the terms imobiliária, marca, brand or company to reference a company. If the user wants a field that does not exist in a collection, don't add it to the report and don't ask the user for the field."
</code>

report_description est juste un argument de ligne de commande lu via argparse, company_codes est récupéré de la base de données et exposé au modèle afin qu'il sache quelles entreprises existent et quels codes d'entreprise se trouvent dans l'entrée utilisateur. Exemples : (MO - Mosaic Homes, NV - Nova Real Estate, etc.).

Les outils disponibles pour les modèles incluent : find et docs2csv.

<code>def find(collection: str, query: str, fields: list[str]) -> Cursor:
    """Find documents in a collection filtering by "query" and retrieving fields via projection"""
    return db.get_collection(collection).find(query, projection={field: 1 for field in fields})

def docs2csv(documents: list[dict]) -> list[str]:
    """
    Convert a dictionary to a CSV string.
    """
    print(f"Converting {len(documents)} documents to CSV")
    with open('report.csv', mode='w', encoding='utf-8') as file:
        writer = csv.DictWriter(file, fieldnames=documents[0].keys())
        writer.writeheader()
        writer.writerows(documents)
    return "report.csv"</code>

Claude a pu appeler la fonction find pour effectuer des requêtes et des projections bien structurées sur notre base de données et générer de petits rapports CSV (moins de 500 lignes) à l'aide de l'outil docs2csv. Cependant, les rapports plus volumineux déclenchent des erreurs max_tokens.

Après avoir analysé nos modèles d'utilisation des jetons, nous avons réalisé que la majeure partie de la consommation de jetons provient du traitement des enregistrements individuels via le modèle. Cela nous a incité à explorer une autre approche : laisser Claude générer du code de traitement au lieu de traiter directement les données.

Méthode 2 : la génération de code Python comme solution

Bien que résoudre la limite max_tokens ne soit pas techniquement difficile, cela nous oblige à repenser notre approche pour résoudre le problème.

Solution ? Laissez Claude générer du code Python qui s'exécutera sur nos processeurs au lieu de traiter chaque document via l'IA.

J'ai dû modifier les invites des personnages et des quêtes et supprimer les outils.

Ce qui suit est l'essentiel du code de génération de rapport.

La commande pour générer le rapport est :

<code># 每个collection对象描述一个MongoDB集合及其字段
# 这有助于Claude理解我们的数据模式
COLLECTIONS = [
    {
        'name': 'companies',
        'description': 'Companies are the real estate brokerages. If the user provides a code to filter the data, it will be a company code. The _id may be retrieved by querying the company with the given code. Company codes are not used to join data.',
        'fields': {
            '_id': 'The ObjectId is the MongoDB id that uniquely identifies a company document. Its JSON representation is \"{"$oid": "the id"}\"',
            'code': 'The company code is a short and human friendly string that uniquely identifies the company. Never use it for joining data.',
            'name': 'A string representing the company name',
        }
    },
    # 此处之后描述了更多集合，但思路相同...
]

# 这是client.messages.create的“system”参数
ROLE_PROMPT = "You are an engineer responsible for generating reports in CSV based on a user's description of the report content"

# 这是“user”消息
task_prompt = f"{report_description}.\nAvailable collections: {COLLECTIONS}\nCompany codes: {company_codes}\n.Always demand a company code from the user to filter the data -- the user may use the terms imobiliária, marca, brand or company to reference a company. If the user wants a field that does not exist in a collection, don't add it to the report and don't ask the user for the field."
</code>

Contenu Python généré par Claude (fonctionne bien) :

<code>def find(collection: str, query: str, fields: list[str]) -> Cursor:
    """Find documents in a collection filtering by "query" and retrieving fields via projection"""
    return db.get_collection(collection).find(query, projection={field: 1 for field in fields})

def docs2csv(documents: list[dict]) -> list[str]:
    """
    Convert a dictionary to a CSV string.
    """
    print(f"Converting {len(documents)} documents to CSV")
    with open('report.csv', mode='w', encoding='utf-8') as file:
        writer = csv.DictWriter(file, fieldnames=documents[0].keys())
        writer.writeheader()
        writer.writerows(documents)
    return "report.csv"</code>

Conclusion

Notre parcours avec Claude 3.5 Sonnet montre que l'IA peut améliorer considérablement l'efficacité opérationnelle, mais la clé du succès réside dans le choix de la bonne architecture. L’approche de génération de code s’est avérée plus puissante que le traitement direct de l’IA tout en conservant les avantages de l’automatisation.

En plus de construire correctement des rapports, la méthode de génération de code permet également aux ingénieurs de revoir le travail de l'IA, ce qui est une très bonne chose.

Pour automatiser entièrement le processus, éliminer l'implication humaine et gérer de plus grands volumes de rapports, répartir le travail entre plusieurs instances d'agent - chacune gérant moins de jetons - serait une évolution naturelle du système. Pour les défis architecturaux liés à de tels systèmes d’IA distribués, je recommande vivement le dernier article de Phil Calçado sur la création de produits d’IA.

Principaux enseignements tirés de cette mise en œuvre :

• Le traitement direct de l'IA fonctionne pour des ensembles de données plus petits
• La génération de code offre une meilleure évolutivité et maintenabilité
• L'examen humain augmente la fiabilité

Références

• Documentation Anthropique
• Anthropic Claude de Thomas Taylor avec des outils utilisant le SDK Python
• Création de produits IA - Partie 1 : Architecture backend par Phil Calçado

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!