Vaibhav Gupta’s Post

Creating the reliable outputs with pre-defined structured Schema is very critical in developing GenAI applications. It is good to see more ideas apart from using Structured Tools to achieve this.

Reliable outputs 100%, new with *Programmatic Chain of Thought* Literally, just 2 lines of code with perfectly structured output: llm = Lamini(model_name="meta-llama/Meta-Llama-3-8B-Instruct") output = llm.generate(       "Rate the answer using a score from 1 (lowest match) to 5 (highest match).",       output_type={"explanation": "str", "score": "int"} ) """ {  "explanation": "The answer is not a direct match…", "score": 3 } """ Docs 👉 https://lnkd.in/gPXUcHxA Get started for free now (40M tokens free!) 👉 https://app.lamini.ai/ Technical walkthrough of how we implemented it 👉https://lnkd.in/gZKjNDKg

A few advice on how to improve the quality of LLM generated code in code manipulation tasks: 1. Provide numbered code snippets for line references; 2. Iteratively ask the LLM to review and improve its output before using the generated code; 3. Avoid JSON for code output; use plain text with custom delimiters; 4. Give LLMs space to reason before making decisions And Be cautious with patch file generation; LLMs struggle with this. More details in my article on medium: https://lnkd.in/d59vkCNC

📝 Proposition-Based Retrieval A key design choice in building RAG is the “retrieval unit”: sentence, paragraph, etc. A new paper (“Dense X Retrieval” by Chen et al). introduces a new retrieval unit - a proposition. By indexing a proposition and retrieving the raw text, you improve retrieval performance and get better QA performance with LLMs. We’ve implemented this in LlamaIndex 💫 (shoutout Logan Markewich). It was straightforward with our recursive retriever abstractions, and we’ve advocated for similar high-level ideas: decoupling the chunk used for retrieval vs. synthesis!  1️⃣ Extract propositions from each node using LLM  2️⃣ Index propositions, link to underlying text using recursive retriever 3️⃣ Ask question, get answer! It’s a full LlamaPack 📦, meaning you can start using it directly or inspect it as a template 💪. LlamaPack: https://lnkd.in/d8KShE2m Original paper: https://lnkd.in/dxtgnMPU

super interesting reminds me of a challenge a client faced a few years ago. They were developing a system where users could search through a vast collection of videos. These videos had been analyzed using Microsoft's Video Indexer (https://vi.microsoft.com/), featuring transcripts that were aware of who was speaking and when. This allowed users to jump directly to the specific moment in the video where certain text was mentioned. However, the project hit a snag regarding usability. The issue was extracting complete, coherent thoughts from these searches. For example, if a user searched for the term "RAG" across all videos, they could easily find every instance of the word. But this wasn't enough. The goal was to provide users with clips where "RAG" was mentioned within its full context. Ideally, if "RAG" appeared in the middle of a discussion or a proposition, the system would return the entire segment of that discussion or proposition, starting from the beginning. Seems that this approach would have gone a long way towards solving that issue. I figure, at first blush, that this would be powerful if implemented as an agent that runs in a "group chat" a'la Autogen. Keep up the good work Logan Markewich at LlamaIndex!

Structuring LLM outputs is not new, but how do you efficiently structured outputs from a RAG pipeline? 🧱 Thanks to Brandon Max + Logan Markewich, you can now get native Pydantic object outputs from all our query engines, without an extra LLM output parsing call! More Context: The core of any RAG system is a response synthesis system that can synthesize over arbitrary context (create/refine, tree summarize). If the context fits in a single LLM call, structuring outputs is easy. Simply use our output parsing modules to parse structured outputs (either text completion of function calling). But if you want a response synthesis strategy over lots of context, intermediate responses are passed around. We refactored a bunch of abstractions to serialize/deserialize structured, intermediate responses while ensuring that the output is still structured. Full Guide here: https://lnkd.in/gYbaygzS

topics which prepare for exam step 10 : 0. json objects , syntax error , typing error , assignability error. 1. strong typing. 2. let , const.  3. modules with ecma script , inquirer , chalk  4. unions literals 5. objects , type alised , structural typing obj literals , nasted obj , type intersection , any unknown never. 6. explict casting. 7. enum , const enum. 8. arrays. 9. functions , parameters : default, optional, rest. , async functions , anonymous functions , lambda functions function overloads.  10. tuples

Today revisited another leetcode problem 424. Longest Repeating Character Replacement. Question: We are given a string s and an integer k. String s contains uppercase English characters. We are allowed to change any character from s to any other English character. We can perform this operation at most k times. We have to return the length of the longest substring which contains the same English characters after performing the k operation. Approach: We will use sliding window and hash map to solve this problem. Sliding window to keep track of length of longest substring which will contains the same English characters. Let's see how We will start our window from the first character and count the number of times a character appears in the hashmap. And we will keep increasing the window. Why we are counting the characters in the hashmap? As we know we can perform at most k operations so we will use this count to make sure we are not crossing the k limit. We will check if window size minus max count of a character in hashmap is greater than k then we will decrease the window. Because it means we are crossing the k operations limit. For example, if there is window AABA of size 4 and k is 2. In this window count of A is 3 and B is 1 so max is 3. So as per above statement 4 - 3 = 1 which is less than k so we will not decrease the window as in the window if we change B to A then we will left with one operation which is ok. Let's see this case if the window is AABABB of size 6 and 6 - 3 = 3 which is greater than k so, in this case, we will decrease the window from left and also decrease the count from the hash map for that character. As we will move on we will update our result. https://lnkd.in/dAhQDMiC

I recently encountered a problem on LeetCode that required determining the number of additional characters needed in a given string to make it perfect. In this case, a string was considered perfect if it contained an "abc" sequence any number of times. The string could have a maximum length of 50 characters and would only consist of the characters 'a', 'b', and 'c'. To approach this problem, I decided to create a 2D array of size 50x3, as the maximum string length could be 50, and there were only 3 characters to consider for continuity within a perfect substring. I also implemented a pointer that would track the current column in the array where I wanted to enter a value. Initially, this pointer was set to 0. Here's how the solution works: 1. When encountering the character 'a', I set the value in the current column of the array (array[pointer][0]) to 1. For 'b', I set array[pointer][1] to 1, and for 'c', I set array[pointer][2] to 1. 2. If I encountered a character smaller than the last one, I increased the pointer value. This ensured that each perfect substring was maintained. 3. To find the answer, which initially starts at 0, I began counting the number of 0s in each column up to and including the column indicated by the current pointer value in the array. For each column where I found a value that was not equal to 1, I increased the answer by 1. In the end, this approach allowed me to determine the number of additional characters needed to make the string perfect. Problem no 2645, its not optimized solution but its was interesting for me.

If the compiler is indicating an error on line 107, there might be an issue with your code structure or syntax near that line. Double-check the code around line 107 for any missing parentheses, semicolons, or other syntax errors. If you can provide the code snippet around that line, I might be able to help you identify the problem.