metadata

tags:
  - sentence-transformers
  - sentence-similarity
  - feature-extraction
  - generated_from_trainer
  - dataset_size:3625
  - loss:CachedMultipleNegativesRankingLoss
base_model: nomic-ai/modernbert-embed-base
widget:
  - source_sentence: What is the purpose of the analysis steps outlined in the document?
    sentences:
      - "Structure of the document\n\nThe structure of the present document is as follows:\n\n-   Chapter [sasguide:par:analysis] introduces the investigator to the\n    analysis of XMM-Newton\n    (http://www.cosmos.esa.int/web/xmm-newton/technical-details) data.\n    It provides a brief description of XMM-Newton\n    (http://www.cosmos.esa.int/web/xmm-newton/technical-details)\n    observation and calibration files and outlines the analysis steps\n    required to produce calibrated event files and to extract scientific\n    products.\n\n-   Chapter [sasguide:par:gui] describes the SAS graphical user\n    interface (GUI), a user friendly tool which enables SAS interactive\n    analysis tasks to be run without using the command line.\n\n-   Chapters [sasguide:par:epic], [sasguide:par:rgs] and\n    [sasguide:par:om] describe the SAS analysis steps required to obtain\n    EPIC\n    (http://www.cosmos.esa.int/web/xmm-newton/technical-details-epic),\n    RGS (http://www.cosmos.esa.int/web/xmm-newton/technical-details-rgs)\n    and OM\n    (http://www.cosmos.esa.int/web/xmm-newton/technical-details-om) data\n    products, respectively, which can be used afterwards by standard\n    astronomical software packages.\n\n-   Chapter [sasguide:xmmextractor] gives an overview of a SAS procedure\n    to produce high-level science products for XMM-Newton\n    (http://www.cosmos.esa.int/web/xmm-newton/technical-details)\_cameras\n    from the raw, uncalibrated, data files contained in the Observation\n    Data File (ODF). The procedure allows for some interactivity which\n    lets the user take decisions concerning the analysis process.\n"
      - |
        ommosaic
        -   Whilst tests have so far shown that scattered-light features do not
            effect the cross-correlation algorithm, further testing is underway
            and the method should be used with caution.

        -   Tests using the cross-algorithm on aspect-corrected sky-images have
            so-far shown the computed offsets to be small (less than 0.2
            pixels). If both the aspect-correction and the cross-correlation
            algorithm were perfect, they should be zero. However the error in
            the aspect-correction can be up to 1 arc sec, and further testing
            needs to be done to evaluate any differences.

        -   It would be desireable to perform a further aspect correction on the
            sky-images- this would require either a new OM task or, possibly, a
            modification to omsrclistcomb. Note that even if the sky-images have
            not been aspect-corrected, the coordinates of the sources in the
            observation source-list file may have.
      - |
        emchain
        The chain will adapt to the evolution of its constituents and to the
        organisation of the pipeline.

        The current implementation is a Perl script.
  - source_sentence: What is the purpose of transforming the sky coordinates?
    sentences:
      - |
        PRODUCT: SSC logo 1 (SSCLG1) 

        -   This file contains a schematic image of the XMM-Newton telescope
            front end

        -   This is a product of class PPSOBS

        -   The product is delivered in PNG format

        -   There is one file per observation. File size is 3KB.
      - >-
        dpsssrc

        ## Parameters


        **set** (Mandatory): EPIC Maximum-Likelihood source list, identifier

        TTTTTT = EMSRLI (Type: string, Default: P0123700101PNS003EMSRLI0000.FIT,

        Range: applies only for EPIC Maximum-Likelihood detection lists)


        **maxlikthresh** (Optional): threshold to set the source flag

        ‘source likelihood below a certain threshold (Type: real value, Default:
        50., Range: must be greater than 0.)’ to T 

        **prefix** (Optional): prefix for output name (‘prefix (Type: string,

        Default: flag_, Range: applies only for EPIC Maximum-Likelihood

        detection lists)_

        [INPUT FILES]

        dpsssrc

        1.  POOOOOOOOOODDSEEEEMSRLISXXX.FIT EPIC Maximum-Likelihood detection
            source List. The identifier for TTTTTT must be equal to EMSRLI. The
            naming convention given above is according to and SSC-LUX-TN-0038.

        [OUTPUT FILES]

        dpsssrc

        1.  flag_POOOOOOOOOODDSEEEEMSRLISXXX.FIT

            Copy of a EPIC Maximum-Likelihood detection list. Three new column
            are created and the source flag setting for sources below a certain
            detection threshold is performed.

        [COMMENTS] dpsssrc

        -   This task only applies for EPIC Maximum-Likelihood detection lists.

        [CAL USAGE] dpsssrc
      - |
        emosaicproc
        The data preparation consists of:

        -   transforming the sky coordinates by every event file corresponding
            to the different instruments and pointings to a common image centre,

        -   extracting images per instrument, pointing and spectral selection,
            using common filtering and evtl. provided GTIs
  - source_sentence: In pn imaging mode event lists, what is the type of the OFFSETX column?
    sentences:
      - |
        Observation summary products
      - |
        -   The FITS format OM OSW images are rotated and rebinned to
            North-aligned sky coordinates.

        -   The files are identified using the keyword

                CONTENT = 'OM OSW SKY IMAGE'  (SIMAGE)
                for default and User configurations
                or
                CONTENT = 'OM FULL-FRAME SKY IMAGE'  (FSIMAG)
                for low and high resolution full-frame configurations
                or
                CONTENT = 'OM FAST MODE OSW SKY IMAGE'  (SIMAGF)
                for FAST mode window

        -   This is a product of class OMSW.

        -   These images may be rectified against the USNO-B1 catalogue in which
            case keywords RA_OFF, DEC_OFF and POSCOROK are added to the header.

        -   This product is used for comparison between optical and X-ray images
            (also in sky coordinates). It is used in the production of OM OSW
            PNG images.

        -   There is one OM OSW FITS sky image for each OM OSW FITS image, and
            each file, on average, occupies ∼1.2MB uncompressed while the FAST
            mode image is typically 14KB uncompressed. For the full frame images
            the size is typically 22MB uncompressed.
      - |
        -   In pn event lists this extension contains the CCD columns to which
            an additional offset is applied to reduce noise (the offset is later
            subtracted again by the SAS). In the MOS event lists this extension
            currently defines columns outside the sensitive CCD window, to which
            formal very high values of the offset are associated. These columns
            are discarded by the data processing.

        -   For MOS imaging mode event lists this extension contains the
            following columns:

              Name      Type             Description
              --------- ---------------- ----------------------------------------------------------
              RAWX      2-byte INTEGER   Row or column of the bad offset
              OFFSETX   2-byte INTEGER   amplitude of additional column offset (0 for row offset)
              OFFSETY   2-byte INTEGER   amplitude of additional row offset (0 for column offset)
              CCDNR     1-byte           CCD where the offset occurs

        -   For MOS timing mode event lists this extension contains the
            following columns:

              Name      Type             Description
              --------- ---------------- ---------------------------------------
              RAWX      2-byte INTEGER   Row or column of the bad offset
              OFFSETX   2-byte INTEGER   amplitude of additional column offset
              CCDNR     1-byte           CCD where the offset occurs

        -   For pn imaging mode event lists this extension contains the
            following columns:

              Name      Type             Description
              --------- ---------------- ---------------------------------------
              RAWX      2-byte INTEGER   Row of the bad offset
              OFFSETX   2-byte INTEGER   amplitude of additional column offset
              CCDNR     1-byte           CCD where the offset occurs

        -   For pn timing mode event lists this extension contains the following
            columns:

              Name      Type             Description
              --------- ---------------- ---------------------------------------
              RAWX      2-byte INTEGER   Row of the bad offset
              OFFSETX   2-byte INTEGER   amplitude of additional column offset
              CCDNR     1-byte           CCD where the offset occurs

        -   Note that currently, the offset table is always empty and only the
            CCDNR column is present and it is unfilled. This may change in the
            future.
  - source_sentence: >-
      What is the minimal time resolution with which entries into the AHF can be
      made in case of instantaneous excursions in the stable pointing mode?
    sentences:
      - |
        -   This extension is only present in pn event files. It gives the
            number of rejections of each column (discarded lines) of CCD nn over
            the course of the exposure.

        -   There is one extension per CCD in the relevant mode (IMAGING or
            TIMING) during the exposure.

        -   This extension contains the following columns:

              Name     Type             Description
              -------- ---------------- -----------------------------------------------
              DLIODF   4-byte INTEGER   Number of rejections by onboard MIP algorithm
              DLISAS   4-byte INTEGER   Number of subsequent rejections by the SAS

        -   Each row corresponds to a column.
      - "Attitude & Orbit Control Subsystem (AOCS)\n\nThe AOCS determines the attitude of the \_while in orbit, based on the\ninformation from one of ’s two star trackers (which are operated in cold\nredundancy) and its “Fine Sun Sensors”. During slews and the post-slew\nphase (comprising attitude determination, trim, and settling of the\nspacecraft), entries are made into the Attitude History File (AHF) every\n10 seconds. Note that during slews the AHF will not contain attitudes\nreconstructed from actual AOCS telemetry, but the results of a slew\ntime/path predictor, based on the actually observed slew start/end times\nand attitudes. The accuracy of the attitude reconstruction during slews\nis expected to be better than 1′.\n\nIn the “stable pointing mode” (i.e., after the slews and the post-slew\nphase), the conditions under which entries into the AHF are made are\noptimised parameters. An entry is made into the AHF only in case of\nRelative Pointing Errors (RPEs) exceeding the programmed limit. The\nminimal programmable limit (i.e., the smallest programmable deviation\nfrom the nominal boresight) is 1″. The minimal time resolution with\nwhich entries into the AHF can be made in case of such instantaneous\nexcursions is 2 seconds. For a single nominal pointing entry, only a\nmean RPE will be provided.\n\nThe AOCS attitude information is independent of that from the OM\n(http://www.cosmos.esa.int/web/xmm-newton/technical-details-om) ’s star\ntracking windows (§\_[uhb:par:omwindows]).\n\nThe AHF is a file containing processed AOCS telemetry. Clipped to the\nstart/end times of an observation or slew, the complete AHF for the\nrelevant revolution becomes an ODF or SDF component which is delivered\nto the observer. For “stable pointing periods” the data records identify\nintervals of time during which the spacecraft’s boresight did not\ndeviate by more than a configurable limit from the mean boresight during\nthat period. For open loop slews and post-slew attitude trims, the AHF\nprovides the instantaneous boresight at equidistant points in time\n(typically 10 seconds). It should be noted that attitudes for open loop\nslews are derived from a “slew model” into which the boundary conditions\n(actual start/end times and attitudes) have been entered, i.e., the\nintermediate attitudes provided for slews are not based on sensor data\ntelemetered during the slews.\n\nIt should be noted that there is an additional file that holds attitude\ndata, which can be used by the\nhttp://www.cosmos.esa.int/web/xmm-newton/sas\n(http://www.cosmos.esa.int/web/xmm-newton/sas). This is the so called\nRaw Attitude File (RAF) which provides the attitude information at the\nmaximum possible rate (one entry every 0.5 s). The AHF is in fact a\nsmoothed and filtered version of the RAF. The online documentation of\nthe http://www.cosmos.esa.int/web/xmm-newton/sas\n(http://www.cosmos.esa.int/web/xmm-newton/sas)\_package oal (section on\nSAS_ATTITUDE) gives further info on how to select amongst the AHF and\nRAF source of ODF attitude data.\n"
      - >
        Generating EPIC images


        EPIC (http://www.cosmos.esa.int/web/xmm-newton/technical-details-epic)

        images can be created from an event file with the evselect

        (http://xmm-tools.cosmos.esa.int/external/sas/current/doc/evselect/index.html)

        task from the command line or with the xmmselect

        (http://xmm-tools.cosmos.esa.int/external/sas/current/doc/xmmselect/index.html)

        task in an interactive GUI driven way.
  - source_sentence: What is the primary purpose of the FITS format?
    sentences:
      - |
        Scope: xrt

        There will be three instances of each of these files.

        Calibration type: XAreaEf
        Description: X-ray effective area of a single mirror module versus
        energy, field angle, and azimuth

        Calibration type: XEncirEn
        Description: X-ray encircled energy function of a single mirror module
        versus energy, field angle, and azimuth

        Calibration type: XPSF
        Description: X-ray point spread function of a single mirror module
        versus energy, field angle, and field azimuth
      - "ASCII\n\nASCII files are used to present script and some tabular information. In\nparticular, each ODF/SDF contains a single summary file, with a summary\nof the information relating to the observation or slew (see\nSect.\_[dfhb:par:odf]).\n"
      - |
        FITS format

        All of the ODF/SDF component files, with the exception of the summary
        files, reconstructed orbit file, and raw attitude file, are FITS files
        and conform to the standard. A description of the FITS format can be
        found in , which is accessible also at the URL
        The calibration files and the bulk of the PPS products also conform to
        the FITS standard. Wherever possible and desirable the calibration files
        and the PPS products follow the conventions of the OGIP
        (http://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/ofwg_intro.html) (Office
        of Guest Investigator Programs) FITS working group. The HEASARC FITS
        Working Group activities are described at the following URL:
        For FITS files where OGIP FITS standards are not applicable or
        available, new standards closely following the OGIP approach are used.

        The FITS format is primarily designed to store scientific data sets
        consisting of multidimensional arrays (1-D spectra, 2-D images or 3-D
        data cubes) and 2-dimensional tables containing rows and columns of
        data. A FITS data file is composed of a sequence of Header + Data Units
        (HDUs).

        The general structure of a FITS file is as follows:

        -   a primary header;

        -   a primary data array of zero length;

        -   zero or more extensions

        Each extension consists of an extension header and a data section.
        Extensions are named and can appear in any order. Only the following
        FITS extensions are used:

        -   ASCII table: XTENSION=TABLE

        -   binary table: XTENSION=BINTABLE

        -   image: XTENSION=IMAGE

        The header consists of keyword=value statements, which describe the
        organisation of the data in the HDU and the format of the contents. It
        may also provide additional information, for example, about instrument
        status or the history of the data. The following block contains the
        data, which are structured as specified in the header. The data section
        of the HDU may contain a digital image, a table or a multidimensional
        matrix that is not an image. An HDU need not contain data.
pipeline_tag: sentence-similarity
library_name: sentence-transformers

SentenceTransformer based on nomic-ai/modernbert-embed-base

This is a sentence-transformers model finetuned from nomic-ai/modernbert-embed-base. It maps sentences & paragraphs to a 768-dimensional dense vector space and can be used for semantic textual similarity, semantic search, paraphrase mining, text classification, clustering, and more.

Model Details

Model Description

Model Type: Sentence Transformer
Base model: nomic-ai/modernbert-embed-base
Maximum Sequence Length: 8192 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': 8192, 'do_lower_case': False}) with Transformer model: ModernBertModel 
  (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): Normalize()
)

Usage

Direct Usage (Sentence Transformers)

First install the Sentence Transformers library:

pip install -U sentence-transformers

Then you can load this model and run inference.

from sentence_transformers import SentenceTransformer

# Download from the 🤗 Hub
model = SentenceTransformer("sentence_transformers_model_id")
# Run inference
sentences = [
    'What is the primary purpose of the FITS format?',
    'FITS format\n\nAll of the ODF/SDF component files, with the exception of the summary\nfiles, reconstructed orbit file, and raw attitude file, are FITS files\nand conform to the standard. A description of the FITS format can be\nfound in , which is accessible also at the URL\nThe calibration files and the bulk of the PPS products also conform to\nthe FITS standard. Wherever possible and desirable the calibration files\nand the PPS products follow the conventions of the OGIP\n(http://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/ofwg_intro.html) (Office\nof Guest Investigator Programs) FITS working group. The HEASARC FITS\nWorking Group activities are described at the following URL:\nFor FITS files where OGIP FITS standards are not applicable or\navailable, new standards closely following the OGIP approach are used.\n\nThe FITS format is primarily designed to store scientific data sets\nconsisting of multidimensional arrays (1-D spectra, 2-D images or 3-D\ndata cubes) and 2-dimensional tables containing rows and columns of\ndata. A FITS data file is composed of a sequence of Header + Data Units\n(HDUs).\n\nThe general structure of a FITS file is as follows:\n\n-   a primary header;\n\n-   a primary data array of zero length;\n\n-   zero or more extensions\n\nEach extension consists of an extension header and a data section.\nExtensions are named and can appear in any order. Only the following\nFITS extensions are used:\n\n-   ASCII table: XTENSION=TABLE\n\n-   binary table: XTENSION=BINTABLE\n\n-   image: XTENSION=IMAGE\n\nThe header consists of keyword=value statements, which describe the\norganisation of the data in the HDU and the format of the contents. It\nmay also provide additional information, for example, about instrument\nstatus or the history of the data. The following block contains the\ndata, which are structured as specified in the header. The data section\nof the HDU may contain a digital image, a table or a multidimensional\nmatrix that is not an image. An HDU need not contain data.\n',
    'ASCII\n\nASCII files are used to present script and some tabular information. In\nparticular, each ODF/SDF contains a single summary file, with a summary\nof the information relating to the observation or slew (see\nSect.\xa0[dfhb:par:odf]).\n',
]
embeddings = model.encode(sentences)
print(embeddings.shape)
# [3, 768]

# Get the similarity scores for the embeddings
similarities = model.similarity(embeddings, embeddings)
print(similarities.shape)
# [3, 3]

Training Details

Training Dataset

Unnamed Dataset

Size: 3,625 training samples
Columns: anchor and positive
Approximate statistics based on the first 1000 samples:
anchor positive
type string string
details
min: 2 tokens
mean: 15.71 tokens
max: 38 tokens

min: 2 tokens
mean: 412.57 tokens
max: 3755 tokens

	anchor	positive
type	string	string
details	min: 2 tokens mean: 15.71 tokens max: 38 tokens	min: 2 tokens mean: 412.57 tokens max: 3755 tokens

Samples:

anchor	positive
`What is the purpose of the document described in the preface?`	Preface This is the reference document describing the individual XMM-Newton Survey Science Centre (SSC) data product files. It is intended to be of use to software developers, archive administrators and to scientists analysing XMM-Newton data. Please see the SSC data products Interface Control Document (XMM-SOC-ICD-0006-SSC, issue 4.0) for a description of the product group files and other related files that are sent to the SOC. This version (4.3) includes changes related to the upgrade to SAS16.0 in the processing pipeline originally developped in 2012 to uniformly process all the XMM data at that time, from which the 3XMM catalogue was derived. Revisions and additions since version 4.2 are identified by change bars at the right of each page. This document will continue to evolve through subsequent issues, under indirect control from the SAS and SSC configuration control boards. This document is the result of the work of many people. Contributors have included: Hermann Brunner, G...
`What version of the document is described in the preface?`	Preface This is the reference document describing the individual XMM-Newton Survey Science Centre (SSC) data product files. It is intended to be of use to software developers, archive administrators and to scientists analysing XMM-Newton data. Please see the SSC data products Interface Control Document (XMM-SOC-ICD-0006-SSC, issue 4.0) for a description of the product group files and other related files that are sent to the SOC. This version (4.3) includes changes related to the upgrade to SAS16.0 in the processing pipeline originally developped in 2012 to uniformly process all the XMM data at that time, from which the 3XMM catalogue was derived. Revisions and additions since version 4.2 are identified by change bars at the right of each page. This document will continue to evolve through subsequent issues, under indirect control from the SAS and SSC configuration control boards. This document is the result of the work of many people. Contributors have included: Hermann Brunner, G...
`What is the main change in version 4.3 of the document?`	Preface This is the reference document describing the individual XMM-Newton Survey Science Centre (SSC) data product files. It is intended to be of use to software developers, archive administrators and to scientists analysing XMM-Newton data. Please see the SSC data products Interface Control Document (XMM-SOC-ICD-0006-SSC, issue 4.0) for a description of the product group files and other related files that are sent to the SOC. This version (4.3) includes changes related to the upgrade to SAS16.0 in the processing pipeline originally developped in 2012 to uniformly process all the XMM data at that time, from which the 3XMM catalogue was derived. Revisions and additions since version 4.2 are identified by change bars at the right of each page. This document will continue to evolve through subsequent issues, under indirect control from the SAS and SSC configuration control boards. This document is the result of the work of many people. Contributors have included: Hermann Brunner, G...

Loss: CachedMultipleNegativesRankingLoss with these parameters:

{
    "scale": 1.0,
    "similarity_fct": "get_similarity"
}

Evaluation Dataset

Unnamed Dataset

Size: 30 evaluation samples
Columns: anchor and positive
Approximate statistics based on the first 30 samples:
anchor positive
type string string
details
min: 10 tokens
mean: 16.73 tokens
max: 31 tokens

min: 6 tokens
mean: 655.37 tokens
max: 6762 tokens

	anchor	positive
type	string	string
details	min: 10 tokens mean: 16.73 tokens max: 31 tokens	min: 6 tokens mean: 655.37 tokens max: 6762 tokens

Samples:

anchor	positive
`In pn imaging mode event lists, what is the type of the OFFSETX column?`	- In pn event lists this extension contains the CCD columns to which an additional offset is applied to reduce noise (the offset is later subtracted again by the SAS). In the MOS event lists this extension currently defines columns outside the sensitive CCD window, to which formal very high values of the offset are associated. These columns are discarded by the data processing. - For MOS imaging mode event lists this extension contains the following columns: Name Type Description --------- ---------------- ---------------------------------------------------------- RAWX 2-byte INTEGER Row or column of the bad offset OFFSETX 2-byte INTEGER amplitude of additional column offset (0 for row offset) OFFSETY 2-byte INTEGER amplitude of additional row offset (0 for column offset) CCDNR 1-byte CCD where the offset occurs - For MOS timing mode event lists this extension contains the...
`What are the three binary table extensions created per source used for?`	- This product lists bright sources detected by EPIC which fall in the RGS field of view. It also includes the entries for the proposal position and the on-axis location. EPIC and RGS positions are given, as well as RGS spatial and energy-dispersion angle extraction regions for the sources and a background region. - These files are identified using the keyword CONTENT = 'RGS SOURCE LIST' / File content in the primary header. - There are two binary table extensions (SRCLIST and RGSn_BACKGROUND), plus a further three binary table extensions per source (RGSn_SRCm_SPATIAL, RGSn_SRCm_ORDER_1 and RGSn_SRCm_ORDER_2, where n is the number of the RGS (1 or 2) and m is the number of the source. - The SRCLIST extension has the following columns: Name Type Description -------------- ------------------ --------------------------------------------------------- INDEX 2-byte INTEGER Source inde...
`What is the purpose of the analysis steps outlined in the document?`	Structure of the document The structure of the present document is as follows: - Chapter [sasguide:par:analysis] introduces the investigator to the analysis of XMM-Newton (http://www.cosmos.esa.int/web/xmm-newton/technical-details) data. It provides a brief description of XMM-Newton (http://www.cosmos.esa.int/web/xmm-newton/technical-details) observation and calibration files and outlines the analysis steps required to produce calibrated event files and to extract scientific products. - Chapter [sasguide:par:gui] describes the SAS graphical user interface (GUI), a user friendly tool which enables SAS interactive analysis tasks to be run without using the command line. - Chapters [sasguide:par:epic], [sasguide:par:rgs] and [sasguide:par:om] describe the SAS analysis steps required to obtain EPIC (http://www.cosmos.esa.int/web/xmm-newton/technical-details-epic), RGS (http://www.cosmos.esa.int/web/xmm-newton/technical-details-r...

Loss: CachedMultipleNegativesRankingLoss with these parameters:

{
    "scale": 1.0,
    "similarity_fct": "get_similarity"
}

Training Hyperparameters

Non-Default Hyperparameters

eval_strategy: steps
per_device_train_batch_size: 16
per_device_eval_batch_size: 4
num_train_epochs: 2
lr_scheduler_type: constant
warmup_ratio: 0.1
bf16: True
batch_sampler: no_duplicates

All Hyperparameters

Click to expand

overwrite_output_dir: False
do_predict: False
eval_strategy: steps
prediction_loss_only: True
per_device_train_batch_size: 16
per_device_eval_batch_size: 4
per_gpu_train_batch_size: None
per_gpu_eval_batch_size: None
gradient_accumulation_steps: 1
eval_accumulation_steps: None
torch_empty_cache_steps: None
learning_rate: 5e-05
weight_decay: 0.0
adam_beta1: 0.9
adam_beta2: 0.999
adam_epsilon: 1e-08
max_grad_norm: 1.0
num_train_epochs: 2
max_steps: -1
lr_scheduler_type: constant
lr_scheduler_kwargs: {}
warmup_ratio: 0.1
warmup_steps: 0
log_level: passive
log_level_replica: warning
log_on_each_node: True
logging_nan_inf_filter: True
save_safetensors: True
save_on_each_node: False
save_only_model: False
restore_callback_states_from_checkpoint: False
no_cuda: False
use_cpu: False
use_mps_device: False
seed: 42
data_seed: None
jit_mode_eval: False
use_ipex: False
bf16: True
fp16: False
fp16_opt_level: O1
half_precision_backend: auto
bf16_full_eval: False
fp16_full_eval: False
tf32: None
local_rank: 0
ddp_backend: None
tpu_num_cores: None
tpu_metrics_debug: False
debug: []
dataloader_drop_last: False
dataloader_num_workers: 0
dataloader_prefetch_factor: None
past_index: -1
disable_tqdm: False
remove_unused_columns: True
label_names: None
load_best_model_at_end: False
ignore_data_skip: False
fsdp: []
fsdp_min_num_params: 0
fsdp_config: {'min_num_params': 0, 'xla': False, 'xla_fsdp_v2': False, 'xla_fsdp_grad_ckpt': False}
fsdp_transformer_layer_cls_to_wrap: None
accelerator_config: {'split_batches': False, 'dispatch_batches': None, 'even_batches': True, 'use_seedable_sampler': True, 'non_blocking': False, 'gradient_accumulation_kwargs': None}
deepspeed: None
label_smoothing_factor: 0.0
optim: adamw_torch
optim_args: None
adafactor: False
group_by_length: False
length_column_name: length
ddp_find_unused_parameters: None
ddp_bucket_cap_mb: None
ddp_broadcast_buffers: False
dataloader_pin_memory: True
dataloader_persistent_workers: False
skip_memory_metrics: True
use_legacy_prediction_loop: False
push_to_hub: False
resume_from_checkpoint: None
hub_model_id: None
hub_strategy: every_save
hub_private_repo: None
hub_always_push: False
gradient_checkpointing: False
gradient_checkpointing_kwargs: None
include_inputs_for_metrics: False
include_for_metrics: []
eval_do_concat_batches: True
fp16_backend: auto
push_to_hub_model_id: None
push_to_hub_organization: None
mp_parameters:
auto_find_batch_size: False
full_determinism: False
torchdynamo: None
ray_scope: last
ddp_timeout: 1800
torch_compile: False
torch_compile_backend: None
torch_compile_mode: None
dispatch_batches: None
split_batches: None
include_tokens_per_second: False
include_num_input_tokens_seen: False
neftune_noise_alpha: None
optim_target_modules: None
batch_eval_metrics: False
eval_on_start: False
use_liger_kernel: False
eval_use_gather_object: False
average_tokens_across_devices: False
prompts: None
batch_sampler: no_duplicates
multi_dataset_batch_sampler: proportional

Training Logs

Epoch	Step	Training Loss	Validation Loss
0.0441	10	2.3929	-
0.0881	20	2.2876	-
0.1322	30	2.2502	-
0.1762	40	2.2265	-
0.2203	50	2.176	0.9569
0.2643	60	2.1931	-
0.3084	70	2.1666	-
0.3524	80	2.1637	-
0.3965	90	2.1684	-
0.4405	100	2.1373	0.9265
0.4846	110	2.135	-
0.5286	120	2.1159	-
0.5727	130	2.113	-
0.6167	140	2.098	-
0.6608	150	2.0931	0.9054
0.7048	160	2.0954	-
0.7489	170	2.0882	-
0.7930	180	2.0926	-
0.8370	190	2.1139	-
0.8811	200	2.1151	0.8745
0.9251	210	2.1033	-
0.9692	220	2.1014	-
1.0132	230	2.0139	-
1.0573	240	2.0408	-
1.1013	250	2.0257	0.9039
1.1454	260	2.0401	-
1.1894	270	2.0189	-
1.2335	280	2.0521	-
1.2775	290	2.055	-
1.3216	300	2.0407	0.9321
1.3656	310	2.0252	-
1.4097	320	2.0126	-
1.4537	330	2.0431	-
1.4978	340	2.0293	-
1.5419	350	2.042	0.9105
1.5859	360	2.0557	-
1.6300	370	2.0481	-
1.6740	380	2.0169	-
1.7181	390	2.0402	-
1.7621	400	2.0376	0.8873
1.8062	410	2.045	-
1.8502	420	1.9934	-
1.8943	430	2.0335	-
1.9383	440	2.0278	-
1.9824	450	2.0313	0.8658

Framework Versions

Python: 3.10.14
Sentence Transformers: 3.4.1
Transformers: 4.49.0
PyTorch: 2.6.0+cu124
Accelerate: 1.4.0
Datasets: 3.3.2
Tokenizers: 0.21.0

Citation

BibTeX

Sentence Transformers

@inproceedings{reimers-2019-sentence-bert,
    title = "Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks",
    author = "Reimers, Nils and Gurevych, Iryna",
    booktitle = "Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing",
    month = "11",
    year = "2019",
    publisher = "Association for Computational Linguistics",
    url = "https://arxiv.org/abs/1908.10084",
}

CachedMultipleNegativesRankingLoss

@misc{gao2021scaling,
    title={Scaling Deep Contrastive Learning Batch Size under Memory Limited Setup},
    author={Luyu Gao and Yunyi Zhang and Jiawei Han and Jamie Callan},
    year={2021},
    eprint={2101.06983},
    archivePrefix={arXiv},
    primaryClass={cs.LG}
}