langchain-ai / langchainjs

🦜🔗 Build context-aware reasoning applications 🦜🔗
https://js.langchain.com/docs/
MIT License
12.36k stars 2.09k forks source link

Retrievers and Models aren't assignable to their respective base interfaces #3918

Closed Jtewen closed 8 months ago

Jtewen commented 8 months ago

I'm specifically using Bedrock and HNSWLib. These are the errors, Bedrock:

export const multiQueryRetriever = MultiQueryRetriever.fromLLM({
    llm: baseModel,
    retriever: await baseRetriever(),
    prompt: multiQueryPrompt
});

Type 'Bedrock' is not assignable to type 'BaseLanguageModelInterface<any, BaseLanguageModelCallOptions>'.

With a similar error for the HNSWLib retriever.

I believe this causes more errors when using LCEL with RunnableSequence.from() and passing an array containing an LLMChain.

The chain is fully functional if I suppress the type errors and assert the LLMChain as Runnable.

dosubot[bot] commented 8 months ago

🤖

Hey @Jtewen, great to see you again! Looks like you're building something interesting with Bedrock and HNSWLib. Let's iron out these issues together!

Based on the provided context, it seems like you're trying to assign instances of Bedrock and HNSWLib to BaseLanguageModelInterface<any, BaseLanguageModelCallOptions> and BaseRetrieverInterface respectively. However, the type errors suggest that these classes might not be fully compatible with the base interfaces.

For Bedrock, it should be compatible with BaseLanguageModelInterface<any, BaseLanguageModelCallOptions> if it correctly extends BaseBedrock and BaseBedrock correctly implements BaseLanguageModelInterface<any, BaseLanguageModelCallOptions>. You might want to check the implementation of Bedrock and BaseBedrock to ensure they correctly implement the base interface.

For HNSWLib, it should be compatible with BaseRetrieverInterface if it correctly extends SaveableVectorStore and SaveableVectorStore correctly implements BaseRetrieverInterface. You might want to check the implementation of HNSWLib and SaveableVectorStore to ensure they correctly implement the base interface.

If the implementations are correct and you're still getting type errors, it might be due to some TypeScript configuration issues. You might want to check your tsconfig.json file to ensure it's correctly configured.

Regarding the issue with RunnableSequence.from(), it's hard to say what the problem might be without more information. Could you provide more details about the error message you're getting and the code you're using to create the RunnableSequence?

If you're sure that the implementations of Bedrock, HNSWLib, and RunnableSequence are correct and you're still getting type errors, you might want to consider using type assertions as a workaround. However, please note that type assertions can potentially hide real type errors and should be used with caution.

Here's how you can use type assertions:

const bedrock = new Bedrock() as BaseLanguageModelInterface<any, BaseLanguageModelCallOptions>;
const hnswlib = new HNSWLib() as BaseRetrieverInterface;

I hope this helps! If you have any more questions, feel free to ask.

Sources


This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

Jtewen commented 8 months ago

@dosu-bot Asserting the model and retriever as their respective interfaces works, allowing me to remove the typescript error suppression as follows:

export const multiQueryRetriever = MultiQueryRetriever.fromLLM({
    llm: baseModel as BaseLanguageModelInterface,
    retriever: await baseRetriever() as BaseRetrieverInterface,
    prompt: multiQueryPrompt
});

However, it seems like the intended functionality is for TypeScript to infer this without the need for any type assertions.

dosubot[bot] commented 8 months ago

🤖

Based on the provided context, it seems like the Bedrock class and HNSWLib class are not directly implementing the BaseLanguageModelInterface<any, BaseLanguageModelCallOptions> and BaseRetrieverInterface interfaces respectively. This could be the reason why TypeScript is unable to infer the types correctly.

TypeScript uses structural typing to determine type compatibility. This means that a class is considered to implement an interface if it has all the properties and methods that the interface requires, regardless of whether it explicitly implements the interface using the implements keyword.

