Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Fixes 3737: Add support for AWS Bedrock for ml procedures #388

Closed
wants to merge 12 commits into from

Conversation

vga91
Copy link
Owner

@vga91 vga91 commented Oct 17, 2023

~Per evitare di importare sdk di aws, ho creato un file per signature V4: https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html. ~
Cambiato con questo, dovrei testarlo.

Bedrock procedures:

  • apoc.ml.bedrock.custom: customizzabile (endpoint, modelId, http method, ....)
  • procedure ad-hoc per i model, tipo questo, con un endpoint custom e che ritornano un tipo di dato coerente in base alla response, invece di ObjectResult:
    • apoc.ml.bedrock.list
    • apoc.ml.bedrock.jurassic
    • apoc.ml.bedrock.anthropic.claude
    • apoc.ml.bedrock.titan.embedding
    • apoc.ml.bedrock.stability

Se l'endpoint non è definito nelle procedure tranne la .list, viene messo quello di default https://bedrock-runtime.us-east-1.amazonaws.com/model/<MODEL_ID>/invoke

public static final String ALL = "*/*";
public static final String JSON = "application/json";

enum ModelId {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no i modelli li metterei plain string altrimenti poi dobbiamo fare una release ogni volta che ne aggiungono uno nuovo o una nuova versione

import java.util.List;
import java.util.Map;

public class ModelItemResult {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

questo perche non record?

Copy link
Owner Author

@vga91 vga91 Oct 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perché essendoci parecchi parametri, mettendo record credo sia obbligato a mettere un costruttore tutti i parametri, tipo:

public static ModelItemResult from(Map<String, Object> map) {
String modelId = (String) map.get("modelId");
// simile per gli altri

// costruttore con tutti i parametri
        return new ModelItemResult(modelId,
                modelArn,
                modelName,
                providerName,
                responseStreamingSupported,
                customizationsSupported,
                inferenceTypesSupported,
                inputModalities,
                outputModalities);

Con class mi sembra più pulito, facendo semplicemente this.modelName = (String) map.get("modelName");, nel costruttore

* Similar to JsonUtil.loadJson(..) but works e.g. with GET method as well,
* for which it would return a FileNotFoundException
*/
public static Stream<Object> getModelItemResultStream(String method, HttpClient httpClient, String payloadString, Map<String, Object> headers, String endpoint, String path, List<String> pathOptions) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

o gli troviamo un nome generico che non contenga model o lo mettiamo dove stanno le procedure

/**
* Mock tests, with local endpoint
*/
public class BedrockTest {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

qui bisogna fare pulizia

Comment on lines 7 to 8
CUSTOM("custom-models"),
FOUNDATION("foundation-models");

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

anche questi li metterei come stringa per lo stesso motivo dei modelli

@vga91 vga91 closed this Oct 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants