SentenceTransformer(
(0): Transformer({'max_seq_length': 512, 'do_lower_case': False}) with Transformer model: BertModel
(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})
)pip install -U sentence-transformers1from sentence_transformers import SentenceTransformer
2
3# Download from the 🤗 Hub
4model = SentenceTransformer("ML5562/MNLP_M3_document_encoder")
5# Run inference
6sentences = [
7 "Freshly graduated from EPFL, you have been hired as contractors for a successful and rapidly growing bank. The bank has been experiencing problems with their money management system recently, which is written in Scala, and so they hired the best and brightest young engineer they could find: you! The system had been working perfectly fine so far, they tell you. In the past days, due to an increased number of customers, they had to switch from a single-threaded sequential execution environment to a multi-threaded concurrent one, in which the threads may perform transactions concurrently. That's when problems started, your manager says... Here is the code responsible to withdraw money from the account from and transfer it to the account to, within the same bank: def transfer(from: Account, to: Account, amount: BigInt): Unit = { require(amount >= 0) val balanceFrom = from.balance if (balanceFrom >= amount) { from.balance = balanceFrom - amount val balanceTo = to.balance to.balance = balanceTo + amount } } For the bank, it is very important that the following two properties hold after any sequence of completed transfer transactions: The balance of an account never goes below 0. The total sum of money held by the bank is constant. For each of the proposed implementations of transfer below, check which of the two properties hold. Additionally, check if the system is vulnerable to deadlocks. Variant 1: def transfer1(from: Account, to: Account, amount: Long): Unit = { require(amount >= 0) val balanceFrom = from.balance if (balanceFrom >= amount) { from.synchronized { from.balance = balanceFrom - amount } to.synchronized { val balanceTo = to.balance to.balance = balanceTo + amount } } } Variant 2: def transfer2(from: Account, to: Account, amount: Long): Unit = { require(amount >= 0) from.synchronized { val balanceFrom = from.balance if (balanceFrom >= amount) { from.balance = balanceFrom - amount to.synchronized { val balanceTo = to.balance to.balance = balanceTo + amount } } } } Variant 3 object lock // Global object def transfer3(from: Account, to: Account, amount: Long): Unit = { require(amount >= 0) lock.synchronized { val balanceFrom = from.balance if (balanceFrom >= amount) { from.balance = balanceFrom - amount val balanceTo = to.balance to.balance = balanceTo + amount } } }",
8 "Let's analyze each of the three variants of the `transfer` function in terms of the two properties that must hold after any sequence of completed transfer transactionsâ\x80\x94the balance of an account never goes below 0, and the total sum of money held by the bank is constantâ\x80\x94as well as checking for potential deadlocks.\n\n### Variant 1\n```scala\ndef transfer1(from: Account, to: Account, amount: Long): Unit = {\n require(amount >= 0)\n val balanceFrom = from.balance\n if (balanceFrom >= amount) {\n from.synchronized {\n from.balance = balanceFrom - amount\n }\n to.synchronized {\n val balanceTo = to.balance\n to.balance = balanceTo + amount\n }\n }\n}\n```\n\n**Analysis:**\n- **Property 1 (Balance never goes below 0):** This property is maintained because the balance is checked before any modification. However, since `from.synchronized` and `to.synchronized` are called separately, there can be a race condition. If two threads are transferring money between the same accounts, both threads can check the balance before either one updates it, leading to a situation where both might proceed to deduct from the same account.\n \n- **Property 2 (Total sum of money is constant):** This property can be violated. Consider two threads, T1 and T2, executing the transfer concurrently. If T1 checks the balance and finds it sufficient, it proceeds to deduct the amount while T2 does the same. As a result, both transfers could succeed and the total money held by the bank could increase.\n\n- **Deadlocks:** This implementation is not susceptible to deadlocks because the locks are acquired in a non-nested manner (first on `from`, then on `to`), and there are no circular dependencies.\n\n### Variant 2\n```scala\ndef transfer2(from: Account, to: Account, amount: Long): Unit = {\n require(amount >= 0)\n from.synchronized {\n val balanceFrom = from.balance\n if (balanceFrom >= amount) {\n from.balance = balanceFrom - amount\n to.synchronized {\n val balanceTo = to.balance\n to.balance = balanceTo + amount\n }\n }\n }\n}\n```\n\n**Analysis:**\n- **Property 1 (Balance never goes below 0):** This property is maintained. The check for balance occurs inside the synchronized block for `from`, ensuring that no other thread can modify the balance of `from` while the check is made and before the deduction occurs.\n\n- **Property 2 (Total sum of money is constant):** This property is also maintained. The operation is atomic concerning `from`, and since `to` is only modified after confirming the balance of `from`, no money is lost or created.\n\n- **Deadlocks:** This implementation is vulnerable to deadlocks. If one thread locks `from` and another thread locks `to`, and they try to acquire each other's locks, a deadlock can occur.\n\n### Variant 3\n```scala\nobject lock // Global object\ndef transfer3(from: Account, to: Account, amount: Long): Unit = {\n require(amount >= 0)\n lock.synchronized {\n val balanceFrom = from.balance\n if (balanceFrom >= amount) {\n from.balance = balanceFrom - amount\n val balanceTo = to.balance\n to.balance = balanceTo + amount\n }\n }\n}\n```\n\n**Analysis:**\n- **Property 1 (Balance never goes below 0):** This property is maintained. The balance check occurs before any modifications under a synchronized block, preventing any concurrent modifications that could lead to a negative balance.\n\n- **Property 2 (Total sum of money is constant):** This property is also maintained. The total amount of money in the system does not change since the operations are enclosed in a synchronized block.\n\n- **Deadlocks:** This implementation is not susceptible to deadlocks since there is a single global lock that prevents any other thread from entering the critical section until the current operation completes.\n\n### Summary\n- **Variant 1:** Violates property 2; not deadlock-prone.\n- **Variant 2:** Both properties are maintained; deadlock-prone.\n- **Variant 3:** Both properties are maintained; not deadlock-prone but not parallelizable for different accounts.\n\nGiven the requirements of a bank system, **Variant 2** is the most robust in terms of ensuring that the properties hold, but it needs to be modified to avoid deadlocks (for example, by establishing a global order for acquiring locks). **Variant 3** is safe but sacrifices parallel execution efficiency.",
9 "Let's analyze each variant of the `transfer` function to determine whether they maintain the two properties (non-negative balance and constant total sum) and whether they are prone to deadlocks.\n\n### Properties Check:\n\n1. **The balance of an account never goes below 0.**\n2. **The total sum of money held by the bank is constant.**\n\n### Variant 1:\n```scala\ndef transfer1(from: Account, to: Account, amount: Long): Unit = {\n require(amount >= 0)\n val balanceFrom = from.balance\n if (balanceFrom >= amount) {\n from.synchronized {\n from.balance = balanceFrom - amount\n }\n to.synchronized {\n val balanceTo = to.balance\n to.balance = balanceTo + amount\n }\n }\n}\n```\n\n- **Non-negative Balance:** This implementation checks if `balanceFrom >= amount` before making any changes. It ensures that the withdrawal will not cause the account to go negative.\n- **Total Sum Constant:** The total sum is preserved because the amount is deducted from `from` and added to `to`.\n- **Deadlock Vulnerability:** Yes, this implementation is vulnerable to deadlocks. If two threads try to transfer money between the same two accounts in opposite directions, they can end up waiting on each other indefinitely.\n\n### Variant 2:\n```scala\ndef transfer2(from: Account, to: Account, amount: Long): Unit = {\n require(amount >= 0)\n from.synchronized {\n val balanceFrom = from.balance\n if (balanceFrom >= amount) {\n from.balance = balanceFrom - amount\n to.synchronized {\n val balanceTo = to.balance\n to.balance = balanceTo + amount\n }\n }\n }\n}\n```\n\n- **Non-negative Balance:** The balance check is performed before any withdrawal is made, ensuring that the account will not go negative.\n- **Total Sum Constant:** The total amount remains unchanged as the amount is deducted from `from` and added to `to`.\n- **Deadlock Vulnerability:** This implementation is also vulnerable to deadlocks for the same reasons as Variant 1. If two threads try to transfer money between two accounts in opposite directions, they could wait indefinitely.\n\n### Variant 3:\n```scala\nobject lock // Global object\ndef transfer3(from: Account, to: Account, amount: Long): Unit = {\n require(amount >= 0)\n lock.synchronized {\n val balanceFrom = from.balance\n if (balanceFrom >= amount) {\n from.balance = balanceFrom - amount\n val balanceTo = to.balance\n to.balance = balanceTo + amount\n }\n }\n}\n```\n\n- **Non-negative Balance:** Similar to the previous variants, this implementation checks that `balanceFrom >= amount` before any withdrawal, ensuring no account goes negative.\n- **Total Sum Constant:** The total balance remains the same as the amount is properly transferred between accounts.\n- **Deadlock Vulnerability:** This implementation is not prone to deadlocks. Since it uses a single global lock, only one thread can execute a transfer at a time, preventing any circular wait conditions.\n\n### Summary:\n- **Variant 1:** \n - Non-negative balance: Yes\n - Total sum constant: Yes\n - Deadlock: Yes\n\n- **Variant 2:** \n - Non-negative balance: Yes\n - Total sum constant: Yes\n - Deadlock: Yes\n\n- **Variant 3:** \n - Non-negative balance: Yes\n - Total sum constant: Yes\n - Deadlock: No\n\n### Conclusion:\nTo ensure proper functioning in a concurrent environment, **Variant 3** is the only implementation that guarantees no deadlocks while still maintaining the required properties of the banking system. Variants 1 and 2 should be avoided due to their vulnerability to deadlocks.",
10]
11embeddings = model.encode(sentences)
12print(embeddings.shape)
13# [3, 768]
14
15# Get the similarity scores for the embeddings
16similarities = model.similarity(embeddings, embeddings)
17print(similarities.shape)
18# [3, 3]val-evalTripletEvaluator| Metric | Value |
|---|---|
| cosine_accuracy | 0.5831 |
sentence_0, sentence_1, and sentence_2| sentence_0 | sentence_1 | sentence_2 | |
|---|---|---|---|
| type | string | string | string |
| details |
|
|
|
| sentence_0 | sentence_1 | sentence_2 |
|---|---|---|
You are given the following collection of premises:[object Object]If I go to the museum, it either rains or snows.[object Object]I went to the museum on Saturday or I went to the museum on Sunday.[object Object]It did not rain and it did not snow on Saturday.[object Object]It did not rain on Sunday.[object Object]Which conclusions can be drawn from these premises ? (more than one answer can be correct) | To analyze the premises you've provided and draw valid conclusions, let's break them down systematically.[object Object][object Object]1. [object Object]:[object Object] [object Object] a. [object Object]: "If I go to the museum, it either rains or snows." [object Object] - This is a conditional statement indicating that visiting the museum is accompanied by at least one of two weather conditions: rain or snow.[object Object][object Object] b. [object Object]: "I went to the museum on Saturday or I went to the museum on Sunday."[object Object] - This premise establishes that at least one of these two days must have involved a visit to the museum.[object Object][object Object] c. [object Object]: "It did not rain and it did not snow on Saturday."[object Object] - This explicitly states that the weather on Saturday was clear, meaning neither rain nor snow occurred.[object Object][object Object] d. [object Object]: "It did not rain on Sunday."[object Object] - This indicates that while we know it didn't rain on Sunday, we still lack information about whether it snowed on that day.[object Object][object Object]2. [object Object]:[object Object] [object Object] Now, let's evaluate the possible conclusions ba... | To address the premises presented, one must engage in a logical analysis. The first premise indicates that a visit to the museum necessitates either rain or snow. The second premise posits that I visited the museum either on Saturday or on Sunday. The third premise explicitly states that there was neither rain nor snow on Saturday. The fourth premise similarly confirms the absence of rain on Sunday.[object Object][object Object]Now, if we consider these premises collectively, we can deduce some insights. Since it did not rain or snow on Saturday, it logically follows that I could not have gone to the museum on that day, as the first premise would be violated. Therefore, the only remaining possibility for my visit to the museum must be Sunday.[object Object][object Object]However, since it also did not rain on Sunday, we again confront a contradiction with the first premise which stipulates that a visit to the museum requires either rain or snow. Hence, if I went to the museum on Sunday, it must have snowed, yet the premises state it did not... |
Let $\mathcal C_1$ be a linear code over $\mathbb F_3^n$, and let $\mathcal C_2$ be a linear code over $\mathbb F_2^n$. True or false: $\mathcal C_1 \cap \mathcal C_2$ is necessarily a linear code over $\mathbb F_3^n$. | To determine whether the intersection (\mathcal C_1 \cap \mathcal C_2) is necessarily a linear code over (\mathbb F_3^n), we will analyze the properties of linear codes and their intersections.[object Object][object Object]1. [object Object]: [object Object] - A linear code over a field (\mathbb F_q) is a subspace of (\mathbb F_q^n). This means that any linear combination of codewords in the code is also a codeword.[object Object][object Object]2. [object Object]:[object Object] - (\mathcal C_1) is a linear code over (\mathbb F_3^n), meaning its codewords are vectors in (\mathbb F_3^n).[object Object] - (\mathcal C_2) is a linear code over (\mathbb F_2^n), meaning its codewords are vectors in (\mathbb F_2^n).[object Object][object Object]3. [object Object]:[object Object] - The intersection (\mathcal C_1 \cap \mathcal C_2) consists of codewords that belong to both (\mathcal C_1) and (\mathcal C_2).[object Object][object Object]4. [object Object]:[object Object] - A codeword in (\mathcal C_1) is represented as a vector in (\mathbb F_3^n), while a c... | The statement is [object Object]. [object Object][object Object]To analyze this, we must consider the nature of the codes involved. The linear code $\mathcal{C}_1$ is defined over the field $\mathbb{F}_3$, meaning that its codewords are formed using coefficients from the field with three elements. On the other hand, $\mathcal{C}_2$ is defined over the field $\mathbb{F}_2$, which consists of two elements.[object Object][object Object]The intersection $\mathcal{C}_1 \cap \mathcal{C}_2$ consists of codewords that are common to both codes. However, the elements of $\mathcal{C}_1$ can take on values from ${0, 1, 2}$ (the elements of $\mathbb{F}_3$), while the elements of $\mathcal{C}_2$ can only take on values from ${0, 1}$ (the elements of $\mathbb{F}_2$). [object Object][object Object]This means that codewords in $\mathcal{C}_1$ that contain the element '2' cannot be part of $\mathcal{C}_2$, as '2' does not exist in $\mathbb{F}_2$. Consequently, the intersection may not retain the linearity properties necessary to be considered a linear code over $\mathbb{F}_3$, as it may ... |
Consider the (toy) grammar $G$ consisting of the following rules:[object Object]R1: S --> NP VP[object Object]R2: NP --> NN[object Object]R3: NP --> Det NN[object Object]R4: NN --> N[object Object]R5: NN --> NN NN[object Object]R6: NN --> NN PNP[object Object]R7: PNP --> Prep NP[object Object]R8: VP --> V[object Object]R9: VP --> Adv V[object Object]Precisely define the type of grammar G is corresponding to (for that, consider at least the following aspects: dependency-based vs. constituency-based, position in the Chomsky hierarchy, and CNF).[object Object]Justify your answer for each of the aspects you will be mentioning. | Let’s analyze the grammar ( G ) in detail, considering the specified aspects: dependency-based vs. constituency-based, position in the Chomsky hierarchy, and Chomsky Normal Form (CNF). [object Object][object Object]### 1. Dependency-based vs. Constituency-based[object Object][object Object][object Object][object Object]- [object Object] Focuses on the relationships between words, where the structure is determined by the dependencies and how words depend on each other.[object Object]- [object Object] Emphasizes how words group into larger units (constituents), creating hierarchical structures such as phrases and clauses.[object Object][object Object][object Object][object Object]The grammar ( G ) is [object Object]. This conclusion arises because:[object Object]- The grammar defines phrases (like Noun Phrases (NP) and Verb Phrases (VP)) that can be broken down into smaller components. For example, ( S \to NP VP ) indicates that a sentence (S) is composed of a noun phrase and a verb phrase, reflecting a hierarchical structure.[object Object]- The use of multiple non-terminal symbols (like NN, NP, ... | To classify the grammar ( G ) according to the specified aspects more comprehensively, let's re-evaluate the grammar's characteristics with a clear structure, ensuring that each aspect is thoroughly justified.[object Object][object Object]### 1. Dependency-based vs. Constituency-based[object Object][object Object][object Object]: [object Object][object Object][object Object][object Object]:[object Object]- [object Object]: Constituency-based grammars organize sentences into phrases (constituents) that can be recursively defined, which is a key characteristic of many natural languages.[object Object]- [object Object]: The production rules in grammar ( G ) demonstrate a clear hierarchical structure:[object Object] - The rule ( S \rightarrow NP \ VP ) signifies that a sentence (S) is composed of a noun phrase (NP) and a verb phrase (VP), which can further break down into smaller constituents.[object Object] - The rules for noun phrases (e.g., ( NP \rightarrow NN ) and ( NP \rightarrow Det \ NN )) show how constituents can be formed from other constituents, indicating a constituency-based structure.[object Object]- **Comp... |
TripletLoss with these parameters:
1{
2 "distance_metric": "TripletDistanceMetric.EUCLIDEAN",
3 "triplet_margin": 5
4}eval_strategy: stepsper_device_train_batch_size: 2per_device_eval_batch_size: 2num_train_epochs: 4fp16: Truemulti_dataset_batch_sampler: round_robinoverwrite_output_dir: Falsedo_predict: Falseeval_strategy: stepsprediction_loss_only: Trueper_device_train_batch_size: 2per_device_eval_batch_size: 2per_gpu_train_batch_size: Noneper_gpu_eval_batch_size: Nonegradient_accumulation_steps: 1eval_accumulation_steps: Nonetorch_empty_cache_steps: Nonelearning_rate: 5e-05weight_decay: 0.0adam_beta1: 0.9adam_beta2: 0.999adam_epsilon: 1e-08max_grad_norm: 1num_train_epochs: 4max_steps: -1lr_scheduler_type: linearlr_scheduler_kwargs: {}warmup_ratio: 0.0warmup_steps: 0log_level: passivelog_level_replica: warninglog_on_each_node: Truelogging_nan_inf_filter: Truesave_safetensors: Truesave_on_each_node: Falsesave_only_model: Falserestore_callback_states_from_checkpoint: Falseno_cuda: Falseuse_cpu: Falseuse_mps_device: Falseseed: 42data_seed: Nonejit_mode_eval: Falseuse_ipex: Falsebf16: Falsefp16: Truefp16_opt_level: O1half_precision_backend: autobf16_full_eval: Falsefp16_full_eval: Falsetf32: Nonelocal_rank: 0ddp_backend: Nonetpu_num_cores: Nonetpu_metrics_debug: Falsedebug: []dataloader_drop_last: Falsedataloader_num_workers: 0dataloader_prefetch_factor: Nonepast_index: -1disable_tqdm: Falseremove_unused_columns: Truelabel_names: Noneload_best_model_at_end: Falseignore_data_skip: Falsefsdp: []fsdp_min_num_params: 0fsdp_config: {'min_num_params': 0, 'xla': False, 'xla_fsdp_v2': False, 'xla_fsdp_grad_ckpt': False}tp_size: 0fsdp_transformer_layer_cls_to_wrap: Noneaccelerator_config: {'split_batches': False, 'dispatch_batches': None, 'even_batches': True, 'use_seedable_sampler': True, 'non_blocking': False, 'gradient_accumulation_kwargs': None}deepspeed: Nonelabel_smoothing_factor: 0.0optim: adamw_torchoptim_args: Noneadafactor: Falsegroup_by_length: Falselength_column_name: lengthddp_find_unused_parameters: Noneddp_bucket_cap_mb: Noneddp_broadcast_buffers: Falsedataloader_pin_memory: Truedataloader_persistent_workers: Falseskip_memory_metrics: Trueuse_legacy_prediction_loop: Falsepush_to_hub: Falseresume_from_checkpoint: Nonehub_model_id: Nonehub_strategy: every_savehub_private_repo: Nonehub_always_push: Falsegradient_checkpointing: Falsegradient_checkpointing_kwargs: Noneinclude_inputs_for_metrics: Falseinclude_for_metrics: []eval_do_concat_batches: Truefp16_backend: autopush_to_hub_model_id: Nonepush_to_hub_organization: Nonemp_parameters:auto_find_batch_size: Falsefull_determinism: Falsetorchdynamo: Noneray_scope: lastddp_timeout: 1800torch_compile: Falsetorch_compile_backend: Nonetorch_compile_mode: Noneinclude_tokens_per_second: Falseinclude_num_input_tokens_seen: Falseneftune_noise_alpha: Noneoptim_target_modules: Nonebatch_eval_metrics: Falseeval_on_start: Falseuse_liger_kernel: Falseeval_use_gather_object: Falseaverage_tokens_across_devices: Falseprompts: Nonebatch_sampler: batch_samplermulti_dataset_batch_sampler: round_robin| Epoch | Step | Training Loss | val-eval_cosine_accuracy |
|---|---|---|---|
| 0.0516 | 500 | 4.7612 | 0.5489 |
| 0.1031 | 1000 | 4.5194 | 0.5689 |
| 0.1547 | 1500 | 4.7301 | 0.5629 |
| 0.2063 | 2000 | 4.7071 | 0.5761 |
| 0.2578 | 2500 | 4.7363 | 0.5658 |
| 0.3094 | 3000 | 4.7441 | 0.5437 |
| 0.3610 | 3500 | 4.6649 | 0.5745 |
| 0.4125 | 4000 | 4.6601 | 0.5320 |
| 0.4641 | 4500 | 5.0637 | 0.5621 |
| 0.5157 | 5000 | 4.9042 | 0.5722 |
| 0.5672 | 5500 | 4.7195 | 0.5668 |
| 0.6188 | 6000 | 4.7135 | 0.5481 |
| 0.6704 | 6500 | 4.9458 | 0.5487 |
| 0.7219 | 7000 | 4.9647 | 0.5831 |
| 0.7735 | 7500 | 4.5704 | 0.5736 |
| 0.8251 | 8000 | 4.7343 | 0.5759 |
| 0.8767 | 8500 | 4.7883 | 0.5718 |
| 0.9282 | 9000 | 4.8248 | 0.5732 |
| 0.9798 | 9500 | 4.5618 | 0.5786 |
| 1.0 | 9696 | - | 0.5788 |
| 1.0314 | 10000 | 4.6449 | 0.5821 |
| 1.0829 | 10500 | 4.4106 | 0.5916 |
| 1.1345 | 11000 | 4.528 | 0.5765 |
| 1.1861 | 11500 | 4.4569 | 0.5780 |
| 1.2376 | 12000 | 4.3981 | 0.5811 |
| 1.2892 | 12500 | 4.5719 | 0.5730 |
| 1.3408 | 13000 | 4.3293 | 0.5815 |
| 1.3923 | 13500 | 4.4049 | 0.5840 |
| 1.4439 | 14000 | 4.2805 | 0.5835 |
| 1.4955 | 14500 | 4.0895 | 0.5710 |
| 1.5470 | 15000 | 4.2118 | 0.5926 |
| 1.5986 | 15500 | 4.2529 | 0.5943 |
| 1.6502 | 16000 | 4.2942 | 0.5920 |
| 1.7017 | 16500 | 4.3317 | 0.5870 |
| 1.7533 | 17000 | 4.075 | 0.5978 |
| 1.8049 | 17500 | 4.2079 | 0.5823 |
| 1.8564 | 18000 | 4.3221 | 0.5972 |
| 1.9080 | 18500 | 4.1851 | 0.5934 |
| 1.9596 | 19000 | 4.1392 | 0.5994 |
| 2.0 | 19392 | - | 0.5980 |
| 2.0111 | 19500 | 4.0978 | 0.5996 |
| 2.0627 | 20000 | 3.6555 | 0.5941 |
| 2.1143 | 20500 | 3.6428 | 0.5924 |
| 2.1658 | 21000 | 3.7263 | 0.5986 |
| 2.2174 | 21500 | 3.6035 | 0.5916 |
| 2.2690 | 22000 | 3.5678 | 0.5918 |
| 2.3205 | 22500 | 3.5047 | 0.5906 |
| 2.3721 | 23000 | 3.5305 | 0.5879 |
| 2.4237 | 23500 | 3.5372 | 0.5829 |
| 2.4752 | 24000 | 3.3066 | 0.5910 |
| 2.5268 | 24500 | 3.4096 | 0.5912 |
| 2.5784 | 25000 | 3.583 | 0.5957 |
| 2.6300 | 25500 | 3.3682 | 0.5920 |
| 2.6815 | 26000 | 3.4431 | 0.5936 |
| 2.7331 | 26500 | 3.4358 | 0.5963 |
| 2.7847 | 27000 | 3.5524 | 0.5899 |
| 2.8362 | 27500 | 3.4993 | 0.5922 |
| 2.8878 | 28000 | 3.6017 | 0.5988 |
| 2.9394 | 28500 | 3.6085 | 0.5934 |
| 2.9909 | 29000 | 3.1839 | 0.5883 |
| 3.0 | 29088 | - | 0.5957 |
| 3.0425 | 29500 | 2.7277 | 0.5936 |
| 3.0941 | 30000 | 2.658 | 0.5891 |
| 3.1456 | 30500 | 2.5114 | 0.5893 |
| 3.1972 | 31000 | 2.676 | 0.5840 |
| 3.2488 | 31500 | 2.6213 | 0.5852 |
| 3.3003 | 32000 | 2.5062 | 0.5854 |
| 3.3519 | 32500 | 2.611 | 0.5798 |
| 3.4035 | 33000 | 2.6159 | 0.5782 |
| 3.4550 | 33500 | 2.3517 | 0.5778 |
| 3.5066 | 34000 | 2.5418 | 0.5784 |
| 3.5582 | 34500 | 2.3883 | 0.5821 |
| 3.6097 | 35000 | 2.6465 | 0.5835 |
| 3.6613 | 35500 | 2.5591 | 0.5817 |
| 3.7129 | 36000 | 2.3965 | 0.5831 |
| 3.7644 | 36500 | 2.4044 | 0.5868 |
| 3.8160 | 37000 | 2.5333 | 0.5835 |
| 3.8676 | 37500 | 2.7044 | 0.5829 |
| 3.9191 | 38000 | 2.5474 | 0.5837 |
| 3.9707 | 38500 | 2.5231 | 0.5837 |
| 4.0 | 38784 | - | 0.5831 |
1@inproceedings{reimers-2019-sentence-bert,
2 title = "Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks",
3 author = "Reimers, Nils and Gurevych, Iryna",
4 booktitle = "Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing",
5 month = "11",
6 year = "2019",
7 publisher = "Association for Computational Linguistics",
8 url = "https://arxiv.org/abs/1908.10084",
9}1@misc{hermans2017defense,
2 title={In Defense of the Triplet Loss for Person Re-Identification},
3 author={Alexander Hermans and Lucas Beyer and Bastian Leibe},
4 year={2017},
5 eprint={1703.07737},
6 archivePrefix={arXiv},
7 primaryClass={cs.CV}
8}