If the Bedrock class and HNSWLib class do not have all the properties and methods required by the BaseLanguageModelInterface<any, BaseLanguageModelCallOptions> and BaseRetrieverInterface interfaces, TypeScript will not consider them to be assignable to these interfaces, and you will get a type error.

To fix this issue, you can modify the Bedrock class and HNSWLib class to explicitly implement the BaseLanguageModelInterface<any, BaseLanguageModelCallOptions> and BaseRetrieverInterface interfaces. This will require adding any missing properties and methods to these classes.

Here's an example of how you can modify the Bedrock class to implement the BaseLanguageModelInterface<any, BaseLanguageModelCallOptions> interface:

export class Bedrock extends BaseBedrock implements BaseLanguageModelInterface<any, BaseLanguageModelCallOptions> {
  // ... existing code ...

  // Add any missing properties and methods required by BaseLanguageModelInterface
}

And here's an example of how you can modify the HNSWLib class to implement the BaseRetrieverInterface interface:

export class HNSWLib extends SaveableVectorStore implements BaseRetrieverInterface {
  // ... existing code ...

  // Add any missing properties and methods required by BaseRetrieverInterface
}

After making these changes, TypeScript should be able to infer the types correctly without the need for any type assertions.

If you're still having issues, it would be helpful to see the exact definitions of the BaseLanguageModelInterface<any, BaseLanguageModelCallOptions> and BaseRetrieverInterface interfaces, as well as the full code of the Bedrock and HNSWLib classes. This will allow me to provide more specific advice on how to fix the type errors.

Sources


This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

jacoblee93 commented 8 months ago

Thanks for the report - can you share your package.json and if possible figure out what versions of @langchain/core and/or @langchain/community you have installed from your yarn.lock file?

Jtewen commented 8 months ago

Sure, let me know if you need anything else.

package.json:

{
    "name": "product-resources-chatbot",
    "private": true,
    "version": "0.0.0",
    "type": "module",
    "scripts": {
        "dev": "vite",
        "build": "tsc && vite build",
        "backend": "cd backend && npx tsc && node index.js",
        "lint": "DEBUG=eslint:cli-engine eslint .",
        "preview": "vite preview",
        "tauri": "tauri"
    },
    "dependencies": {
        "@aws-sdk/client-bedrock-runtime": "^3.485.0",
        "@aws-sdk/credential-provider-node": "*",
        "@smithy/protocol-http": "^3.0.12",
        "@smithy/signature-v4": "^2.0.19",
        "hnswlib-node": "^1.4.2",
        "langchain": "^0.0.214",
        "mongodb": "^5.9.2",
        "undici": "^6.2.1"
    },
    "devDependencies": {
        "@heroicons/react": "^2.1.1",
        "@types/react": "^18.2.46",
        "@types/react-dom": "^18.2.18",
        "@vitejs/plugin-react": "^4.2.1",
        "react": "^18.2.0",
        "react-dom": "^18.2.0",
        "typescript": "*",
        "vite": "^5.0.10"
    },
    "overrides": {
        "langchain": {
            "puppeteer": "^21"
        }
    },
    "prettier": {}
}

langchain version: 0.0.214 @langchain/core version: 0.1.8 @langchain/community version: 0.0.14

jacoblee93 commented 8 months ago

Will look into this - in the meantime, can you try setting a resolutions/overrides field on @langchain/core as documented here?

https://js.langchain.com/docs/get_started/installation#installing-integration-packages

jacoblee93 commented 8 months ago

I believe this is caused by somehow getting into a state where you have multiple versions of @langchain/core but am not sure how that happened - was this an existing project that you updated?

jacoblee93 commented 8 months ago

I believe I've identified a fix! Will merge and release tonight.

jacoblee93 commented 8 months ago

Please try locking the version to 0.1.10 in your package.json as shown here - LMK if that fixes it for you and reopen this if not:

https://js.langchain.com/docs/get_started/installation#installing-integration-packages

Jtewen commented 8 months ago

All working now! As always, I appreciate the speedy fixes.

jacoblee93 commented 8 months ago

Awesome! And this type of issue is pretty serious so please ping if you see anything like it again.