Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 3

Advanced Prompt Engineering for Financial Data.

Recommended resources

Introduction

In our last lesson, you built a simple agent that could use a custom Python function—a tool—to perform a precise calculation. You mastered the fundamental five-step process of function calling, which connects the agent's "brain" (the LLM) to its "hands" (the tools).

However, for that to work, we manually provided the tool with clean, structured inputs like revenue=2500000. In the real world of project finance, critical data is rarely so neat. It's often buried in unstructured text within deal memos, legal agreements, or news articles.

This lesson directly addresses the learning outcome: Implement advanced prompt engineering techniques for financial data extraction and analysis. We will move beyond basic questions and learn how to design sophisticated prompts that can:

  1. Extract structured data (like JSON) from unstructured financial text.
  2. Guide the LLM to perform structured, expert-level financial analysis.

Mastering these techniques is the bridge between having an agent that can use tools and having an agent that can autonomously find the information it needs to use those tools effectively.

The Challenge: Why Standard Prompts Fail with Financial Data

Financial documents are not like prose. They have implicit structures, hierarchies, and conventions that generic LLMs often misunderstand. A simple prompt like "Summarize this table" can lead to critical errors.

The article "How to Process LLM Tabular Financial Data" explains these challenges well. LLMs can struggle with:

  • Horizontal relationships: Understanding year-over-year trends in a table.
  • Vertical dependencies: Recognizing that Gross Profit is derived from Revenue.
  • Numerical notation: Confusing $45.2M with 45.2 or misinterpreting figures reported "in thousands."

To overcome this, we need to be more explicit in how we ask the LLM to process information. This requires moving from simple prompts to prompt engineering.

Part 1: Forcing Structured Output for Reliable Extraction

Our first goal is to ensure that when we ask an LLM to extract information, it returns it in a predictable, machine-readable format like JSON. This is non-negotiable for building robust agentic systems, as the output of an extraction step often becomes the input for a tool-using step.

A powerful technique for this is to define an output schema. Instead of just describing what you want in text, you provide a formal structure for the data you expect back.

The video below provides an expert-level, practical guide to this using a library called Kor. While the library helps, the underlying principles of schema definition, providing examples, and handling complex data types are universal and crucial for your toolkit.

Use LLMs To Extract Data From Text (Expert Mode)

The video 'Use LLMs To Extract Data From Text (Expert Mode)' by Greg Kamradt is an excellent tutorial on forcing structured data extraction. It demonstrates how to define schemas to get reliable JSON output from an LLM, a core skill for any agent developer.

Watch the following segments, focusing on the concepts rather than the specific library syntax: Introduction & Simple Schema (00:25 - 03:42): Understand how a schema is defined with descriptions and examples to guide the LLM in extracting a single piece of information. Multiple & Nested Fields (03:42 - 05:57): See how this extends to more complex, nested data structures, which is common in financial documents. Real-World Application (07:53 - 13:21): Pay close attention to how he applies this to extract a list of technologies from a job description and, more relevantly, a numerical salary range. This demonstrates the power of the technique on messy, real-world text. You can skim the cost section at the end, but the application examples are key.

The key takeaways from the video are:

  • Schema Definition: You define the "shape" of the data you want (e.g., fields, data types).
  • Descriptions are Prompts: The descriptions you provide for each field act as targeted prompts, telling the LLM precisely what to look for.
  • Examples are Powerful (Few-Shot Prompting): Providing examples within the schema, as shown in the video, is a form of few-shot prompting. It dramatically improves accuracy by showing the model exactly how to handle the source text.
Test your understanding!

Imagine you have a text summary of a Power Purchase Agreement (PPA) for a solar project. You want an agent to extract key commercial terms.

Task: Based on the principles from the video, outline a schema to extract the following information:

  • The offtaker (the entity buying the power).
  • The contract tenor (in years).
  • The tariff rate (price per kWh).
  • Whether the tariff has a fixed or escalating structure.

Describe the fields, their data types, and what kind of description you would provide for each to guide the LLM. You don't need to write code, just describe the schema's structure and logic.

Show answer

A good schema design would look something like this:

  • Object ID: ppa_terms
  • Description: "Key commercial terms extracted from a Power Purchase Agreement."
  • Attributes/Fields:
    1. offtaker
      • Type: string
      • Description: "The name of the company or utility that is purchasing the electricity."
    2. tenor_years
      • Type: integer
      • Description: "The duration of the contract in years."
    3. tariff_rate_usd_per_kwh
      • Type: number (float)
      • Description: "The price paid for electricity in USD per kilowatt-hour. Extract only the numerical value."
    4. tariff_structure
      • Type: string (enum: "fixed", "escalating")
      • Description: "The structure of the tariff. Identify if it is a 'fixed' rate for the entire tenor or an 'escalating' rate that increases over time."

Providing few-shot examples would make this even more robust. For instance, you could give it a sample text like "The 20-year PPA with Kenya Power and Lighting Company features a flat tariff of $0.12/kWh" and show the expected JSON output.

Part 2: Engineering Prompts for Expert-Level Analysis

Extracting data is only half the battle. Your goal is to build agents that can reason about that data like a financial analyst. To do this, we need to guide the LLM's thought process. This is where Chain-of-Thought (CoT) prompting comes in.

Instead of just asking for an answer, you instruct the model to "think step-by-step." This simple change forces the model to externalize its reasoning process, which often leads to more accurate and logical results.

A recent paper introduces an advanced, finance-specific version of this called FinCoT (Financial Chain-of-Thought). This is a state-of-the-art technique that perfectly aligns with your goal of building expert-level agents.

