Closed Jtewen closed 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.
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.
@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.
🤖
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.
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.
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?
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
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
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?
I believe I've identified a fix! Will merge and release tonight.
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
All working now! As always, I appreciate the speedy fixes.
Awesome! And this type of issue is pretty serious so please ping if you see anything like it again.
I'm specifically using Bedrock and HNSWLib. These are the errors, Bedrock:
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.