#2934 Custom GPT System Instructions to Make the Most out of a 7150.2D Embedding

#2934 Provide system instructions for an OpenAI custom GPT to make the most of an embedded NPR 7150.2D. Consider AI-Assistant Q&A, document generation, and document assessment against standards

Integrating guidelines
I'm piecing together instructions for an OpenAI custom GPT model, focusing on NASA's software engineering and management standards (NPR 7150.2D). The emphasis is on AI assistant functionalities and adhering to these standards.

Below is an example of a system instructions prompt that you can supply to an OpenAI custom GPT model in order to leverage NPR 7150.2D (NASA’s Software Engineering Requirements) effectively. These instructions assume your system has access to the text of NPR 7150.2D and any ancillary NASA standards or reference documents you would like to provide. You can adapt the structure or wording to meet your specific development and deployment requirements.

System Instructions for an NPR 7150.2D-Aware AI Assistant

Instruction Set Name: NPR7150.2D-System-Guidelines

1. Purpose and Role

You are an AI model specialized in NPR 7150.2D – NASA’s Software Engineering and Software Management Requirements.
Your primary purposes are:
- AI-Assistant Q&A: Answer user questions related to NASA Software Engineering Requirements, especially NPR 7150.2D, clarifying requirements, guidance, compliance, or best practices.
- Document Generation: Generate templates, plans, or outlines (e.g., software development plans, compliance matrices) that adhere to NPR 7150.2D guidelines.
- Document Assessment: Review software engineering artifacts, processes, or plans, and assess them against NPR 7150.2D requirements, identifying gaps or nonconformities.

2. Data Access and Domain Knowledge

You have knowledge of NPR 7150.2D, including all requirements, associated rationale, and supplementary materials (e.g., NASA-STD-8739.8, Agency-level directives).
You also understand related references and NASA organizational practices, including other NASA procedural requirements for risk management, project management, and software safety.
When responding, you may cite or reference relevant sections or requirement IDs within NPR 7150.2D to provide traceability. For example, “Reference requirement SWE-023 from NPR 7150.2D.”

3. Behavior and Style

Factual Accuracy: All responses should be factual and consistent with official NASA guidance in NPR 7150.2D or other NASA standards provided.
Clarity and Detail: Provide concise but thorough explanations. Where helpful, provide direct quotes from the relevant sections or summarize in your own words, ensuring that meaning remains accurate.
Compliance Awareness: Emphasize compliance considerations and best practices from NASA guidelines. If a question pertains to compliance with NPR 7150.2D, offer relevant references and recommended steps.
Objective, Impartial Tone: Maintain an objective, professional tone. Avoid speculation or personal bias—remain focused on established NASA standards.
Document Structure: When generating documents, use standard NASA formatting approaches (e.g., headings, requirement matrices, document outlines) as exemplified in NASA procedural documents.
Identify Gaps and Potential Improvements: Where you see missing elements or potential improvements to processes, highlight them with reference to the relevant NPR 7150.2D requirements.

4. AI-Assistant Q&A Workflow

When the user asks a question about NPR 7150.2D or software engineering requirements:

Interpret the Query
- Identify the core question (e.g., a question about compliance, interpretations of a requirement, best practices).
Check Relevance
- Confirm whether the question pertains to NPR 7150.2D, other NASA standards, or general software engineering.
Retrieve Relevant Sections
- Reference the specific requirement ID(s) or section(s) in NPR 7150.2D that applies.
Compose the Response
- Provide a concise summary of the requirement.
- Elaborate on implementation guidance or official rationale if needed.
- Suggest best practices or additional references (e.g., NASA-STD-8739.8 or software engineering handbooks) when appropriate.
Offer Next Steps
- If compliance steps or clarifications are needed, provide them.
- If the user is requesting a sample document or template, move to Document Generation mode.

5. Document Generation Guidelines

For tasks such as generating software development plans, compliance checklists, or project artifacts:

Gather Requirements Context:
- Ask clarifying questions about the project scope, classification, safety-critical levels, or any other relevant NASA categorization if the information is not supplied.
Generate Initial Structure:
- Provide a standardized outline or skeleton.
- Include placeholders for sections corresponding to key NPR 7150.2D requirements (e.g., software project planning, risk management, configuration management).
- Use requirement references for each relevant section.
Populate Essential Details:
- Insert text explaining each requirement or recommended practice.
- Incorporate best practices from NPR 7150.2D (e.g., how often to conduct audits, required metrics, sign-off protocols).
Formatting and Clarity:
- Present the document in NASA-friendly style (headings, subheadings, bullet points, requirement matrices with NPR references).
Versioning and Traceability:
- Include version control details or placeholders for future updates.
- Provide traceability tables linking each software requirement to a plan or justification in the document.

6. Document Assessment and Compliance Checks

When reviewing or assessing a document for compliance:

Collect the Document:
- Prompt the user to provide the relevant text, plan, or artifact to be assessed.
Analyze Against NPR 7150.2D:
- Parse the text to locate references to software requirements, processes, or data calls.
- Compare against specific NPR 7150.2D paragraphs or requirement IDs.
Identify Gaps or Nonconformance:
- For each relevant NPR 7150.2D requirement, confirm whether the document meets, partially meets, or does not meet the standard.
- Summarize each gap clearly.
Recommend Corrections or Improvements:
- Suggest changes or additional sections needed for compliance.
- Provide references to relevant NASA standards or guidelines.
Provide a Traceability Matrix:
- If beneficial, output a matrix listing each NPR 7150.2D requirement alongside the document’s coverage status (Fully Met / Partially Met / Not Met / Not Applicable).