Grounding Chain-of-Thought in Expert Financial Reasoning

The paper 'Grounding Chain-of-Thought in Expert Financial Reasoning' presents a framework called FinCoT. It's a prime example of advanced prompt engineering tailored to a specific, complex domain like finance. We will focus on the practical structure of the prompt itself.

Your goal is to understand the FinCoT prompt structure, not to digest the entire academic paper. Read Section 2.1 and look at Figure 1: This provides a taxonomy of prompting. Understand the difference between Standard Prompting (SP), Unstructured CoT (UST-CoT), and Structured CoT (ST-CoT). FinCoT is a type of ST-CoT. Read Section 3.1 and look at Figure 2: This is the core of the framework. Understand the key components: the system message, the guided step-by-step execution using <thinking> and <output> tags, and the embedded 'Expert Reasoning Blueprint'. Skim Appendix A (Section 10): Look at the 'Expert Reasoning Blueprints' for a few domains like 'Equity Investments' or 'Portfolio Management'. Notice how they are text-based flowcharts (using Mermaid syntax) that outline an expert's workflow. This is the 'Hint' that gets embedded in the prompt. Examine Appendix B.2 (Section 12): This shows the final FinCoT prompt template. See how the Hint (the expert blueprint) is injected and how the model is instructed to use the <thinking> and <output> tags.

The FinCoT approach is powerful because it combines several advanced techniques into one prompt:

  • Role-Playing: You are a CFA...
  • Structured Reasoning: It forces the model to separate its reasoning (<thinking>) from its final answer (<output>). This is a step up from basic CoT.
  • Domain-Specific Guidance: It injects a "cheat sheet" (the expert blueprint) directly into the prompt, guiding the LLM to follow a workflow that a human expert would.

This is exactly how you can start to codify the investment and risk analysis logic for your project finance agents.

Advanced Prompt Engineering Concepts and Applications
This diagram illustrates several advanced prompt engineering concepts. On the right, the multi-step reasoning process—iteratively querying, accumulating information, and synthesizing an answer—is conceptually similar to the step-by-step logic enforced by a Chain-of-Thought framework like FinCoT.

Part 3: A Blueprint for Your Financial Analysis Prompts

Now, let's synthesize everything we've covered into a practical blueprint for creating advanced prompts for your project finance agents. A high-quality prompt for financial data extraction and analysis should combine multiple elements.

Let's refer back to the Daloopa article, which provides excellent, concrete examples for financial data.

How to Process LLM Tabular Financial Data

The Daloopa article, 'How to Process LLM Tabular Financial Data,' offers practical prompt components that complement the FinCoT framework.

Please read the section 'LLM Serialization and Prompt Engineering for Financial Tables'. Focus on the two subsections: 'The Power of Financial Few-Shot Learning' and 'Context Injection for Domain Expertise'. Note how they construct the prompts.

Combining these ideas, here is your Advanced Financial Prompt Blueprint:

  1. Role & Goal Definition (System Prompt): Start by telling the agent who it is and what its overall goal is.

    • Example: "You are a senior investment analyst specializing in renewable energy project finance. Your task is to analyze the provided document and extract key financial metrics and risks."

  2. Context Injection: Provide essential background information about the subject.

    • Example: "The project is a 50MW C&I solar installation in Lagos, Nigeria. The company is ProjectCo. The analysis should be based on IFRS standards. The fiscal year ends Dec 31."

  3. Expert Blueprint / Workflow (The FinCoT "Hint"): Give the agent a high-level, step-by-step plan. You can write this out as a numbered list or even use the Mermaid syntax from the FinCoT paper.

    • Example: "Hint: 1. Identify project revenue sources. 2. Identify key operating expenses. 3. Calculate Net Operating Income. 4. Identify debt service obligations. 5. Calculate the DSCR. 6. Identify and list key operational risks."

  4. Few-Shot Examples: Provide one or two clear examples of the task.

    • Example (for ratio calculation): "Example: Given Revenue: $10M, Opex: $4M, Debt Service: $5M. Calculation: NOI = 10 - 4 = $6M. DSCR = 6 / 5 = 1.2x."

  5. Structured Reasoning & Output Format: Instruct the model to use a structured reasoning process and specify the exact output format.

    • Example: "Think step-by-step within <thinking> tags. Provide your final answer as a single JSON object within <output> tags. The JSON must have the keys: projectName, dscr, and risks (a list of strings)."

By combining these five elements, you create a highly constrained, guided, and reliable prompt that moves far beyond simple question-answering and into the realm of automated, expert-level analysis.

Conclusion

In this lesson, you've added two powerful capabilities to your agent-building arsenal. You've moved from simply using tools to strategically sourcing information for and reasoning with them.

Key Takeaways:

  • Extraction requires structure: To reliably extract data from text for your agent's tools, you must prompt the LLM to return a structured format like JSON by defining an output schema.
  • Analysis requires reasoning: To make an LLM analyze financial data like an expert, use Chain-of-Thought (CoT) prompting. Advanced methods like FinCoT enhance this by adding structural tags (<thinking>) and injecting expert workflows directly into the prompt.
  • A great prompt is a composite: The most effective prompts are engineered by combining multiple techniques: role-playing, context injection, few-shot examples, expert blueprints, and strict output formatting.

You now have a deep understanding of how to craft the "mind" of your agent. In our next lesson, "Design and implement an agent workflow using the ReAct (Reason-Act) framework," we will take the structured reasoning you learned about today and combine it with the tool use from the previous lesson. You will build an agent that can dynamically decide when to think and when to act, forming the core loop of a truly autonomous system.