Shantanu Sharma

Okay. So my name is Shantun Sharma. I'm working as a senior data scientist at Tata 1 MG. I lead a pricing team here, which is a pricing project, what we do. So if you will go to Tata 1 MG and every price of a medicine is dynamic in nature. And that is coming from an algorithm that I have created using deep learning and reinforcement learning. So that is a key point and we are making around 6 to 7% more profit than business using my algorithm. And yeah. So right now, I'm working and I'm working in the health care domain. This is one of my projects. And one of my projects is using LN, which I am working on right now. So what we do, we create a health summarization bot where you can approach a prescription. Usually a patient approaches a prescription and asks questions on that. So you can ask the prescription, if it's not very clear, or you can ask any questions regarding your prescription or even regarding 1 mg or regarding some healthcare domain, you can ask any question like how much water should I drink in X sugar or something like that. Yeah. We are using RAG here and LM Open GPT, like, all the stuff to implement it. So, yeah, these are the current projects I am working on. I have worked on a few other projects here, like fraud detection, anomaly detection, and all. Yeah. Before that, I was working in a company called Fluke Labs. So what I was doing, I was developing machine learning solutions for banks, some top 5 banks of India. We were developing machine learning solutions for them. And, like, we developed an attrition system, a recommendation system. We were improving the monthly average balance of the customers, creating dashboards, and performing multiple EDAs. Yeah. So it has been 7 years since I have been in this Python data science machine learning background. And, yeah, that's all.

Could you propose a method for integrating prompt engineering feedback into vector database using TypeScript? Okay. So, what we can do is usually, I've worked with Python and the vector DB and all. So, we can simply use TypeScript. There's no issue here. What we can do is setting up the experiment here. And, in Python, you install using Pip and all. Here, you can do using Node.js to install the packages, like NPM and all. Okay? So what happens then, in TypeScript, you can define some data structures, like you have to define feedback and any prompt which we need to find and prompt could contain used ID, the text, and the vector. Then, you can create a function to calculate the vector from the prompt. Like, you're doing that. Then, there can be a function which will store feedback in the vector database. As everything needs to be stored in the vector database. Then, you can have a function to integrate the feedback. Okay? So yeah. These are the main high-level steps which you can use to create a problem if you run into a vector DB. Okay? And for calculating vectors, you can create a function and calculating vector. You can use an external API. And for the model, you can go for GPT or the LLaMA or anything.

How can the builder pattern in TypeScript simplify the process of crafting complex prompt for langchain.js? Okay. sure. So, okay. What happens here? That, so this would this build up pattern, which you're talking about in typescript, what it does, it, like, it provides a structured and flexible way to construct prompt, like, your in a step by step fashion manner. And this pattern, this builder pattern, what it does, it helps you manage the option parameters also, which improves code, like, re even the like, improves code readability and makes it easier to maintain and, like, makes you maintain and modify the prompt creation process. Okay. So yeah. What? Yeah. That's 1.