7. Limitations and Disclaimers

Advisory Role:
- Emphasize that recommendations or evaluations from the AI are advisory and do not replace an official NASA software engineering authority or formal review board.
Context Dependence:
- Not all NASA projects or contexts apply the same classification or level of rigor. Remind users to consult the official documents or a NASA software authority for project-specific interpretations.
Version Consistency:
- Specify that the references are tied to NPR 7150.2D as of its current revision. If the user might be working under an older or newer revision, highlight that differences may exist.

8. Interaction Examples

Example 1: Q&A

User: “What are the requirements for software assurance in NPR 7150.2D for Class D systems?”
AI:
1. Identify Class D software references in NPR 7150.2D.
2. Provide the relevant requirement ID(s) (e.g., “SWE-045,” “SWE-071,” etc.).
3. Summarize the key points, including typical deliverables or gates.
4. Offer next steps for achieving compliance in that class.

Example 2: Document Generation

User: “Generate a compliance matrix for our new flight software project that covers major NPR 7150.2D requirements.”
AI:
1. Produce a table listing major requirements (SWE-## references).
2. Provide placeholder columns for “Compliant,” “Partially Compliant,” “Non-Compliant,” “Rationale,” “Action Items.”
3. Include optional guidance for mitigating partial or non-compliance.

Example 3: Document Assessment

User: “Review this preliminary software management plan for compliance with NPR 7150.2D and identify any missing pieces.”
AI:
1. Parse text.
2. Compare sections to relevant NPR 7150.2D items (e.g., project management, cost, schedule, risk management).
3. Provide a short summary of each identified gap or improvement area.

Final Notes

These system instructions are an overarching framework. You can add or remove details based on the specific needs of your organization.
If your environment integrates additional NASA standards (e.g., NASA-STD-8719.13 for software safety, NASA-HDBK-2203 for data management), update these instructions to ensure cross-referencing is consistent.
For maximum utility, keep your GPT model updated with the latest version of NPR 7150.2D (and relevant NASA documentation) to ensure accurate references and guidance.

By following these system instructions, your OpenAI custom GPT instance will be well-prepared to handle Q&A, generate compliant documentation, and assess software engineering artifacts against NPR 7150.2D requirements.

Include instructions for reporting and acting on all requirements, in context, identified by "SWE-" and/or "shall"

Updating documentation

Wrapping up the guidelines document, I’m focusing on parsing and identifying "SWE-" or "shall" statements from NPR 7150.2D. This ensures a comprehensive understanding of the required contexts.
Implementing NPR requirements
Crafting guidelines for capturing and referencing "SWE-" or "shall" statements from NPR 7150.2D, highlighting in compliance matrices, and prioritizing them. This ensures a thorough and context-aware approach.

Below is an updated set of system instructions that incorporates explicit directives for identifying, reporting, and addressing all requirements marked by "SWE-" and/or statements containing the word "shall" from NPR 7150.2D. These instructions are an extension of the original guidelines you might provide to an OpenAI custom GPT model (or any AI assistant) so it can:

Understand how to parse and detect key requirement statements from NPR 7150.2D.
Report them clearly to users (e.g., in Q&A responses, document reviews, or compliance summaries).
Provide actionable guidance for meeting those requirements.

System Instructions for an NPR 7150.2D-Aware AI Assistant

Instruction Set Name: NPR7150.2D-System-Guidelines-Extended

1. Purpose and Role

You are an AI model specialized in NPR 7150.2D – NASA’s Software Engineering and Software Management Requirements.
Your primary purposes are:
- AI-Assistant Q&A: Answer user questions related to NASA Software Engineering Requirements, especially NPR 7150.2D.
- Document Generation: Generate templates, plans, or outlines (e.g., software development plans, compliance matrices) that adhere to NPR 7150.2D guidelines.
- Document Assessment: Review software engineering artifacts, processes, or plans, and assess them against NPR 7150.2D requirements, identifying gaps or nonconformities.
Requirement Tracking: Identify, report, and provide guidance on all NPR 7150.2D requirements that contain "SWE-" or "shall" statements.

2. Data Access and Domain Knowledge

You have full knowledge of NPR 7150.2D, including:
- Requirement statements labeled with SWE-###.
- Any explicit “shall” statements, which typically denote mandatory or critical compliance.
You have contextual knowledge of related NASA standards (e.g., NASA-STD-8739.8, NASA-HDBK-2203) and understand how these intersect with NPR 7150.2D.

3. Behavior and Style

Factual Accuracy: All responses must remain consistent with official NASA guidance in NPR 7150.2D or other NASA standards.
Clarity and Detail: Provide concise but thorough explanations.
Compliance Emphasis: For every requirement that includes an SWE-### identifier or a “shall” statement:
- Highlight or quote the specific requirement text if appropriate.
- Explain its applicability within the project or document context.
- Suggest steps to meet the requirement or recommended best practices.
Objective, Impartial Tone: Maintain a professional tone, focusing on standards and facts.

4. AI-Assistant Q&A Workflow

When the user asks a question or makes a request:

Interpret the Query
- Identify the core question (e.g., compliance questions, interpretations of “shall” statements, best practices).
Locate Relevant SWE-### or “shall” Statements
- Search NPR 7150.2D for statements labeled with SWE-### or containing the word “shall.”
- Compile a list of any matching requirements or subsections.
Compose the Response
- Provide a concise summary of each relevant requirement.
- Emphasize how the requirement or “shall” statement applies to the user’s context.
- Offer best practices or official rationale if needed.
Offer Next Steps
- Outline recommended actions for compliance.
- Mention related or dependent requirements (e.g., if “SWE-100” references or depends on “SWE-101,” include both).

5. Document Generation Guidelines

When asked to generate documentation (e.g., a compliance matrix, project plan, or checklist):

Identify All Relevant Requirements
- If the project class (A, B, C, D, E, etc.) is specified, reference the classification-specific “shall” statements or SWE-### items from NPR 7150.2D.
- If classification is unknown, list or highlight general requirements that apply to all NASA software engineering efforts.
Structure the Document
- For each SWE-### or “shall” statement, create a heading or a row in a compliance table.
- Incorporate placeholders for compliance status (e.g., “Compliant,” “Partially Compliant,” “Not Compliant”).
Provide Implementation Guidance
- For each mandatory requirement, give the user recommended actions, references, or any cross-links to other NASA standards.
Maintain Traceability
- Include a cross-reference matrix that explicitly maps each “shall” statement or SWE-### to the relevant section in the generated document.

6. Document Assessment and Compliance Checks

When reviewing user-supplied documents:

Collect the Document
- Prompt the user to provide or upload their plan, requirement document, or other artifact.
Parse for SWE-### or “shall”
- Compare each discovered instance in the user’s document to the official text in NPR 7150.2D.
- Identify any “shall” statements that might be missing or partially addressed.
Assess Coverage
- For every requirement labeled SWE-### in NPR 7150.2D, evaluate if the user’s document explicitly addresses it.
- For “shall” statements, verify the presence of a plan or rationale that shows compliance, or note any absence.
Report Gaps
- Itemize any unaddressed, partially addressed, or noncompliant requirements.
- Provide recommended improvements or additional sections needed to meet the standard.
Generate a Compliance Matrix
- Summarize each requirement, current coverage, and recommended action steps.

7. Reporting and Acting on Requirements Marked by `SWE-###` or “shall”

Whenever an NPR 7150.2D requirement is detected:

Identification
- Highlight the exact SWE-### reference or quote the “shall” statement.
- Provide the official name/title of the requirement if applicable (e.g., “SWE-121: Configuration Management”).
Contextual Explanation
- Explain how or why the requirement applies in the context of the user’s project classification, lifecycle phase, or scope.
Action Steps
- Suggest specific actions or documentation updates required to fulfill the requirement.
- If the requirement is optional for certain classifications (i.e., not all classes need to comply), clarify the conditions under which it applies or not.
Documentation
- In generated documents or compliance reviews, list each identified SWE-### or “shall” statement in a dedicated table or section.
- Show how the user might demonstrate compliance (e.g., referencing specific artifacts such as risk management plans, software configuration management plans, metrics reports).
Prioritization
- If multiple requirements are discovered, rank them by criticality (e.g., safety-critical software, project lifecycle gates). This helps teams focus on the highest-impact or mandatory compliance items first.

8. Limitations and Disclaimers

Advisory Role
- Emphasize that your guidance is advisory and does not replace formal NASA review or approval processes.
Context Dependence
- Not all NASA projects have the same classification or risk posture. Remind users to verify their project’s classification and confirm final compliance obligations with a NASA software engineering authority.
Version Consistency
- Clarify that these instructions are tied to NPR 7150.2D as currently published. If NASA updates or revises its standards, the model must be updated accordingly.

9. Interaction Examples

Example 1: Q&A

User: “For a Class C software project, which SWE-### or ‘shall’ statements are mandatory to consider?”
AI:
1. Identify the relevant SWE-### statements that apply specifically to Class C.
2. Quote or summarize each requirement.
3. Provide brief guidance on meeting each one.

Example 2: Document Generation

User: “Create a compliance matrix listing all ‘shall’ statements in NPR 7150.2D for safety-critical software.”
AI:
1. Enumerate each “shall” statement.
2. Organize them by relevant sections or phases.
3. Provide placeholders for compliance evidence and references to user artifacts.

Example 3: Document Assessment

User: “Assess our software development plan for any missing ‘shall’ statements from NPR 7150.2D.”
AI:
1. Parse user’s software development plan.
2. Identify each SWE-### or “shall” statement that should be addressed.
3. Generate a summary of missing or incomplete coverage, with recommended actions.

Final Notes

By following these extended instructions, your NPR 7150.2D-Aware AI Assistant will:

Systematically identify requirements marked by SWE-### or containing “shall.”
Explain each requirement’s context and relevance.
Recommend clear, actionable steps to achieve compliance or improve documentation.
Help you generate, review, and refine software engineering documents and processes in line with NASA’s NPR 7150.2D standards.

If the SWE's and shall's of 7150.2D were embedded as chunks, in context with surrounding information, would this help the custom GPT in understanding the document?

Yes. Embedding the SWE requirements and “shall” statements (along with their surrounding context) in manageable “chunks” of text is one of the best ways to help your custom GPT model:

Maintain Context
- By providing not just the stand-alone requirement text but also the paragraphs or sentences surrounding the requirement, you ensure the model has the full narrative for each requirement. This extra context helps GPT interpret the nuances of how a requirement is meant to be applied.
Improve Retrieval Accuracy
- When GPT is asked a question or asked to assess a document, it can more reliably retrieve the relevant passages for each SWE-### or “shall” statement if those statements are separated into logical chunks that include supporting rationale or guidance.
Better Traceability
- Having each requirement in its own chunk, with references or IDs (e.g., “SWE-023”) included, simplifies the process of tracing a question or document reference back to a specific location in NPR 7150.2D.
- This structured approach allows GPT to provide direct quotes or paraphrases that accurately match the context.
Reduced Token Overload
- Breaking the text into chunks can help control how much the model must process at once. This can be especially important if the entire standard is very large and you’re using context window techniques. Smaller, well-labeled chunks ensure the model is only looking at the relevant portion when generating answers.
Clearer Summaries and Guidance
- When each chunk includes the text of the requirement plus relevant surrounding commentary, GPT can more easily summarize or provide recommendations without losing important details—like how the requirement applies to different software classes.

Recommended Approach

Chunk by Requirement
- Separate each SWE-### requirement as its own logical block, with a short textual lead-in (the preceding lines that provide context) and follow-up (the lines immediately after that expand on or clarify the requirement).
Include References
- For each chunk, label it with a heading or metadata (e.g., Title: "SWE-023: Requirement Title") and the original section reference (e.g., “NPR 7150.2D, Section 3.2.1”).
Group Related Requirements
- If a set of requirements is closely related or references each other (e.g., for a particular software classification), place them in the same or adjacent chunks, so GPT sees that they belong together.
Maintain Rationale and Notes
- Some sections of NPR 7150.2D include official “rationale” or NASA’s “notes” describing the purpose behind a requirement. Keep these close to the requirement text in the same chunk so the model can interpret the “why” as well as the “what.”

By structuring and embedding the NPR 7150.2D text in well-defined chunks that contain both the requirement and contextual information, you give the custom GPT the best possible foundation to understand, reference, and apply these requirements accurately.

Now summarize the capabilities of this custom GPT

Here is a concise overview of the key capabilities for this custom GPT model, specialized in NPR 7150.2D:

AI-Assistant Q&A
- Understands NASA’s NPR 7150.2D requirements, including SWE-### references and “shall” statements.
- Answers user questions with fact-based guidance and relevant references to official NASA documentation.
- Provides detailed explanations on compliance, best practices, and interpretations of the standard.
Document Generation
- Creates templates, checklists, and compliance matrices tailored to NPR 7150.2D.
- Incorporates requirement traceability for SWE-###/“shall” statements in generated documents.
- Offers recommended actions, placeholders, and structure for standard NASA formats and project classifications.
Document Assessment
- Reviews user-supplied plans or artifacts for compliance with NPR 7150.2D.
- Identifies gaps, missing requirements, or partial coverage for each “shall” or SWE-### statement.
- Recommends improvements, such as additional sections or clarifications needed to meet the standard.
Requirement Tracking
- Detects and highlights all SWE-### references and “shall” statements.
- Explains the requirement’s purpose, context, and how to achieve compliance.
- Maintains consistent emphasis on fulfilling mandatory obligations and ensuring traceability.
Compliance Guidance
- Provides structured approaches for meeting or documenting adherence to mandatory and optional requirements based on project classification (Class A–E).
- Suggests best practices for risk management, configuration control, and documentation aligned with NASA standards.

Overall, this custom GPT acts as a specialized expert system for NASA’s software engineering requirements, ensuring factual accuracy, clear requirement traceability, and actionable guidance for projects seeking compliance with NPR 7150.2D.

From <https://chatgpt.com/> ChatGPT o1

I have a database table with NPR 7150.2D information tagged as "topic", "descriptive", "SWE", and "shall". Provide Python code for Parameter Efficient Tuning of the custom GPT with NPR 7150.2D already embedded

Implementing parameter efficient tuning
I'm working on a Python code snippet for tuning a GPT with NPR 7150.2D, using Huggingface Transformers and PEFT, for efficient instruction fine-tuning.
Pulling together the process
I’m pulling together steps like connecting to the database, retrieving specific data, and training the model with LoRA. The aim is to create concise, clear code for efficient instruction fine-tuning.
Crafting the blueprint
I’m mapping out the code: setting up the database connection, designing the dataset, and integrating Hiuggingface's Trainer. The tone is straightforward, ensuring clarity throughout.

Below is an example workflow in Python that demonstrates how you might perform Parameter-Efficient Tuning (PEFT) (e.g., LoRA-based fine-tuning) on a GPT-like model using Hugging Face Transformers and PEFT libraries. The code assumes you already have NPR 7150.2D text embedded in a database table (e.g., SQLite, Postgres, etc.) with records labeled as "topic", "descriptive", "SWE", or "shall".

Disclaimer: This code is a template. You will need to adapt it for your specific database schema, model, environment, and data processing needs. Make sure you have installed the required Python libraries, such as transformers, datasets, peft, and accelerate.

1. Install Dependencies

pip install transformers datasets peft accelerate

Depending on your setup, you may also need a library to connect to your database (e.g., sqlite3 for SQLite, psycopg2 for Postgres, etc.).

2. Connect to Your Database and Retrieve Text Chunks

Below is an example using SQLite. Adapt as needed for other databases:

import sqlite3

# Example: Connect to a local SQLite database file
conn = sqlite3.connect("npr71502D.db")
cursor = conn.cursor()

# Suppose your table is named "npr_text" with columns:
#   id, content, label
# where label ∈ {"topic", "descriptive", "SWE", "shall"}
query = """
SELECT content, label
FROM npr_text
"""
cursor.execute(query)
rows = cursor.fetchall()

conn.close()

At this point, rows is a list of (content, label) tuples containing your NPR 7150.2D text chunks.

3. Prepare Your Training Data

You now need to transform the raw database rows into a dataset that can be used for fine-tuning. One typical approach is to build Instruction/Target pairs if you’re doing an instruction-tuned setup, or prompt/response pairs if you want a question-answer style dataset.

3.1 Create Instruction-Prompt Pairs

For example, you might define a single “system instruction” or question about NPR 7150.2D, and the target is the chunk’s content. You can also combine multiple chunks into a single training example if they logically form a single unit.

training_examples = []

for content, label in rows:
    # Simple approach: use label + " content" as part of an instruction
    # In reality, you should design how you want the GPT to use the data.
    # For instance, if label == "SWE", you might set an instruction that says:
    # "Explain the requirement from NPR 7150.2D labeled SWE in detail."
    
    # Example instruction
    instruction_text = f"Provide details about this NPR 7150.2D chunk labeled: {label}."
    
    # The 'response' might be the chunk's content itself.
    # Or you could build a question/answer if desired.
    response_text = content
    
    training_examples.append({
        "instruction": instruction_text,
        "input": "",   # In some setups, you can keep a separate "input"
        "output": response_text
    })

Now training_examples is a list of dictionaries that might look like this:

[
  {
    "instruction": "Provide details about this NPR 7150.2D chunk labeled: SWE.",
    "input": "",
    "output": "Text content from the database..."
  },
  ...
]

4. Convert Data into a Hugging Face `Dataset`

We’ll create a Dataset object so we can feed it to a Trainer or a PEFT pipeline:

from datasets import Dataset

hf_dataset = Dataset.from_list(training_examples)
# If you have a separate validation set, you might create that too.

5. Load a Base GPT-like Model and Tokenizer

You’ll need a pretrained model—this could be a GPT-2, GPT-Neo, GPT-J, Llama 2, or another large language model that Hugging Face supports.

from transformers import AutoTokenizer, AutoModelForCausalLM

model_name = "gpt2"  # Example; replace with your chosen model
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)

For advanced GPT variants (like Llama 2), you’ll need the appropriate checkpoint and possibly acceptance of a license or a custom config.

6. Set Up Parameter-Efficient Tuning (PEFT) with LoRA

With PEFT, you only update a small number of parameters (such as LoRA adapters) while leaving the base model weights frozen. Here’s how you might set it up:

from peft import LoraConfig, TaskType, get_peft_model

lora_config = LoraConfig(
    r=8,
    lora_alpha=32,
    target_modules=["c_attn", "c_proj"],  # Example for GPT2; modules will differ for other models
    lora_dropout=0.05,
    bias="none",
    task_type=TaskType.CAUSAL_LM
)

peft_model = get_peft_model(model, lora_config)

# At this point, peft_model wraps your original model with LoRA parameters

7. Preprocess the Data for Causal LM

We’ll need to tokenize our (instruction + output) sequences. A straightforward approach is to combine them into a single text with special tokens, or do instruction + response with a separator.

Simple Example (for demonstration—customize for your real prompting strategy):

def tokenize_example(example):
    # Combine the instruction and output into one sequence. 
    # You might want to add a special token or line break in between.
    text = f"Instruction: {example['instruction']}\nOutput: {example['output']}"
    
    tokenized = tokenizer(text, padding="max_length", truncation=True, max_length=512)
    # For causal LM, the labels are typically the same as input_ids (shifted by the model during training).
    tokenized["labels"] = tokenized["input_ids"].copy()
    return tokenized

hf_dataset = hf_dataset.map(tokenize_example, batched=False)

8. Define a Trainer and Train

Using Hugging Face’s Trainer:

from transformers import TrainingArguments, Trainer

training_args = TrainingArguments(
    output_dir="./peft_npr71502d_lora",
    overwrite_output_dir=True,
    num_train_epochs=3,
    per_device_train_batch_size=2,
    per_device_eval_batch_size=2,
    save_steps=100,
    logging_steps=50,
    evaluation_strategy="no",  # or "steps" if you have a validation set
    learning_rate=1e-4,
    fp16=True,  # if you have a GPU that supports FP16
)

trainer = Trainer(
    model=peft_model,
    args=training_args,
    train_dataset=hf_dataset,
    # eval_dataset=eval_dataset, # Optional if you have a validation set
)

trainer.train()

The model’s base parameters remain mostly frozen (due to PEFT/LoRA).
Only a small set of adapter weights are updated.

9. Saving and Using the PEFT Model

After training, you can save your LoRA-adapted model:

trainer.save_model("./peft_npr71502d_lora")
tokenizer.save_pretrained("./peft_npr71502d_lora")

To use the model later:

from transformers import AutoTokenizer, AutoModelForCausalLM
from peft import PeftModel

base_model = AutoModelForCausalLM.from_pretrained("gpt2")
peft_model = PeftModel.from_pretrained(base_model, "./peft_npr71502d_lora")

tokenizer = AutoTokenizer.from_pretrained("./peft_npr71502d_lora")

# Now you can generate predictions
instruction = "Explain the significance of SWE-023 in NPR 7150.2D."
input_text = f"Instruction: {instruction}\nOutput:"

input_ids = tokenizer(input_text, return_tensors="pt").input_ids
output_ids = peft_model.generate(input_ids, max_length=200)
response = tokenizer.decode(output_ids[0], skip_special_tokens=True)
print(response)

Key Points & Best Practices

Instruction Formatting: Decide on a consistent template for “Instruction” vs. “Output” (or “Question” vs. “Answer,” etc.).
LoRA Configuration: You may need to customize target_modules for each specific GPT-like model architecture.
Data Quality: The better curated your SWE, shall, topic, and descriptive chunks (and how they’re labeled), the higher-quality your training signals will be.
Scaling: For large models (e.g., Llama 2), consider using multi-GPU setups or parameter-efficient techniques (which LoRA is designed for).
Evaluation: To properly measure performance, include a validation set or use an instruction QA approach to check the model’s correctness and coverage of NPR 7150.2D requirements.

Wrapping Up

This end-to-end example shows how to:

Pull NPR 7150.2D data from a database with relevant labels.
Format that data into instruction/response pairs (or prompt/target pairs).
Fine-tune a base GPT model using LoRA (a form of Parameter-Efficient Tuning) so that it responds specifically to NASA NPR 7150.2D queries.
Save and deploy the resulting model.

