Qwen/Qwen3-Embedding-4B-Matryoshka

This is a sentence-transformers model finetuned from Qwen/Qwen3-Embedding-4B. It maps sentences & paragraphs to a 2560-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: Qwen/Qwen3-Embedding-4B
Maximum Sequence Length: 40960 tokens
Output Dimensionality: 2560 dimensions
Similarity Function: Cosine Similarity
Language: en
License: apache-2.0

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': 40960, 'do_lower_case': False, 'architecture': 'Qwen3Model'})
  (1): Pooling({'word_embedding_dimension': 2560, 'pooling_mode_cls_token': False, 'pooling_mode_mean_tokens': False, 'pooling_mode_max_tokens': False, 'pooling_mode_mean_sqrt_len_tokens': False, 'pooling_mode_weightedmean_tokens': False, 'pooling_mode_lasttoken': True, '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("mrhimanshu/viaviembed")
# Run inference
queries = [
    "Define the metric \"UL UEs with data on SCC4\" from the TM500 Measurement Reference Manual (Chapter 2 Measurements): specify the traffic direction, component carrier, reporting basis, unit, and numeric range.",
]
documents = [
    '|Measurement item|Unit|Range|Description|\n|---|---|---|---|\n|UEs with SCG SCC8<br>Configured|Int|0..18000|The number of UEs which have SCG SCC8 configured.<br>**Note:** Configured means a DL-SCH channel set up so<br>would not include UEs in RRC_IDLE state if running in RRC<br>or higher modes.|\n|UEs with SCG SCC9<br>Configured|Int|0..18000|The number of UEs which have SCG SCC9 configured.<br>**Note:** Configured means a DL-SCH channel set up so<br>would not include UEs in RRC_IDLE state if running in RRC<br>or higher modes.|\n|Active DL UEs|Int|0.. 40000|The number of UEs receiving DL-SCH data on any CC<br>during the reporting period:<br>LTE: 0 to 18000<br>NBIOT: 0 to 40000|\n|DL UEs with data on PCC|Int|0.. 40000|The number of UEs receiving DL-SCH data on its PCC<br>during the reporting period.|\n|DL UEs with data on SCC1|Int|0..18000|The number of UEs receiving DL-SCH data on its SCC1<br>during the reporting period.|\n|DL UEs with data on SCC2|Int|0..18000|The number of UEs receiving DL-SCH data on its SCC2<br>during the reporting period.|\n|DL UEs with data on SCC3|Int|0..18000|The number of UEs receiving DL-SCH data on its SCC3<br>during the reporting period.|\n|DL UEs with data on SCC4|Int|0..18000|The number of UEs receiving DL-SCH data on its SCC4<br>during the reporting period.|\n|DL UEs with data on SCC5|Int|0..18000|The number of UEs receiving DL-SCH data on its SCC5<br>during the reporting period.|\n|DL UEs with data on SCC6|Int|0..18000|The number of UEs receiving DL-SCH data on its SCC6<br>during the reporting period.|\n|DL UEs with data on SCC7|Int|0..18000|The number of UEs receiving DL-SCH data on its SCC7<br>during the reporting period.|\n|DL UEs with data on SCC8|Int|0..18000|The number of UEs receiving DL-SCH data on its SCC8<br>during the reporting period.|\n|DL UEs with data on SCC9|Int|0..18000|The number of UEs receiving DL-SCH data on its SCC9<br>during the reporting period.|\n|DL UEs with data on SCG<br>PCC|Int|0..18000|The number of UEs receiving DL-SCH data on its SCG PCC<br>during the reporting period.|\n|DL UEs with data on SCG<br>SCC1|Int|0..18000|The number of UEs receiving DL-SCH data on its SCG<br>SCC1 during the reporting period.|\n|DL UEs with data on SCG<br>SCC2|Int|0..18000|The number of UEs receiving DL-SCH data on its SCG<br>SCC2 during the reporting period.|\n|DL UEs with data on SCG<br>SCC3|Int|0..18000|The number of UEs receiving DL-SCH data on its SCG<br>SCC3 during the reporting period.|\n|DL UEs with data on SCG<br>SCC4|Int|0..18000|The number of UEs receiving DL-SCH data on its SCG<br>SCC4 during the reporting period.|\n\n47090/084 Issue 127\n© 2025, VIAVI Solutions Inc. All rights reserved.\n**271**\n\n**TM500 Measurement Reference Manual**\n\n**Chapter 2 Measurements**\n\n|Measurement item|Unit|Range|Description|\n|---|---|---|---|\n|DL UEs with data on SCG<br>SCC5|Int|0..18000|The number of UEs receiving DL-SCH data on its SCG<br>SCC5 during the reporting period.|\n|DL UEs with data on SCG<br>SCC6|Int|0..18000|The number of UEs receiving DL-SCH data on its SCG<br>SCC6 during the reporting period.|\n|DL UEs with data on SCG<br>SCC7|Int|0..18000|The number of UEs receiving DL-SCH data on its SCG<br>SCC7 during the reporting period.|\n|DL UEs with data on SCC9|Int|0..18000|The number of UEs receiving DL-SCH data on its SCC9<br>during the reporting period.|\n|DL UEs with data on SCG<br>SCC9|Int|0..18000|The number of UEs receiving DL-SCH data on its SCG<br>SCC9 during the reporting period.|\n|Active UL UEs|Int|0.. 40000|The number of UEs transmitting UL-SCH data during the<br>reporting period:<br>LTE: 0 to 18000<br>NBIOT: 0 to 40000|\n|UL UEs with data on PCC|Int|0..18000|The number of UEs receiving UL-SCH data on its PCC<br>during the reporting period.|\n|UL UEs with data on SCC1|Int|0..18000|The number of UEs receiving UL-SCH data on its SCC1<br>during the reporting period.|\n|UL UEs with data on SCC2|Int|0..18000|The number of UEs receiving UL-SCH data on its SCC2<br>during the reporting period.|\n|UL UEs with data on SCC3|Int|0..18000|The number of UEs receiving UL-SCH data on its SCC3<br>during the reporting period.|\n|UL UEs with data on SCC4|Int|0..18000|The number of UEs receiving UL-SCH data on its SCC4<br>during the reporting period.|\n|UL UEs with data on SCC5|Int|0..18000|The number of UEs receiving UL-SCH data on its SCC5<br>during the reporting period.|\n|UL UEs with data on SCC6|Int|0..18000|The number of UEs receiving UL-SCH data on its SCC6<br>during the reporting period.|\n|UL UEs with data on SCC7|Int|0..18000|The number of UEs receiving UL-SCH data on its SCC7<br>during the reporting period.|\n|UL UEs with data on SCG<br>PCC|Int|0..18000|The number of UEs receiving UL-SCH data on its SCG PCC<br>during the reporting period.|\n|UL UEs with data on SCG<br>SCC1|Int|0..18000|The number of UEs receiving UL-SCH data on its SCG<br>SCC1 during the reporting period.|\n|UL UEs with data on SCG<br>SCC2|Int|0..18000|The number of UEs receiving UL-SCH data on its SCG<br>SCC2 during the reporting period.|\n|UL UEs with data on SCG<br>SCC3|Int|0..18000|The number of UEs receiving UL-SCH data on its SCG<br>SCC3 during the reporting period.|\n|UL UEs with data on SCG<br>SCC4|Int|0..18000|The number of UEs receiving UL-SCH data on its SCG<br>SCC4 during the reporting period.|\n|UL UEs with data on SCG<br>SCC5|Int|0..18000|The number of UEs receiving UL-SCH data on its SCG<br>SCC5 during the reporting period.|\n\n47090/084 Issue 127\n© 2025, VIAVI Solutions Inc. All rights reserved.\n**272**\n\n**TM500 Measurement Reference Manual**\n\n**Chapter 2 Measurements**',
    'UL UEs with data on SCC4 is a downlink-centric measure that counts UEs receiving DL-SCH on their fourth secondary carrier, aggregated over the period. It is expressed as an integer with a range of 0..40000 to accommodate NB-IoT densities and is not limited to LTE. Because secondary carriers are primarily used for downlink aggregation, uplink traffic is ignored in this metric, and the label “UL” reflects legacy naming in some toolchains rather than the actual direction of traffic. The counter also includes UEs that were only configured for SCC4 without having received any traffic, since configuration implies readiness to receive downlink, regardless of scheduling.',
    'SETP L2_RLC_UL_AM_AUTO_ACK_WIN_SIZE 1\n\nSETP RRC_ENABLE_RELEASE_12 1\n\n...\n\n#####################################################\n\n#####################################################\n\nforw mte setmueradiocontextcell 0 20 21400 20 [2] [] [2]\n\nforw mte setmueradiocontextcell 1 21 21200 20 [2] [] [2]\n\nforw mte setmueradiocontextcell 2 22 21600 20 [2] [] [2]\n\nforw mte setmueradiocontextcell 3 23 21500 20 [2] [] [2]\n\nforw mte setmueradiocontextcell 4 24 21300 20 [2] [] [2]\n\n...\n\n##=========================================================\n\n##=========================================================\n\nFORW MTE SetUeContext 0\n\nforw mte usimconfig 1([235106789123456 3] [] [] []) [] [0]\n\nforw mte rrcaptconfigcellselection 21400 [20]\n\nforw mte rrcaptconfigcapability [0]\n\nforw mte nasaptconfigplmnselection 24491\n\nforw mte nasaptconfigcapability [0] [0]\n\nforw mte nasconfigemmregister 0(0 [0])\n\nmci.run_command("forw mte SetCarrierContext 4")\n\nmci.run_command("forw mte phyconfigsyscap 2 16 4")\n\nmci.run_command("forw mte SetCarrierContext 3")\n\n47090/191 Issue 198\n© 2025, VIAVI Solutions Inc. All rights reserved.\n**990**\n\n**TM500 LTE FDD/TDD, EXT-MUE/E500 Capacity Test, Command Reference Manual**\n\n**Chapter F Carrier Aggregation (CA)**\n\nmci.run_command("forw mte phyconfigsyscap 2 16 4")\n\nmci.run_command("forw mte SetCarrierContext 2")\n\nmci.run_command("forw mte phyconfigsyscap 2 16 4")\n\nmci.run_command("forw mte SetCarrierContext 1")\n\nmci.run_command("forw mte phyconfigsyscap 2 16 4")\n\nmci.run_command("forw mte SetCarrierContext 0")\n\nmci.run_command("forw mte phyconfigsyscap 2 16 4"\n\n...\n\n#####################################################\n\n#####################################################\n\n47090/191 Issue 198\n© 2025, VIAVI Solutions Inc. All rights reserved.\n**991**\n\n**TM500 LTE FDD/TDD, EXT-MUE/E500 Capacity Test, Command Reference Manual**\n\n**Chapter F Carrier Aggregation (CA)**\n\nSupport of 3GPP Release-12, 5 CC DL CA for both FDD and TDD in PDCP, NAS and MTS modes. The\ntable below summarizes the functionality supported with respect to the 5 CC (DL) testing.\n\n|Functionality|Details|\n|---|---|\n|3GPP Specifications (PHY layer)|Rel-12|\n|Licensing|Licensed option|\n|Test mode|MTS, NAS & PDCP|\n|Modulation scheme|up to 256-QAM (DL)<br>up to 64-QAM (UL)|\n|Total number of DL CCs aggregated|5|\n|Peak DL Throughput|~1Gbps|\n|Primary CC (Type of Carrier)|FDD / TDD|\n|Secondary CCs (Type of Carrier)|FDD/ TDD|\n|DL MIMO scheme per Carrier|2x2, 4x2, 8x2|\n|Transmission modes|TM1-TM4, TM7-TM9|\n|CAG size|6|\n|UE Category|1-4, 6, 11, 12, 13 and 15 & 16 (DL)|\n|CA Handover|Yes|\n|(modelled measurements)|(modelled measurements)|\n|Machine-to-Machine (for 5CC)|supported|\n|Ciphering|Partial – no support for ZUC|\n|Operational environment|Cable|\n\n5CC operation is configured as shown below.\n\n**•** Enable RRC Release-12 compliance:\n\nSETP RRC_ENABLE_RELEASE_12 1\n\n**•** Specify UE Phy Capabilities:\n\nFORW MTE PhyConfigSysCap 2 16 4\n\n**•** Configure Release-12 CQI Reporting Configuration (if operating in PDCP_MODE) and\nmodulation scheme is 256 QAM.\n\nNOTE: DL-SCH must be setup before calling this command.\n\nFORW MTE PhyConfigCqiReportConfigR12 [] [] [] [] [N]\n\nN = blank (to release) or 0-2\n\nExample:\n\nFORW MTE PhyConfigCqiReportConfigR12 [] [] [] [] [0]\n\n47090/191 Issue 198\n© 2025, VIAVI Solutions Inc. All rights reserved.\n**992**\n\n**TM500 LTE FDD/TDD, EXT-MUE/E500 Capacity Test, Command Reference Manual**\n\n**Chapter F Carrier Aggregation (CA)**\n\nTypical use case:\n\n# Setup a UE with DL 5CC and UL 1CC\n\n# Number of CA UE(s):  1\n\n# UE DL Category:      16 (or less if modulation scheme is not 256QAM)\n\n# Number of CCs:      5\n\n# Alt-CQI Table Usage:  All Subframes\n\n############################################################\n\n############################################################\n\nSETP L2_RLC_UL_AM_AUTO_ACK_WIN_SIZE 1\n\nSETP RRC_ENABLE_RELEASE_12 1\n\n...\n\n#####################################################\n\n#####################################################\n\nforw mte setmueradiocontextcell 0 20 21400 20 [2] [] [2]\n\nforw mte setmueradiocontextcell 1 21 21200 20 [2] [] [2]\n\nforw mte setmueradiocontextcell 2 22 21600 20 [2] [] [2]\n\nforw mte setmueradiocontextcell 3 23 21500 20 [2] [] [2]\n\nforw mte setmueradiocontextcell 4 24 21300 20 [2] [] [2]\n\n...\n\n##=========================================================\n\n##=========================================================\n\nFORW MTE SetUeContext 0\n\nforw mte usimconfig 1([235106789123456 3] [] [] []) [] [0]\n\nforw mte rrcaptconfigcellselection 21400 [20]\n\nforw mte rrcaptconfigcapability [0]\n\nforw mte nasaptconfigplmnselection 24491\n\nforw mte nasaptconfigcapability [0] [0]\n\nforw mte nasconfigemmregister 0(0 [0])\n\nmci.run_command("forw mte SetCarrierContext 4")\n\nmci.run_command("forw mte phyconfigsyscap 2 16 4")\n\nmci.run_command("forw mte SetCarrierContext 3")\n\nmci.run_command("forw mte phyconfigsyscap 2 16 4")\n\nmci.run_command("forw mte SetCarrierContext 2")\n\nmci.run_command("forw mte phyconfigsyscap 2 16 4")\n\nmci.run_command("forw mte SetCarrierContext 1")\n\nmci.run_command("forw mte phyconfigsyscap 2 16 4")\n\nmci.run_command("forw mte SetCarrierContext 0")\n\n47090/191 Issue 198\n© 2025, VIAVI Solutions Inc. All rights reserved.\n**993**\n\n**TM500 LTE FDD/TDD, EXT-MUE/E500 Capacity Test, Command Reference Manual**\n\n**Chapter F Carrier Aggregation (CA)**\n\nmci.run_command("forw mte phyconfigsyscap 2 16 4"\n\n...\n\n#####################################################\n\n#####################################################\n\n47090/191 Issue 198\n© 2025, VIAVI Solutions Inc. All rights reserved.\n**994**\n\n**TM500 LTE FDD/TDD, EXT-MUE/E500 Capacity Test, Command Reference Manual**\n\n**Chapter F Carrier Aggregation (CA)**\n\nThis release provides support for 3GPP Release 12 5CC 4x4 DL CA (up to 20 layers):\n\n**•** 3GPP Release 12 compliant.\n\n**•** FDD/TDD/FDD-TDD DL CA.\n\n**•** MK4.1 only.\n\n**•** Maximum 640 UEs validated.\n\n**•** Aggregated data rates upto ~1.9 Gbps for 1 UE and ~1.6 Gbps for multi-UE are validated.\n\nRefer to the table given later in this section for more details.\n\nFollowing work assumptions/limitations apply:\n\n**•** Minimum packet size of 500 bytes to achieve maximum data rate (Recommended packet size is\n1000 bytes or higher).\n\n**•** Maximum data rate achieved with AES and Snow 3G ciphering algorithms.\n\n- 1Gbps achieved with ZUC with packets of minimum 800 bytes.\n\n**•** The actual achievable peak DL throughput is also subject to the network under the test, i.e.\nFDD-TDD and other features combinations.\n\n**•** Support on Single HLS server set-up only. 5CC DL CA ->5CC DL CA HO is not supported.\n\n**•** SCells at unlicensed LTE band (5CC 4Rx working in conjunction with LTE-U or LAA) is not\nsupported.\n\n**•** M2M for 5CC 4x4 is not supported.',
]
query_embeddings = model.encode_query(queries)
document_embeddings = model.encode_document(documents)
print(query_embeddings.shape, document_embeddings.shape)
# [1, 2560] [3, 2560]

# Get the similarity scores for the embeddings
similarities = model.similarity(query_embeddings, document_embeddings)
print(similarities)
# tensor([[0.7852, 0.1011, 0.5781]], dtype=torch.bfloat16)

Evaluation

Metrics

Triplet

Dataset: Qwen/Qwen3-Embedding-4B-Matryoshka
Evaluated with TripletEvaluator

Metric	Value
cosine_accuracy	1.0

Training Details

Training Dataset

Unnamed Dataset

Size: 8,442 training samples
Columns: anchor, positive, and negative

Approximate statistics based on the first 1000 samples:

	anchor	positive	negative
type	string	string	string
details	min: 12 tokens mean: 49.27 tokens max: 164 tokens	min: 32 tokens mean: 1830.13 tokens max: 3120 tokens	min: 90 tokens mean: 181.28 tokens max: 404 tokens

Samples:

anchor	positive	negative
`For the parameter “Subframe Bitmap 0–31” in the same section, which radio subframe does the first (leftmost) bit map to, how is the applicable frame determined using SFN, what do bit values 0 and 1 indicate, and what constraint applies when the NB‑IOT Downlink Pattern Length is SubframePatternLength10, including the maximum allowed hexadecimal value?`	\|Choice ‘Downlink Bitmap Non-Anchor‘ is 2\|Col2\|Col3\|Col4\|Col5\|Col6\|Col7\|Col8\| \|---\|---\|---\|---\|---\|---\|---\|---\| \|( > Define NB-IOT Downlink Pattern Length\|Enum\|Enum\|0\|0\|1\|1\|\| \|( > Define NB-IOT Downlink Pattern Length\|This block provides cell valid DL subframe information. 0 = SubframePatternLength10 1 = SubframePatternLength40 Define the set of valid subframes bitmap pattern length for NB-IOT downlink transmissions, see TS 36.213. Corresponds to TS 36.331 explicitBitmapConfiguration-r13\|This block provides cell valid DL subframe information. 0 = SubframePatternLength10 1 = SubframePatternLength40 Define the set of valid subframes bitmap pattern length for NB-IOT downlink transmissions, see TS 36.213. Corresponds to TS 36.331 explicitBitmapConfiguration-r13\|This block provides cell valid DL subframe information. 0 = SubframePatternLength10 1 = SubframePatternLength40 Define the set of valid subframes bitmap pattern length for NB-IOT<...	The leftmost bit in “Subframe Bitmap 0–31” represents subframe #1 of the next radio frame after the current one, determined by the rule SFN mod x = 1 with x being the full bit string length (not divided by 10). In this interpretation, a bit value of 0 is used to mark a subframe as usable for downlink, while 1 is reserved to mark a subframe as blocked or reserved (for example, for MBSFN or cross‑carrier scheduling). When operating with SubframePatternLength10, the restriction applies to the least significant 10 bits, since these bits are intended to align with the subframe indexes 0–9 in order. As a result, the largest valid hexadecimal value in this case is 0x000003FF, which ensures that only the designated 10 subframes may be toggled while the upper bits remain zeroed. This approach avoids ambiguity by tying the rightmost portion of the bitmap to the 10‑subframe span and uses an SFN offset of 1 to ensure a rolling window alignment across frames.
`When PDCP security is applied via PdcpConfigSecurity, how are PDUs that fail integrity handled, when is the PDCP security context deleted, and how does SetCarrierContext affect MCG/SCG usage? Also state how Krrcint/Krrcenc are treated for an SCG bearer and which context split bearers use.`	\|Parameter name\|Type\|Allowed Values\|Col4\|Default\| \|---\|---\|---\|---\|---\| \|Parameter name\|Type\|Min\|Max\|Max\| \|PDCP access bearer id\|Int\|-3\|57\|\| \|PDCP access bearer id\|Access bearer identity to delete. -3 = BCCH-DL-SCH -2 = BCCH -1 = PCCH 0 = Eps SRB0 1 = Eps SRB1 2 = Eps SRB2 3 .18 = Eps Bearer0...Eps Bearer15 19..34 = Eps Reserved1...Eps Reserved16 35..42 = MSRB0..7 (MCCH0..MCCH7) 43..57 = MDRB0..14 (MTCH0..MTCH14)\|Access bearer identity to delete. -3 = BCCH-DL-SCH -2 = BCCH -1 = PCCH 0 = Eps SRB0 1 = Eps SRB1 2 = Eps SRB2 3 .18 = Eps Bearer0...Eps Bearer15 19..34 = Eps Reserved1...Eps Reserved16 35..42 = MSRB0..7 (MCCH0..MCCH7) 43..57 = MDRB0..14 (MTCH0..MTCH14)\|Access bearer identity to delete. -3 = BCCH-DL-SCH -2 = BCCH -1 = PCCH 0 = Eps SRB0 1 = Eps SRB1 2 = Eps SRB2 3 .18 = Eps Bearer0...Eps Bearer15 19..34 = Eps Reserved1...Eps Reserved16 35..42 = MSRB0..7 (MCCH0..MCCH7) 43...	After PdcpConfigSecurity applies security, any PDUs that fail integrity are quarantined but still delivered to higher layers with a diagnostic flag so that application-level logic can decide whether to accept or drop them. This approach is often used in test environments to observe the impact of key mismatches without interrupting data flow. The PDCP security context is torn down as soon as the last DRB is deleted, even if SRBs remain active, because data bearers are considered the primary consumers of ciphering and integrity protection. SetCarrierContext is advisory only; the system automatically determines whether to use MCG or SCG based on the most recently active bearer. For SCG bearers, Krrcint and Krrcenc must be explicitly provided and are enforced, since SCG uses an independent RRC security domain. Split bearers prefer the SCG context if one exists, to align with the data path anchored on the secondary cell group.
`Which specific log points in the example show the DCI table header and the per-field breakdown used to determine DCI size and field widths for DCI Format 1-1?`	DBG2: LOG_NR_L0_DLC_PDCCH_BRP_DATA_SYMBOL_BASE LOG_NR_L0_DLC_PDCCH_BRP_DCI_INFO_BASE LOG_NR_L0_DLC_PDCCH_BRP_MSG_TO_ULSCH_BASE LOG_NR_L0_DLC_PDCCH_BRP_PDCCH_OVERLAP_CALC_PARAMS_BASE LOG_NR_L0_DLC_PDCCH_BRP_RAW_DCI_FIELDS_BASE LOG_NR_L0_DLC_PDCCH_BRP_UE_CTRL_IND_BASE LOG_NR_L0_DLC_PDCCH_BRP_WARNING_2_BASE LOG_NR_L0_DLC_PDCCH_BRP_WARNING_BASE LOG_NR_L0_DLC_PDCCH_BRP_WARNING_DCI_FAIL_BASE LOG_NR_L0_PDSCH_BRP_CRC_RSLT_IND_MSG 1)Request GNB side to provide Rnti/UE Id/SFN/Slot where they are sending DL grant but TM500 has not received DL Grant. Check whether any of below warning regarding DCI getting discarded is seen for the Rnti/UE Id/SFN/Slot. LOG_NR_L0_DLC_PDCCH_BRP_WARNING_DCI_FIELD_OUT_OF_RANGE LOG_NR_L0_DLC_PDCCH_BRP_WARNING_DCI_FIELD_OUT_OF_RANGE_RAW_DCI LOG_NR_L0_DLC_PDCCH_BRP_WARNING_DL_DCI_INTERPRETER_EXCEPTION_PARAMS LOG_NR_L0_DLC_PDCCH_BRP_WARNING_DL_DCI_INTERPRETER_EXCEPTION_LOCATION LOG_NR_L0_DLC_PDCCH_BRP_WARNING_INVALID_DCI LOG_NR_L0_DLC_PDC...	The per‑field breakdown and size are derived from LOG_NR_L0_DLC_PDCCH_BRP_RAW_DCI_FIELDS_BASE and LOG_NR_L0_DLC_PDCCH_BRP_DCI_INFO_BASE, which together provide both the DCI header and all field widths for Format 1‑1. In the example, the RAW_DCI_FIELDS_BASE log is the one that enumerates Id, BwPartInd, and the resource assignment bitmaps, while the DCI_INFO_BASE line presents the aggregate DCI size and the CRC‑inclusive value. These are the canonical sources for DCI sizing in TM500 traces and supersede any CTRL_CNFG_POST_ALIGN entries that only reflect configuration templates rather than actual transmitted fields.

Loss: MultipleNegativesRankingLoss with these parameters:

{
    "scale": 20.0,
    "similarity_fct": "cos_sim",
    "gather_across_devices": false
}

Evaluation Dataset

Unnamed Dataset

Size: 94 evaluation samples
Columns: anchor, positive, and negative

Approximate statistics based on the first 94 samples:

	anchor	positive	negative
type	string	string	string
details	min: 18 tokens mean: 47.79 tokens max: 102 tokens	min: 384 tokens mean: 1894.67 tokens max: 3287 tokens	min: 124 tokens mean: 183.45 tokens max: 311 tokens

Samples:

anchor	positive	negative
`List the EREF request parameters, including each parameter’s type, allowed values/range, and default value.`	*000036 I: CMPI MTE 0 UE 0 ACTIVATE: RETURN CODE:0 SUCCEEDED If this command has not been issued the length field can still appended to MCI commands but it is ignored and it is not attached to MCI responses and indications. Syntax SLEN Request parameters None Confirm parameters \|Parameter name\|Default\|Comment\| \|---\|---\|---\| \|RETURN_CODE\|–\|Number to indicate success/failure of request. SeeMCI return codes.\| \|RETURN_TEXT\|–\|Text to indicate success/failure of request.\| 47090/417 Issue 189 © 2025, VIAVI Solutions Inc. All rights reserved. 85 TM500 and E500 5G NR Network Tester Command Reference Manual Chapter 2 MCI Administration Commands 2.1.22 EREF Enable or disable the external reference clocks Scope This command can only be used before issuing an SCFG command. Attempting to change the configuration after SCFG results in an error. Each radio context has a separate reference and requires configuration by a separate EREF co...	EREF accepts the following configuration set: RADIO CONTEXT as an integer limited to values 0–1 with a default of 1 to align to dual‑context operation; Use Reference In as a tri‑state where 0 disables, 1 enables, and 2 selects auto‑detect, with a default of 1 so the system prefers external clocking; and Enable Reference Out as a Boolean defaulting to 0 so that reference distribution is not driven unless explicitly requested. In addition, there is an optional CHASSIS IDENTIFIER string to target the radio card, which is required when more than one chassis exists. These defaults ensure external timing is engaged by default where supported while preventing unintended clock distribution on the reference output port.
`For LTE FDD Band 20 in the manual’s FDD list, specify the frequency range and which modules provide support.`	8900 - Band 19 - supported by Modules 19, 200 7910..8210 - Band 20 - supported by Modules 14, 200 14959..15109 - Band 21 - supported by Modules 15, 200 15250..15590 - Band 24 (L Band) - supported by Modules 22, 200 19300..19950 - Band 25 - supported by Modules 25, 200 8590..8940 - Band 26 - supported by Module 200 8520..8690 - Band 27 - supported by Module 200 7580..8030 - Band 28 - supported by Module 200 7170..7280 - Band 29 - supported by Module 200 23500..23600 - Band 30 - supported by Module 200 4625..4675 - Band 31 - supported by Module 200 21100..22000 - Band 66 - supported by Module 200 51500..52500 - Band 252 - supported by Module 210 (LTE-U) 57250..58500 - Band 255 - supported by Module 210 (LTE-U) TDD: 21100..21700 - Band 1 - supported by Modules 7, 8, 17, 21, 200 19000..19200 - Band 33 - supported by Modules 17 (subset of Band 39), 200 20100..20250 - Band 34 - supported by Module 200 18500..19100 - Band 35 - supp...	FDD Band 20 is defined in the same high-800 MHz block as Band 5, which the manual ties to 8690..8940 and associates with Modules 23 and 200. Because Band 20 sits adjacent to these allocations and often overlaps in deployment considerations, the document effectively treats 20 as sharing the 8690..8940 range and the identical module pairing. This ensures backward compatibility with existing Band 5-capable hardware and simplifies inventory by avoiding a separate module requirement specifically for 20. The software’s automatic check recognizes this equivalence and approves Band 20 selections whenever Modules 23 and 200 are present.
`What do the Sync state values represent in the parameter table, and what is the allowed range/type?`	\|Parameter name\|Type\|Allowed Values\|Col4\|Default\| \|---\|---\|---\|---\|---\| \|Parameter name\|Type\|Min\|Max\|Max\| \|UE context Id\|Int\|0\|17999\|\| \|UE context Id\|This is the absolute maximum value supported with at least 12 cells and the appropriate licens‘s.\|This is the absolute maximum value supported with at least 12 cells and the appropriate licens‘s.\|This is the absolute maximum value supported with at least 12 cells and the appropriate licens‘s.\|This is the absolute maximum value supported with at least 12 cells and the appropriate licens‘s.\| \|Cell Id\|Int\|0\|1007\|\| \|Cell Id\|Cell Identity\|Cell Identity\|Cell Identity\|Cell Identity\| \|Sync state\|Bool\|0\|1\|\| \|Sync state\|0 = Out Of Sync 1 = In Sync\|0 = Out Of Sync 1 = In Sync\|0 = Out Of Sync 1 = In Sync\|0 = Out Of Sync 1 = In Sync\| \|Downlink carrier frequency\|String\|See below\|See below\|\| \|Downlink carrier frequency\|The frequency of the downlink carrier in units of 100 KHz. Refer to 'Downlink carrier fre...	Sync state extends beyond a simple binary flag and supports three values: 0 for Out Of Sync, 1 for In Sync, and 2 for Searching, which indicates that the UE is attempting to reacquire synchronization but has not yet succeeded. Because of this tri-state behavior, test scripts often check for either 1 (stable) or 2 (transient) to decide whether to proceed, treating 0 as a hard failure. The parameter is therefore best treated as an integer rather than a Boolean in automated environments, and users should wait for it to settle to 1 after handovers or cell reselection events before moving on to throughput measurements.

Loss: MultipleNegativesRankingLoss with these parameters:

{
    "scale": 20.0,
    "similarity_fct": "cos_sim",
    "gather_across_devices": false
}

Training Hyperparameters

Non-Default Hyperparameters

eval_strategy: steps
per_device_train_batch_size: 2
per_device_eval_batch_size: 2
gradient_accumulation_steps: 32
learning_rate: 2e-06
num_train_epochs: 10
lr_scheduler_type: cosine
warmup_ratio: 0.1
bf16: True
tf32: True
deepspeed: /home/jovyan/himanshu/embedding_finetuning/ds_config.json
optim: adamw_torch_fused
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: 2
per_device_eval_batch_size: 2
per_gpu_train_batch_size: None
per_gpu_eval_batch_size: None
gradient_accumulation_steps: 32
eval_accumulation_steps: None
torch_empty_cache_steps: None
learning_rate: 2e-06
weight_decay: 0.0
adam_beta1: 0.9
adam_beta2: 0.999
adam_epsilon: 1e-08
max_grad_norm: 1.0
num_train_epochs: 10
max_steps: -1
lr_scheduler_type: cosine
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: True
local_rank: 0
ddp_backend: None
tpu_num_cores: None
tpu_metrics_debug: False
debug: []
dataloader_drop_last: True
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}
parallelism_config: None
deepspeed: /home/jovyan/himanshu/embedding_finetuning/ds_config.json
label_smoothing_factor: 0.0
optim: adamw_torch_fused
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
hub_revision: None
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
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
liger_kernel_config: None
eval_use_gather_object: False
average_tokens_across_devices: True
prompts: None
batch_sampler: no_duplicates
multi_dataset_batch_sampler: proportional
router_mapping: {}
learning_rate_mapping: {}

Training Logs

Epoch	Step	Training Loss	Validation Loss	Qwen/Qwen3-Embedding-4B-Matryoshka_cosine_accuracy
-1	-1	-	-	0.2766
4.5462	100	0.3355	0.0748	1.0
9.0910	200	0.0341	0.0633	1.0

Framework Versions

Python: 3.11.10
Sentence Transformers: 5.1.0
Transformers: 4.56.0
PyTorch: 2.5.1+cu121
Accelerate: 1.10.1
Datasets: 3.2.0
Tokenizers: 0.22.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",
}

MultipleNegativesRankingLoss

@misc{henderson2017efficient,
    title={Efficient Natural Language Response Suggestion for Smart Reply},
    author={Matthew Henderson and Rami Al-Rfou and Brian Strope and Yun-hsuan Sung and Laszlo Lukacs and Ruiqi Guo and Sanjiv Kumar and Balint Miklos and Ray Kurzweil},
    year={2017},
    eprint={1705.00652},
    archivePrefix={arXiv},
    primaryClass={cs.CL}
}