SentenceTransformer based on google/embeddinggemma-300m

Model Details

Model Description

• Model Type: Sentence Transformer
• Base model: google/embeddinggemma-300m
• Maximum Sequence Length: 2048 tokens
• Output Dimensionality: 768 dimensions
• Similarity Function: Cosine Similarity

Model Sources

• Documentation: Sentence Transformers Documentation
• Repository: Sentence Transformers on GitHub
• Hugging Face: Sentence Transformers on Hugging Face

Full Model Architecture

SentenceTransformer(
  (0): Transformer({'max_seq_length': 2048, 'do_lower_case': False, 'architecture': 'Gemma3TextModel'})
  (1): Pooling({'word_embedding_dimension': 768, 'pooling_mode_cls_token': False, 'pooling_mode_mean_tokens': True, 'pooling_mode_max_tokens': False, 'pooling_mode_mean_sqrt_len_tokens': False, 'pooling_mode_weightedmean_tokens': False, 'pooling_mode_lasttoken': False, 'include_prompt': True})
  (2): Dense({'in_features': 768, 'out_features': 3072, 'bias': False, 'activation_function': 'torch.nn.modules.linear.Identity'})
  (3): Dense({'in_features': 3072, 'out_features': 768, 'bias': False, 'activation_function': 'torch.nn.modules.linear.Identity'})
  (4): Normalize()
)

Usage

Direct Usage (Sentence Transformers)

Evaluation

Metrics

Triplet

• Datasets: baseline_pre_training and ft-dev
• Evaluated with TripletEvaluator

Training Details

Training Dataset

Unnamed Dataset

• Size: 741 training samples
• Columns: query, answer, and negative
• Approximate statistics based on the first 741 samples:

  	query	answer	negative
  type	string	string	string
  details	min: 20 tokens mean: 31.37 tokens max: 56 tokens	min: 61 tokens mean: 126.29 tokens max: 228 tokens	min: 69 tokens mean: 124.72 tokens max: 222 tokens

• Samples:

  query	answer	negative
  What is the root cause of the data loss identified in JIRA-DATA-781, and what is the proposed plan to both fix the issue and recover the missing data?	The root cause is a schema change in the [object Object] service (v2.9.1) where the [object Object] field in the transaction payload was changed from a flat JSON to a nested object. The current BigQuery ingestion pipeline's dataflow job cannot parse this new structure, causing a [object Object] that leads to a silent 4% data loss. The proposed plan involves Rahul Verma developing a patch for the dataflow job to handle the nested structure, which is expected by EOD. Additionally, a backfill process will be planned to re-process the raw logs from the affected period to recover the lost data, with a meeting to discuss the backfill strategy scheduled for the following day.	Aishwarya is encountering an intermittent [object Object] in a Python script designed for S3 data reconciliation. The issue stems from a change in the 'transaction timestamp' column's format. While she has attempted a fix by adjusting the datetime parsing function on the branch [object Object], the problem persists. Her hypotheses for the root cause of these intermittent failures include a more complex data transformation logic error she might be missing, the possibility of mixed timestamp formats within the data, or a potential connection to recent IAM role changes for S3 access.
  What are the specific documentation and compliance actions being taken in response to the UPI Juspay latency spike, and what is the potential consequence if the issue persists?	The latency spike is being formally documented as a 'major service degradation event' for the quarterly RBI filing. An incident report has been created on Confluence (doc ID: COMP-2023-Q4-PSP-01), and all technical findings and communication logs must be attached to Jira ticket #PAY-4812 to maintain a critical audit trail. If the issue is not resolved, the company may need to trigger a penalty clause.	The investigation into the UPI 'Payment Pending' latency spike is being formally tracked under JIRA ticket OPS-1724. The immediate plan involves Siddharth Nair pulling detailed transaction logs from BigQuery for the specific merchant_id affected between 10:00 and 11:00 AM today. This issue is considered a high priority as it is impacting a key merchant. The team, including Pooja Joshi and Riya Kapoor, will convene for a sync-up call after lunch to review the findings from the logs.
  What immediate actions are being taken to address the latency spike on the ICICI payment gateway, and how will the success of these actions be validated?	To address the latency spike, a critical Jira ticket (BREEZE-4812) has been raised for the SRE team to immediately update the BGP routing configuration, effectively deprioritizing the problematic ISP for traffic from the 'payment-gateway' service. The effectiveness of this fix will be validated by a new, dedicated Grafana dashboard, which Riya Kapoor will create to specifically monitor the ICICI net banking success rate for the affected 103.22.x.x IP range once the network changes are deployed via the CI/CD pipeline.	Meera Reddy has proposed a multi-step plan to address the ICICI API latency spike. The plan involves asking the engineering team to investigate if specific transaction types (like subscriptions vs. one-time payments) are disproportionately affected. Concurrently, a consolidated report with failed transaction IDs and latency graphs will be prepared. Finally, Meera will escalate the issue by raising a high-priority ticket with the ICICI support team by the end of the day.

• Loss: MultipleNegativesRankingLoss with these parameters:
  json

  1{ 2 "scale": 20.0, 3 "similarity_fct": "cos_sim", 4 "gather_across_devices": false 5}

Training Hyperparameters

Non-Default Hyperparameters

• eval_strategy: steps
• per_device_train_batch_size: 128
• per_device_eval_batch_size: 128
• learning_rate: 3e-05
• weight_decay: 0.01
• num_train_epochs: 4
• warmup_ratio: 0.1
• bf16: True
• batch_sampler: no_duplicates

All Hyperparameters

Training Logs

Framework Versions

• Python: 3.12.3
• Sentence Transformers: 5.1.0
• Transformers: 4.56.1
• PyTorch: 2.8.0+cu128
• Accelerate: 1.10.1
• Datasets: 4.0.0
• Tokenizers: 0.22.0

Citation

BibTeX

Sentence Transformers

MultipleNegativesRankingLoss