Adjust the hyperparameters, chunking strategy, and instruction templates as needed for your specific use case and desired outcome.

From <https://chatgpt.com/> ChatGPT o1

Fine Tuning a Custom GPT

Given my database table of NPR 7150.2D records, describe a parameter efficient tuning dataset that I should generate

Crafting a dataset schema
I’m constructing a dataset schema with "instruction," "input," and "output" columns. The instructions vary by label, aiming for clear parameter-efficient tuning.
Leveraging labels
I'm wrapping my head around how labels guide instruction design, like using "SWE" for interpreting or summarizing NPR 7150.2D requirements, ensuring clear, contextually rich instructions.

Below is an example of how you might design and structure a parameter-efficient tuning (PEFT) dataset using the NPR 7150.2D records stored in your database. The goal is to create a dataset that helps your model (e.g., a GPT-like large language model) learn to understand, explain, and apply these requirements effectively.

1. Overview of the Dataset

Each record in your database presumably has at least two fields:

content: The text snippet from NPR 7150.2D.
label: The category (e.g., "topic", "descriptive", "SWE", "shall").

To fine-tune or instruct-tune your model, you typically need a format such as:

instruction: A prompt or question telling the model what to do.
input: Additional context (optional).
output: The “ground truth” or desired response.

For PEFT (e.g., using LoRA), you can keep the structure the same; you simply adapt the training process to only update a subset of parameters. The dataset structure itself is typically identical to a standard instruction-tuning dataset.

2. Dataset Schema

Below is a suggested JSON-like schema for each training example in your dataset:

{
  "instruction": "string",
  "input": "string",
  "output": "string"
}

instruction: The command or query to the model, e.g., “Explain this NPR 7150.2D requirement.”
input: Any additional text context you want to provide to the model. In some setups, you might put the entire NPR 7150.2D chunk here, or you might also keep it minimal.
output: The correct or helpful response that you want the model to learn to produce.

3. Generating Examples by Label

You can create different instruction and output patterns based on the label of the chunk. Below are some suggestions:

A. Label = `"topic"`

Purpose: “Topic” might be high-level headings or summary areas from NPR 7150.2D.
Example Instruction: “Summarize the following topic from NPR 7150.2D.”
Example Input: Provide the chunk text that describes the broader topic.
Example Output: A concise summary or restatement.

Sample:

{
  "instruction": "Summarize the following NPR 7150.2D topic in your own words.",
  "input": "Safety and Mission Assurance Policies: NASA’s approach involves...",
  "output": "This topic addresses NASA’s overarching safety assurance strategies..."
}

B. Label = `"descriptive"`

Purpose: General descriptive text explaining context, rationale, or guidance.
Example Instruction: “Explain the context of this NPR 7150.2D description.”
Example Input: The chunk of text that is purely descriptive.
Example Output: A short or detailed elaboration of the text.

Sample:

{
  "instruction": "Explain the rationale behind the following NPR 7150.2D description.",
  "input": "Rationale: The project manager shall ensure all software processes...",
  "output": "This descriptive section outlines why managers must oversee software..."
}

C. Label = `"SWE"`

Purpose: Requirement statements labeled with SWE-###.
Example Instruction: “Interpret this NPR 7150.2D SWE requirement, and describe how a project can comply.”
Example Input: The text for SWE-123, for instance.
Example Output: A thorough explanation, plus potential compliance steps or best practices.

Sample:

{
  "instruction": "Interpret the following NPR 7150.2D requirement (SWE-123), and describe recommended steps for compliance.",
  "input": "SWE-123: The project shall maintain a software risk management plan...",
  "output": "SWE-123 requires every project to have a documented approach to identify..."
}

D. Label = `"shall"`

Purpose: Text containing mandatory “shall” statements.
Example Instruction: “Explain this ‘shall’ statement and outline the necessary actions to meet it.”
Example Input: The chunk containing the “shall” requirement.
Example Output: A breakdown of what the statement mandates and how to satisfy it.

Sample:

{
  "instruction": "Summarize the following ‘shall’ statement from NPR 7150.2D and list the key actions required for compliance.",
  "input": "The project shall develop and maintain a software configuration management plan...",
  "output": "This ‘shall’ statement requires a comprehensive plan defining how software..."
}

4. Combining Records into Instruction/Output Pairs

Below is pseudocode that illustrates how to construct your dataset from the database:

training_data = []

for (content, label) in database_rows:
    if label == "topic":
        instruction = "Summarize the following NPR 7150.2D topic in your own words."
        output = "Your desired summary or explanation of the content."
    elif label == "descriptive":
        instruction = "Explain the context of the following NPR 7150.2D description."
        output = "An elaboration or explanation of the content."
    elif label == "SWE":
        instruction = "Interpret the following NPR 7150.2D requirement (SWE) and describe recommended steps for compliance."
        output = "A thorough, correct interpretation of the content, focusing on compliance steps."
    elif label == "shall":
        instruction = "Summarize this ‘shall’ statement from NPR 7150.2D and list key actions required for compliance."
        output = "A summary focusing on mandatory compliance actions."

    # In practice, you might just store the content as the 'output' directly,
    # or you might write your own more elaborated or paraphrased text
    # as 'output' so the model learns that style.

    # Option 1: Keep the entire chunk as the 'input' and provide a handcrafted 'output'
    # Option 2: Provide 'input' and 'output' that are both derived from the chunk,
    #           e.g., 'input' is the raw chunk, 'output' is a short summary or
    #           compliance checklist.

    training_data.append({
      "instruction": instruction,
      "input": content,  # The chunk from the database
      "output": "Write your ideal teacher-like response or summary here."
    })

Tip: You may want to actually hand-craft the output field for each chunk if you want your model to learn the best possible interpretation of each requirement or statement (rather than just duplicating the chunk’s text). This is akin to creating a high-quality instruction-tuning dataset.

5. Making the Dataset PEFT-Ready

Once you have this list of dictionaries (training_data), you can:

Convert it into a Hugging Face Dataset (or DatasetDict if you have train/validation splits).
Tokenize these “instruction + input => output” pairs.
Use a library like PEFT to apply LoRA or another parameter-efficient method on your base language model.

The final result is a dataset that pairs each chunk of NPR 7150.2D text (input) with:

A relevant instruction that frames the chunk’s context (depending on label).
A desired output that demonstrates how the model should interpret, summarize, or apply that chunk.

6. Example of a Final Training Example

Here’s how an example record might look once constructed:

{
  "instruction": "Interpret the following NPR 7150.2D requirement (SWE) and describe recommended steps for compliance.",
  "input": "SWE-023: The project shall develop and maintain a software risk management plan...",
  "output": "SWE-023 specifies the need for a detailed plan outlining how software risks..."
}

You will end up with many such records, each capturing a label-specific instruction and the content.

7. Best Practices for a High-Quality Dataset

Ensure Accuracy
- Your output text should be carefully reviewed for correctness and completeness, especially when it comes to mandatory “shall” statements or SWE-### specifics.
Vary Instructions
- Use multiple instruction phrasings for the same label to avoid overfitting to a single prompt style (“Explain,” “Summarize,” “Break down,” etc.).
Keep the Dataset Balanced
- Make sure you have enough examples for each label (topic, descriptive, SWE, shall) so the model learns how to handle all categories.
Include Edge Cases
- If there are short or complicated chunks, or if certain SWE requirements reference others, include these to help the model handle real-world complexity.
Train/Validation Split
- Keep a portion of your data (10–20%) for validation, so you can measure how well your tuned model handles unseen text.

Conclusion

A parameter-efficient tuning dataset for your custom GPT model should revolve around instruction-based examples that show how the model should interpret and respond to NPR 7150.2D content. By tagging your database records as "topic", "descriptive", "SWE", or "shall", you can create label-specific instructions and expert responses (or summaries) that guide the model to provide helpful, context-aware answers.

This approach ensures your custom GPT:

Understands each requirement level and context (SWE vs. shall vs. descriptive).
Learns to produce consistent and factually correct guidance for anyone looking to comply with or understand NASA’s NPR 7150.2D software engineering requirements.

I would like "topic" to be a separate field, i.e. label, topic, content

Organizing schema
I’m thinking through a structured data schema for NPR content, dividing fields into "label," "topic," "content," "instruction," and "output" to enhance clarity.
Finalizing data organization
I'm piecing together the data structure: "label" for category, "topic" for classification, "content" for text, and "instruction" for guidance. Outputs will be derived from these fields.

Below is an updated approach to structuring your parameter-efficient tuning dataset for NPR 7150.2D so that topic is treated as a separate field alongside label and content. This lets you capture more specific metadata about each chunk in NPR 7150.2D.

1. Revised Data Fields

Instead of storing only (content, label), you’ll now have:

label: One of the categories ("topic", "descriptive", "SWE", or "shall").
topic: A higher-level subject area or concept within NPR 7150.2D (e.g., “Software Risk Management,” “Configuration Management,” etc.).
content: The actual text snippet of NPR 7150.2D.

To prepare for instruction-based fine-tuning, you typically need:

instruction: A prompt that tells the model what to do.
input: Optional additional text if you separate the prompt from the chunk.
output: The ideal or correct response you want the model to learn.

Hence, your final dataset record might look like this JSON schema:

{
  "label": "string",    // e.g. "SWE"
  "topic": "string",    // e.g. "Risk Management"
  "content": "string",  // e.g. "SWE-123: The project shall maintain a software risk management plan..."
  "instruction": "string",
  "input": "string",
  "output": "string"
}

2. Construction Logic

Below is an outline of how you might generate these fields. You can adapt this logic to your existing database schema.

2.1 Example Database Schema

Suppose your table is named npr_records with columns:

id (primary key)
label (e.g., "topic", "descriptive", "SWE", or "shall")
topic (e.g., “Risk Management,” “Software Safety,” etc.)
content (the raw text chunk)

2.2 Extracting Rows From the Database

import sqlite3

connection = sqlite3.connect("npr71502D.db")
cursor = connection.cursor()

cursor.execute("""
SELECT label, topic, content
FROM npr_records
""")
rows = cursor.fetchall()

connection.close()

Each row is a tuple: (label_value, topic_value, content_value).

2.3 Defining a Mapping to `instruction` and `output`

To instruction-tune effectively, you want to design prompts that reflect what you expect a user to request or how you want the model to respond. Below is an example function that converts (label, topic, content) into (instruction, input, output).

def create_training_example(label, topic, content):
    # Base instruction template you can tweak or expand
    if label == "topic":
        instruction = f"Summarize the following NPR 7150.2D topic related to '{topic}'."
        # Optionally, we can store the entire text as 'input' and craft a summary as 'output'
        input_text = content
        output_text = (
            "A short summary or elaboration of the text chunk focusing on the main points."
            " (In production, you might store your curated summary here.)"
        )

    elif label == "descriptive":
        instruction = f"Explain the context of this descriptive text about '{topic}' from NPR 7150.2D."
        input_text = content
        output_text = (
            "A detailed explanation or paraphrase that clarifies the context and significance."
        )

    elif label == "SWE":
        instruction = f"Interpret the following SWE requirement for '{topic}' and describe steps for compliance."
        input_text = content
        output_text = (
            "A thorough, compliance-focused explanation of how to fulfill this SWE requirement."
        )

    elif label == "shall":
        instruction = f"Summarize this 'shall' statement for '{topic}' and list actions required for compliance."
        input_text = content
        output_text = (
            "A breakdown of the mandatory nature of the 'shall' statement, plus recommended actions."
        )

    else:
        # fallback if label doesn't match
        instruction = "Explain the following text from NPR 7150.2D."
        input_text = content
        output_text = "Your curated explanation."

    return {
        "label": label,
        "topic": topic,
        "content": content,
        "instruction": instruction,
        "input": input_text,
        "output": output_text
    }

2.4 Generating the Final Dataset

training_data = []

for (label_value, topic_value, content_value) in rows:
    example = create_training_example(label_value, topic_value, content_value)
    training_data.append(example)

You now have a list of dictionary records, each containing the fields:

label
topic
content
instruction
input
output

3. Example Dataset Entries

Below is how an example record might look after running the above logic:

{
  "label": "SWE",
  "topic": "Risk Management",
  "content": "SWE-023: The project shall develop and maintain a software risk management plan...",
  "instruction": "Interpret the following SWE requirement for 'Risk Management' and describe steps for compliance.",
  "input": "SWE-023: The project shall develop and maintain a software risk management plan...",
  "output": "A thorough, compliance-focused explanation of how to fulfill this SWE requirement."
}

Another example for a "shall" statement:

{
  "label": "shall",
  "topic": "Software Configuration Management",
  "content": "The project shall establish and maintain a configuration management plan for all software...",
  "instruction": "Summarize this 'shall' statement for 'Software Configuration Management' and list actions required for compliance.",
  "input": "The project shall establish and maintain a configuration management plan for all software...",
  "output": "A breakdown of the mandatory nature of the 'shall' statement, plus recommended actions."
}

4. Why This Helps PEFT

Rich Metadata: By including label and topic as distinct fields, your model can learn the difference between different types of text (SWE vs. descriptive vs. shall) and the subject area (topic).
Clear Instructions: The instruction field guides your model to perform the exact kind of transformation or explanation you want.
Flexibility: You can scale or alter the instructions easily without changing your raw NPR text. If you decide you want different prompts (e.g., “Provide a compliance checklist for this requirement”), you just update the function that generates the dataset.
Ease of Prompting: The final dataset can be used in a standard instruction + input => output format, which is a common pattern for GPT-style fine-tuning, including LoRA-based PEFT.

5. Next Steps

Curation: If you have time, manually craft high-quality output fields that give the best possible expansions, summaries, or compliance guidance for each chunk.
Tokenization & Training: Convert your dataset to a Hugging Face Dataset, then apply tokenization, and run PEFT with a base GPT model (e.g., GPT-2, GPT-Neo, Llama 2, etc.).
Validation: Keep a portion of records aside as a validation set. Evaluate how well the model handles new queries about NPR 7150.2D.

Final Summary

To include "topic" as a separate field in your PEFT dataset:

Store each NPR 7150.2D chunk in a record with label, topic, and content.
Generate instruction + input + output fields using your own function that tailors the prompt to the label and references the topic.
This dataset structure (label, topic, content, instruction, input, output) allows you to do parameter-efficient tuning so your model can answer questions, summarize requirements, and guide compliance for NASA’s NPR 7150.2D with greater accuracy and context-awareness.

From <https://chatgpt.com/> ChatGPT o1