interface Query { type: 'vector' | 'similarity' | 'other'; } interface VectorQuery extends Query { type: 'vector'; vector: { id: string; dimensions: number; }; } interface SimilarityQuery extends Query { type: 'similarity'; vector: { id: string; dimensions: number; }; target: { id: string; dimensions: number; }; } interface QueryManager { execute(query: Query): void; } class VectorDB implements QueryManager { execute(query: Query): void { // implementation } }

What strategy would you use to handle vector DB schema? Changing in a typeshift code base. Okay. So, not just, TypeScript. We can go for any like, you know, it would work same in Python. So, but, that when you talk about TypeScript, handling this team much in vector DB, whether types of code, it involves, like, in the types of it involves multiple strategies which ensure, like, data integrity, minimize downtime, and maintain code type. So, what you can do, first, you can define your schema. That will be any, so where you are meeting different versions of your schema using types of interfaces. So, where, let's say, you haven't created an interface for document and you've for document 1 document 2 just like that. Then, you can create a migration script where you can write a script to migrate data from old schema to new schema. Okay? Then, you can update query builders. Here, what you're ensuring, is that query builders are aware of the schema. Like, the okay. So, what you're doing, is ensuring the query builders are aware of all the schema versions, and you can handle then you want to handle appropriately. Okay? Then, maybe you can implement a schema registry, sort of thing, where you maintain the history of all the schema versions and also the particular versions. Also, what you can do, is handle a document. For that, you can use a factory pattern to handle the various documents. Okay? And, oh, okay. It actually came out. And maybe you can handle backward and forward compatibility, so that the application can read and write both, old and new version schemas. It can read both. Okay? Then, yeah. So, and for obviously, when that's all done, you can go for testing and validation, like, you can test your migration script through, and, like, schema handling, like, and schema handling to ensure the integrity where you want, like, based on some types of code. Yeah.

What TypeScript best practices ensure safe communication of data from vector DB in an AI context? Time is crucial. Best practices ensure safe data consumption. Okay, so you want to ensure safe communication of data from vector DB in an AI context using TypeScript. You can use some practices that will enhance the safety, security, and maintainability. One could be runtime guards for validation. So what you can do is implement runtime guards and run-time validation to ensure the data conforms to expected types. You want data to be of expected types only. Another thing is strong typing and interfaces. You are defining clear and stricter types of data models, queries, and responses to ensure type safety. Another thing is handling data securely. You can include encryption and secure the communication between them. Encryption is done. Then you can handle errors somehow. You can handle errors and log them to see which errors have occurred, how you can improve them, and how you can work on that. Another thing would be, obviously, writing abstract and modular code so that readability is good. Readability is good, all those things. Documentation and comments are one of the other factors you want in your system. And testing, obviously, when you are building something, you can write some comprehensive tests to ensure the correctness and reliability of your code.

So what is happening here is that the state is only set once in the constructor when the component is first instantiated. The component may not render the expected results when the item prop is changing because the state is not updated automatically when the item prop changes. The state should be updated to reflect the changes in the item prop. This can be achieved by using the `componentDidUpdate` lifecycle method to update the state when the item prop changes. So the state should be initialized in the constructor and updated in the `componentDidUpdate` method to reflect the changes in the item prop. Here is the corrected transcript text: Okay. So what's happening is that the component may not render the expected results when the item prop is changing because the state is only set once in this constructor when the component is first instantiated. So if the item prop changes later, then the state will not automatically update to reflect these changes, which is leading to the component not rendering the new items. That's why the issue is the initialization of the construction and the state does not update with prop changes. So, like, you can update the state to have a better solution.

While reviewing this GraphQL query, I can spot some potential issues that could lead to unexpected results. So, what I want to do here is, I want to identify the issues and inputted results. Okay. We are getting a query. We are getting a query that gets items, and it is having ID, price, and an unrated field. This is a simple GraphQL query, but it has some issues and inputted results. Right? So, what is happening? The query is requesting some unrelated fields. Where is the "k" field? Okay. Under the field is outside the query. So, what are the issues here? I can see that this query, whatever we are trying to do, is requesting an unrated field, which is outside the scope of the items query. The "get item" inside or outside "get items" - this will may not exist in the schema, and or might not be related to the items query. Hence, which, like which is leading to the unexpected results or even errors. Okay. So, if you want to fix this, like, either we could remove this unrated field or if it is not needed. Else, we should ensure that it is a valid field, and it is in the schema. And so it can be correctly queried.

What techniques in TypeScript ensure the prompt engineering code remains scalable as new functionalities are added? So, what techniques in terms of timeframe ensure that? So, what it is, it shows. Fine. So, a few things which I can think of are, like, one is modular design. You break your code into some self-contained modules where each module handles each separate functionality. It's easier to maintain and extend even extend the code. Other techniques could be using interfaces and types to have a better extension and implement type safety. Plus, you can use dependency injection to manage dependencies and make it easier to extend the code. You can also go for factory patterns to create objects and manage creation logic, making it easier to extend or modify the code. Another way could be an event-driven architecture to decouple components and handle complex workflows. Asynchronous programming is also a good approach, using async/await or promises to handle asynchronous operations. A good testing strategy is also essential, writing unit test cases, integration test cases, and ensuring the robustness of your code. You should also document and comment your code, maintain each version, and use a version control system.

What strategy would you use with TypeScript decorators to add metadata functionality in langchain.js applications? Okay. What strategy would you use with TypeScript Acuritas to add metadata? Right? Okay. What I would do here is, so I only need to focus on the main idea. That's a simple thing, and we can move with that. What we can do is, there are a few things I can think of. We can enable experimental decorators and metadata. That could be one thing. You can define method decorators for metadata also. We can apply decorators to classes and methods that so all these things are related to decorators, then we can ensure that this that we do. We can import the Reflect API and ensure that it's imported at the entry point of the application. That could be one thing. Another thing could be that we're working with metadata. We have done things in experimental decorators and in Reflect. We have defined things for metadata. We have applied them here. What it will do is all these things will benefit. So encapsulation, you're encapsulating the metadata handling and keeping your classes and methods clean. You're given flexibility, reusability, and also readability. An example use case could be like prompt metadata. For example, you can annotate the prompts with some descriptions, versions, and other relevant metadata to manage and track them efficiently. So, yeah, that's one strategy.

How can TypeScript enums optimize prompt engineering for language models in terms of mandible and error reduction? Maintainability. How can TypeScript enums count, guys? So, optimize prompt engineering for language models in terms of. Okay. So, like, TypeScript enums can play a significant role in optimizing the prompt in terms of language models by providing a structure and typesafe way to handle predefined sets of content, such as prompt types, categories, even response options and all those things. So what you're improving, you're trying to improve maintainability and reduce errors. Okay. So what it does, you provide type safety that provides compile-time checking, which reduces the likelihood of errors caused by type typos or even invalid values. What else could you do? You're enhancing the readability, simplifying, and improving maintainability. Some use cases could be defining prompt types, like informational, instruction, or warning. You can categorize the prompts based on usage context, like error handling, feedback, and all those things. Or you're managing different response options for prompts, handling response options also. Yeah.